htmlentities: Where do they get translated?

Is there a list someplace that identifies which fields have their htmlentities translated and which don't?

I created a sample product to see what's going on. That product's name is "Product" & "Example", its description is This product has both double-quotes (") and ampersands (&) in its title, model number and name. and its model number is "EXAMPLE" & product. I also changed its manufacturer to "P&E".

Here's how its product_info page is rendered:

<!--bof Main Product Image -->
<div id="productMainImage" class="centeredContent back">
<script language="javascript" type="text/javascript"><!--
document.write('<a href="javascript:popupWindow(\'http://localhost/vinos/demo/index.php?main_page=popup_image&pID=186\')"><img src="images/no_picture.gif" alt="\"Product\" & \"Example\"" title=" \"Product\" & \"Example\" " width="100" height="80" /><br /><span class="imgLink">larger image</span></a>');
//--></script>
<noscript>
<a href="http://localhost/vinos/demo/index.php?main_page=popup_image&pID=186" target="_blank"><img src="images/no_picture.gif" alt=""Product" & "Example"" title=" "Product" & "Example" " width="100" height="80" /><br /><span class="imgLink">larger image</span></a></noscript>
</div><!--eof Main Product Image-->

<!--bof Product Name-->
<h1 id="productName" class="productGeneral">"Product" & "Example"</h1>
<!--eof Product Name-->

<!--bof Product Price block -->
<h2 id="productPrices" class="productGeneral">
$40.00</h2>
<!--eof Product Price block -->

<!--bof free ship icon  -->
<!--eof free ship icon  -->

 <!--bof Product description -->
<div id="productDescription" class="productGeneral biggerText">This product has both double-quotes (") and ampersands (&) in its title, model number and name.</div>
<!--eof Product description -->
<br class="clearBoth" />

<!--bof Add to Cart Box -->
                  <div id="cartAdd">
    Add to Cart: <input type="text" name="cart_quantity" value="1" maxlength="6" size="4" /><br /><br /><input type="hidden" name="products_id" value="186" /><input type="image" src="includes/templates/template_default/buttons/english/button_in_cart.gif" alt="Add to Cart" title=" Add to Cart " />          </div>
  <!--eof Add to Cart Box-->

<!--bof Product details list  -->
<ul id="productDetailsList" class="floatingBox back">
  <li>Model: "EXAMPLE" & product</li>
  <li>Shipping Weight: 5lbs</li>
  <li>70 Units in Stock</li>
  <li>Manufactured by: "P&E"</li>
</ul>
<br class="clearBoth" />
<!--eof Product details list -->

Sometimes the double-quotes are converted (zen_image), but most times not; the ampersands are never converted. Is there a "rule" that we can use to determine when it's OK to be lazy and just use & and " and when it's necessary to use & and " to get properly validated HTML?

lat9:

Is there a "rule" that we can use to determine when it's OK to be lazy and just use & and " and when it's necessary to use & and " to get properly validated HTML?

There's always "Rods Rule". If it don't work one way, try the other. :-)

Cheers
RodG

RodG:

There's always "Rods Rule". If it don't work one way, try the other. :-)

Cheers
RodG
It's a good rule in a pinch; I was looking for a bit more definitive a statement. Having a stated rule would indicate whether a I'm looking at a bug or a "user didn't enter the data right" issue.

Admittedly this is an area where I wish we had gone against the grain back-in-the-day and used a templating "language", so that all output always went thru a parsing function. Then there'd be a definitive rule. As it is right now all our automated tests and security tests show all outputs as being properly sanitized. But sanitizing for security isn't the same as insulating users from entering bad html.

DrByte:

Admittedly this is an area where I wish we had gone against the grain back-in-the-day and used a templating "language", so that all output always went thru a parsing function. Then there'd be a definitive rule. As it is right now all our automated tests and security tests show all outputs as being properly sanitized. But sanitizing for security isn't the same as insulating users from entering bad html.

Well, who knew (back then) that the internet was going to become such a big deal? :)

:laugh: ahahahaha, thank you for that bit of humor:D

Well, there is always 1.6...twig, twig, twig

DrByte:

Admittedly this is an area where I wish we had gone against the grain back-in-the-day and used a templating "language", so that all output always went thru a parsing function. Then there'd be a definitive rule. As it is right now all our automated tests and security tests show all outputs as being properly sanitized. But sanitizing for security isn't the same as insulating users from entering bad html.
Can I take the highlighted bit as indicating that product names, descriptions and model numbers, category names and descriptions and manufacturer names should ***always ***be entered using htmlentities (e.g. & as opposed to &)?

G'day,

It seems to me that Zen Cart expects us to enter HTML entities into all of the fields because Zen Cart typically does nothing to such fields on output. So if you enter L&M you get HTML validation errors. If you enter L&M you don't.

But doing this introduces a user interface problem. When the customer tries to search for L&M and it's been entered as L&M it won't be found.

So my thinking is that it would be better if we entered everything in the way a user would into search, i.e. L&M, but Zen Cart handles conversion of the appropriate characters to HTML entities on output, i.e. L&M.

Best regards, Lloyd Borrett.

lloyd_borrett:

G'day,

It seems to me that Zen Cart expects us to enter HTML entities into all of the fields because Zen Cart typically does nothing to such fields on output. So if you enter L&M you get HTML validation errors. If you enter L&M you don't.

But doing this introduces a user interface problem. When the customer tries to search for L&M and it's been entered as L&M it won't be found.

So my thinking is that it would be better if we entered everything in the way a user would into search, i.e. L&M, but Zen Cart handles conversion of the appropriate characters to HTML entities on output, i.e. L&M.

Best regards, Lloyd Borrett.
This, IMO, is a side-effect of not having a defined "standard" (i.e. entities in the descriptions/names or not). Perhaps the "issue" at this point with the search function is that it should search for both L&M and L&M.

G'day,

Of course you're correct lat9. If there is a defined standard then everyone knows what to do, and how output should be handled. Problem will be how to help users migrate their content to the standard.

Site search on large Zen Cart sites can already be very slow. (There's one I use regularly where a search typically takes more than a minute.) So I wouldn't want search to handle it both ways if it will slow the search even more.

In my old ZC 1.3.6 installation, if you entered HTML entities, once saved they were there. But if you edited the field, they were lost. Zen Cart would display & not & when retrieving the field, and it stored & when the field was saved. This was extremely frustrating and meant that there was no point in trying to put in HTML entities. We were forced to put up with HTML validation issues, which is not a good look, and causes flow on issues.

My vote would be for the 'standard' to be raw HTML. Then Zen Cart needs to convert all output to HTML entities. But maybe I'm not fully understanding other impacts of doing it this way.

Best regards, Lloyd Borrett.

RodG:

There's always "Rods Rule". If it don't work one way, try the other. :-)

Must include a similar note in my search help popup file.