Zen Cart Observers: Observations

 plugins, v1.5.3, v1.5.4, v1.5.5, zen-cart  Comments Off on Zen Cart Observers: Observations
Oct 082017

One thing to consider when you’re writing a Zen Cart plugin that includes an observer-class module is the point at which any monitored notification is going to be “fired”.  Auto-loading observers, previously discussed here, are great since using that method can reduce the number of files that a plugin needs in its distribution … but there’s a potential downside (isn’t there always?).

All auto-loading observers are loaded at breakpoint 175 during the Zen Cart autoload process.  That processing loads all files present in the /includes/classes/observers directory whose names match auto.*.php and, if the class’ name adheres to the auto-loading “rules”, creates an instance of the associated class.

If the notifications that your plugin is observing are issued prior to breakpoint 175, then auto-loading isn’t for you!

For example, let’s say that your plugin is monitoring NOTIFIER_CART_ADD_CART_START, issued by the shopping-cart class at the beginning of an add-to-cart action.  Those cart-manipulation actions occur during init_cart_handler.php‘s processing at breakpoint 140, so an auto-loading observer will never see that notification.  Your plugin will need to include an additional file (in /includes/auto_loaders)  to instruct Zen Cart the point at which your observer should be loaded (prior to 140!) and instantiated and its observer-class file’s name must not start with “auto.“.

In summary, while auto-loading observers can simplify a plugin’s distribution, plugin authors need to ensure that auto-loading is compatible with the plugin’s expected functionality.

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 1.5.5b!

 v1.5.5, zen-cart  Comments Off on Zen Cart 1.5.5b!
Nov 122016

Wow, where did the year go?  In the interim, the Zen Cart developers have finalized the 1.5.5 (initial) release and augmented that with 1.5.5a and 1.5.5b releases.  Here at Vinos de Frutas Tropicales, I’ve released:

  1. Updates to Edit Orders, working with the Zen Cart development team to get the admin-level “sanitization” introduced in 1.5.5a to “play nice” with EO.
  2. The DataBase I/O Manager (DbIo), an alternative to EZ-populate that’s designed from the ground up.
  3. The One-Page Checkout plugin, reducing the normally 3-page checkout handling to a single page of information gathering … making it easier for your customer’s to complete their purchases.

A Zen Cart 1.5.5b release provides an incremental improvement over 1.5.5a, squishing bugs reported in 1.5.5a and accommodating interface changes introduced by some of the payment providers (like

Over the next year, I’ll be bringing my various plugins up to the Zen Cart 1.5.5b notifier interface and removing support for Zen Cart versions prior to 1.5.3.  ZC 1.5.3 introduced the concept (needed for PHP versions post-5.3) of a variable that can be modified by a “notifier”.  Since I focus on releasing plugins that “seamlessly” plug into your cart, that’s an absolute necessity!