Manufacters names in dropdown menus being html converted.

In 1.5 I noticed that a manufacturer in my manufacturers drop down box was showing T&S instead of being converted to T&S.

I hunted this down. And it would seem the code at includes/modules/sideboxes/manufacturers.php has changed causing this problem.

At around line 52 in 1.3.9h we have:

   while (!$manufacturer_sidebox->EOF) {
      $manufacturer_sidebox_name = ((strlen($manufacturer_sidebox->fields['manufacturers_name']) > MAX_DISPLAY_MANUFACTURER_NAME_LEN) ? substr($manufacturer_sidebox->fields['manufacturers_name'], 0, MAX_DISPLAY_MANUFACTURER_NAME_LEN) . '..' : $manufacturer_sidebox->fields['manufacturers_name']);

In 1.5.1 we have:

$manufacturer_sidebox_name = zen_output_string(((strlen($manufacturer_sidebox->fields['manufacturers_name']) > (int)MAX_DISPLAY_MANUFACTURER_NAME_LEN) ? substr($manufacturer_sidebox->fields['manufacturers_name'], 0, (int)MAX_DISPLAY_MANUFACTURER_NAME_LEN) . '..' : $manufacturer_sidebox->fields['manufacturers_name']), false, true);

The problem seems to be the zen_output_string and more importantly is the fact this is being sent as PROTECTED=true. This causes htmlspecialchars to be run on the string. Which causes & to turn into &&

Now a simple solution I guess is to change the manufacturer to T&S instead of T&S. That solves the manufacturers drop down.. but causes HTML errors everywhere else my manufacturer name is.

For now I've just made this piece of code not be protected by changing the last true to false. This seems to work right.

Something is inconsistent here though. Either Zen Cart needs to change ampersands or leave them alone.

To make sure this wasn't an add-on or module I've tested in a clean copy of 1.5.1 with demo products. Add a manufacturer to the system with a & and then tack it to a product and you'll see what I mean in the manufacturers dropdown.

I'm responsible for this, since I suggested the change from v1.3.9h to v1.5.0 having noticed that the manufacturers' sidebox on my home page didn't validate if I had an ampersand in a manufacturer's name. Unlike you, I didn't take it further, checking that having an & instead of & also caused validation issues in my products' listings and information pages.

I agree with your assessment; if an ampersand in a manufacturer's name can't be solved globally via code, it should at least be dealt with consistently. As such, I recommend that the change that was incorporated at my suggestion be backed out of the next ZC codebase and that the policy going forward be that if a manufacturer's name includes an ampersand (&) that the name be specified in the database using &

I think that might be easiest. Ideally I wouldn't mind if most everything converted. It's been a pain to tell people to use & instead of a normal ampersand. (Not that it really makes a difference, I can't think of any browser that chokes on this sort of thing)

But I don't know if I'd like my descriptions converted, as I use a lot HTML there. I think I also oddly have some attributes which I'm injecting with HTML to make look a little better.

Internal testing suggests this is resolved in v1.6.0 pre-alpha code (accessible on Github).

I would appreciate if one of you can confirm this.

DrByte:

Internal testing suggests this is resolved in v1.6.0 pre-alpha code (accessible on Github).

I would appreciate if one of you can confirm this.

Tested on code pulled from github this morning. Can confirm irregularities still exist.

Test procedure:

Installed 1.6 pre-alpha using normal installation, did not install demo products.
Created two manufacturers one with just an ampersand (T & S) and one with an ampersand quoted (Pelton & Crane)
Created two products and attached to manufacturers.
Visited product pages.

On the product info section the manufacturer name shows up as inputted:
<span itemprop="brand">T&S</span>
<span itemprop="brand">Pelton & Crane</span>

The first case will cause the HTML error we all love. The second is 'correct'.

However in the manufacturers side box we have:

As you can see both have been attempted to be quoted, yet the Pelton and Crane entry did not need it.

What I think needs to happen here is that on output nothing is translated and outputs as it is in the database, however on all inputs I think we need to check explicitly for an ampersand alone and quote if necessary.

Or just don't mess with the quoting at all. Allow us nitpickers to put in the HTML correctly to get rid of mostly harmless HTML errors.