Attribs zen_output_string_protected

[DrByte]

Are you saying there's a specific inconsistency somewhere?

[ses707]

The specific inconsistency is that
includes/modules/attibutes.php does not zen_output_string_protected the options_values_name which serves attribs on the product page
but
includes/modules/pages/shopping_cart/header.php does.

$attrArray[$option]['products_options_values_name'] = zen_output_string_protected($attr_value) ;

This actually helped me realize that in
admin/options_values_manager.php
I could:

$inputs .= $languages[$i]['code'] . ':&nbsp;<input type="text" name="value_name[' . $languages[$i]['id'] . ']" ' . zen_set_field_length(TABLE_PRODUCTS_OPTIONS_VALUES, 'products_options_values_name', 25) . ' value="' . zen_output_string_protected($value_name->fields['products_options_values_name']) . '">&nbsp;<br />';

This allows me to edit <a href> links in the admin. Before I could always enter links but editing them required 2 edits, one to clear the html that was hanging it up the first time and once to replace the <a href> with the change.

It always seemed strange to me that no one else linked their options values to a page with more info (or the product that attrib represents).

It's like 2am so I take no responsibility if that's jacked and you don't understand...

Edit: Basically you want to see html code in the admin so it should be zen_output_string_protected, however the customer should never see the html so anything they see should not be zen_output_string_protected.

[DrByte]

hmmm ... I would think that the output-protected approach should be run anytime the content of user-collected data is being re-displayed, so that if any sql-injection or other attack would be averted.

[ses707]

It's options_values_name which is input on the admin side only?

[DrByte]

Will have to do some further investigation. Here's a related post: http://www.zen-cart.com/forum/showthread.php?t=64115