Upgrades: Character Sets and Collations

 hints, zen-cart  Comments Off on Upgrades: Character Sets and Collations
Dec 202016

As more and more web-hosts retire PHP 5.4, more and more Zen Cart stores are going through the “upgrade process” … many of them from versions of Zen Cart prior to v1.5.1.  Since the concept of identifying the character-set used by the database (the DB_CHARSET definition) wasn’t introduced until Zen Cart 1.5.1, those stores’ databases are normally using a latin1-style collation (e.g. latin1_general_ci or latin1_swedish_ci).

It’s important that your Zen Cart’s CHARSET (as identified in each language’s main language file, both storefront and admin) and DB_CHARSET (identified in your configure.php files) definitions “agree”, otherwise your customers with first names like José might have their names recorded as José … not pretty!  In addition, many of the payment providers (PayPal, for example) are now using a UTF-8 character-encoding in their communications with your store; if your store is still using an ASCII character-encoding (like iso-8859-1), then any order placed by José  is going to likely result in his name being mangled in your store’s database.

There’s a tool that can help you re-align your database’s collation: Convert DB to UTF8.  This plugin, available for download from the Zen Cart Plugins, will convert the character-set (collation) of each of the database’s tables to utf8_general_ci.  Just make sure that your DB_CHARSET definition (in both the storefront and admin /includes/configure.php files) is set to utf8 once the database is converted and don’t forget to delete that file from your store’s file-system when you’ve finished.

Another consideration as you’re converting your store to have a consistent character-set:  language files. If your store is currently using an ASCII character-encoding and you’ve made use of some special characters (other than standard alphabetics and numbers), then your language files might also need some care-and-feeding.  For example, if you’ve included the “half” character (½) in an ASCII language file and you’ve updated your site to define your CHARSET values as utf8, you’ll find that � is displayed instead.

You can normally correct these character-display issues with the help of the Notepad++ editor, downloadable here.  Once the editor is installed, use it to open your problematic language file(s).  In the top-of-page menu ribbon, you’ll see a tab named Encoding.  If you click on that tab, the editor will show you what encoding is currently being used, most likely Encode in ANSI.  You can use the editor to change the file’s encoding, just click on the Convert to UTF-8 (not Convert to UTF-8 BOM) element in that Encoding tab’s drop-down and save the file!  Hopefully, you won’t find a bunch of these.

Once your store has been fully updated, you won’t have any of those character-conversion headaches in the future!

Zen Cart Rule #3: Don’t Over-Prepare

 hints, php, troubleshoot, zen-cart  Comments Off on Zen Cart Rule #3: Don’t Over-Prepare
Oct 312015

When you’re performing database manipulations, it’s important to prepare your textual input so that there aren’t any stray single- (‘) or double-quotes  (“) that will wreck havoc with your MySQL queries.  Zen Cart provides methods (the functions zen_db_input and $db->prepare_input) that will help, but you need to have a plan for what method you’re going to use to insert or update that data to prevent over-preparation.

Zen Cart provides two methods for inserting and updating database information:

  1. class-based, using the $db->Execute function.
  2. function-based, using the zen_db_perform function.

The class-based method allows you full control over the formatting of a MySQL query while the function-based method uses an associative input-array to map each database field to its associated value.  The function-based method’s strength is its ease in creating or updating an entire database table record, while the class-based method is more suitable to a quick update of a couple of fields in a record.

When you use the class-based method, it’s very important to prepare any text input prior to sending that data to the database, i.e. escaping any quotes within the data.  Failure to do this can result in a whitescreen (with associated myDEBUG*.log) intermittently … based on the data input.

When you use the function-based method, that function automatically prepares all input — in fact, it treats all input as strings.  If you’ve also prepared the input, the resultant database field will include unwanted slashes (e.g. o/’Toole instead of o’Toole).  That’s because the function has prepared (via call to $db->prepare_input) data that you’ve already prepared, resulting in the slashes themselves being escaped … a result of over-preparation!

Zen Cart makes it easy to perform your database manipulations, but the onus is on you to first choose the method that you’re going to use and then perform any input-preparations needed based on the method you’ve chosen.

Zen Cart Rule #2: Additional Images’ Names

 hints, troubleshoot, zen-cart  Comments Off on Zen Cart Rule #2: Additional Images’ Names
Sep 292015

From “Animal Farm”, by George Orwell:

All animals are equal, but some are more equal than others.

You’ve got your Zen Cart set up and have been placing all your products’ images in the base images’ folder (/images). It’s getting hard to maintain all those images in a single folder (and it’s surely increasing your page-load times), so you’ve decided to move all the product images into manufacturer-based sub-directories.

Good plan! Now you’ve updated each of the products’ database records to properly point to the primary image that’s now in an images’ sub-directory (e.g. images/microsoft) and have copied all those additional product images as well. You fire up your store with those relocated images and … what the heck … many of your additional images have “gone missing”. You re-check that the additional-image files have, in fact, been copied to their manufacturer sub-directory — they’re there!

One of the “problem” products uses base image name of my_image.jpg and it’s got two additional images: my_image-01.jpg and my_image-02.jpg. There’s the issue — all additional images are equal, but some are more equal than others!

The additional-images’ handling (/includes/modules/additional_images.php) uses different criteria when the base image is in a sub-directory than in the main /images directory!  When a main product image is in a sub-directory, its additional images’ file-names are of the form base_suffix.ext; when the main image is in the root /images directory, no intervening underscore is required.

So, given the example above, the file my_image-01.jpg is a perfectly-acceptable additional image for the file my_image.jpg … when the main image is in the /images directory itself … but not when the main image is in a sub-directory.  The file my_image_01.jpg is a valid additional image for my_image.jpg, regardless the directory in which the main image resides.

Now that you know the additional-images’ naming rules, it’s easier to play the game! Happy Zenning!