htmlentities: Where do they get translated?

[RodG]

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

[lat9]

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.

[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.

[mc12345678]

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? :)

[barco57]

ahahahaha, thank you for that bit of humor


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

[lat9]

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 &)?

[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.

[lat9]

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.

[lloyd_borrett]

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.

[dw08gm]

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.