Another round of things that might be interesting for people using ZenMagick. Also a chance for me to write down a few things that are not documented anywhere else and hopefully add them to the ZenMagick website as well…

The extra directory

The extra directory is the place where themes can put their own code. This can be either static stuff (eg functions, settings, etc.) or classes. ZenMagick accesses those files using the loader. Other than this, there are three conventions that control how the code is loaded:

1. If local.php exists, it is guaranteed to be the first file to be loaded. That makes it an excellent place to put theme specific init/config code.
2. The distinction between static code and classes is based on filenames. Files starting with a upper-case letter are treated as classes, lower case indicates static code.
3. The loader is expecting exactly one class per file with the filename reflecting the class name. This is a case sensitive process, even though PHP will use lower case for class names internally (AFAIK).

Based on the above conventions we can conclude that:

• Static theme code is always execute/loaded before the page controller is called
• Theme classes take precedence over core classes if the loader is used to instantiate them
• Theme switching is supported, but not neccessary a transparent thing

There is also one special case related to using core.php. If core.php is used, the loader will validate that potential classes inherit from ZMObject. This is required as there is no way to make sure that only ZenMagick specific classes are instantiated. An example of what would happen is trying to create an instance with a class name of ‘Language’. Since zen-cart includes a class called language there is a name conflict. In order to avoid that the check is required. If core.php is not used, the loader can look at the classpath and figure it out from there…

Theme switching

Theme switching is allowed in theme code while the themes static code is loaded/executed. If a theme switch is detected, zm_theme and zm_themeInfo will be updated accordingly and the new themes static code will be loaded.

For each theme the controller will be looked up and the most specific one will be used. That means if Theme A provides n implementation for, say, product details and then switches t Theme B and Theme B does not have it’s own implementation, the controller from Theme A will be used.

l10n/i18n support

I went through quite some pain to enhance the language and date/time support compared to zen-cart (this is, of course, just my personal opinion).

While the used configurati onoptions in the themes lang directory are very similar, it takes away the pain of modifying zen-carts zen_date_raw(..) method if yo want to change the date format. Rather, everyting is based on the date and time pattern in i18n.php. I also added the sample string here, so it’s just one place to edit.

While there are a number of settings, usually all you need to change is UI_DATE_FORMAT and UI_DATE_FORMAT_SAMPLE. Only condition is that zen-carts original method gets disabled. The installation screen has an option to do exactly that.

With the changes to the theme code these settings will also be inherited from the default theme, thus making all current settings in the demo store obsolete.