Jump to content

Archived

This topic is now archived and is closed to further replies.

chadcloman

[SOLVED] Item description blank, existing ones deleted by the editor (or: why htmlspecialchars hates you)

Recommended Posts

[Note: I'm using an older version of osCommerce. I assume this has been fixed in newer versions.]

For some time I've noticed that if I have a sufficiently complicated item description, the osCommerce item editor will not display it and just show a blank text area. In the past I've worked around this by adding the description directly to the database. Once the item description is set, it works fine, but if I revisit the editor it will be blank, and if I subsequently save the item then the description will be lost and written to the database as a blank field. Today I decided to investigate.

WHY THIS IS HAPPENING:

The htmlspecialchars() PHP function is used to make an output string safe, and you use it pretty much whenever you write text to a web page, and especially if the text comes from somewhere other than string literals in the source code (e.g., user input, database). One feature of htmlspecialchars() is that it understands character encodings and will output an empty string if it encounters a value that's not part of the expected encoding scheme. It does this silently, and the caller has no way of knowing it happened.

Things were working reasonably well until PHP 5.4.0 was released. At that time, the default encoding used by htmlspecialchars() was changed from ISO-8859-1 to UTF-8. Apparently the osCommerce editor's item description is not encoded with UTF-8, and this broke htmlspecialchars() -- but only if the description included special characters of some sort. Instead of returning the "safe" version of the character string, htmlspecialchars() would instead return an empty string. This is the cause of the osCommerce error.

The problem was noticed and quickly changed by the PHP developers. In PHP 5.6.0, the htmlspecialchars() default encoding was changed to be the default encoding defined in the 'default_charset' configuration variable. So the problem will most likely only occur if you're using PHP 5.4 or 5.5.

More information about this issue can be found on the htmlspecialchars() manual page.

HOW TO FIX THE PROBLEM:

Method #1:

Specify the correct encoding. This can be done by editing the source code to replace any use of

htmlspecialchars(<string>);

with

htmlspecialchars(<string>, ENT_COMPAT, get_cfg_var('default_charset'));

Note that if you wish to use a specific character encoding, you can replace the 'get_cfg_var(...)' part with that encoding enclosed in quotes (e.g., "ISO-8859-1").

This is what I use and is what I recommend.

Method #2:

Tell the function to ignore stuff it doesn't understand. This can be done by editing the source code to replace any use of

htmlspecialchars(<string>);

with one of the following

htmlspecialchars(<string>, ENT_SUBSTITUTE);  // Substitutes a Unicode U+FFFD character

htmlspecialchars(<string>, ENT_IGNORE);      // Ignores and discards bad characters - NOT RECOMMENDED

The last one, ENT_IGNORE, is not recommended because it can cause security issues.

When making these changes, you should modify every instance of htmlspecialchars() in the source. But if you wish to simply fix the item editor, here are the files that need to be changed:

  • admin/includes/functions/database.php
  • admin/includes/functions/general.php
  • admin/configuration.php

That's it. Hope this helps.

 


Check out Chad's News.

Share this post


Link to post
Share on other sites

×