htmlentities: Where do they get translated?

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