So far my posts have not given the impression that support for zen-cart mods in ZenMagick has a great future. Still, I always added that the answer to the question of whether a mod can be supported or not depends largely on the structure of the mod and most of all on the number of actual templates includes.

For the next release a couple new plugins will be available that should hopefully make it more interesting for people using multiple mods to move to ZenMagick.

In particular there will be:

• A new plugin adding support for cross-selling using this mod
• A store locator plugin using Google Maps
  (Initially, only one location is supported, but the plan is to make it possible to add multiple locations)
• There might be support for the new Multisite module which is hosted here
  I have to add though, that this is still open and I actually feel that this might be something that deserves native
  support in ZenMagick (either in core or as  another plugin)
• There is also going to be a new plugin that will contains all the music related code.
  This means, that out of the box, ZenMagick will have only support for the default product type. Installing this new plugin will seamlessly make music products work.
  This might also be a good way to distribute other product types…

I am also pondering a rewrite of the captcha plugin. There are heaps of articles about the usefulness of captchas and I think it would be nice to have a more generic structure, so that it might be possible to drop in new captcha classes that use different images algorithms or even to allow to randomly select one…  Of course, this would require that all classes implement a defined interface (which might be even only one method!)

I’ve added a few events that will get fired during ZenMagick request processing.

• ZM_EVENT_DISPATCH_START / ZM_EVENT_DISPATCH_DONE
  Fired before zm_dispatch() is called and after it ended.
• ZM_EVENT_VIEW_START / ZM_EVENT_VIEW_DONE
  Fired before /after the views generate() method is called. A reference of the view instance is added to the parameters map using the key ‘view‘. (see example below)
• ZM_EVENT_CONTROLLER_PROCESS_START
  Called by the controllers process() method (but only after authorization has been verified). The controller itself is passed as event source.

In the cases where no real event source is available, the current $zm_runtime instance is used as event source, as null can’t be passed by reference.

Examples of how to meddle with request processing…

To change the view displayed add something like this to a custom event observer class:


// change displayed view
function onZMViewStart($args) {
$view =& $args['view'];
$view->setName(’login’);
}

// add global variable to controller; $foo will be available in the view
function onZMControllerProcessStart($args) {
$controller =& $args['source'];
$controller->exportGlobal(’foo’, $this);
}


In tradition with my current just-in-time documentation a quick note about theme switching.

As explained previously, the theme id is taken from zen-cart. In order to be able to that, a ZenMagick installation patch exists, that will create dummy files to make zen-cart believe that those themes exist as zen-cart templates.

Theme switching is a feature in ZenMagick that allows to programmatically change the theme for the current request. The ideal place for that is any local.php that gets loaded, so either the global local.php file in zenmagick, or the one in the extra directory of the currently configured theme.

The code itself is a no-brainer:

if (’contact_us’ == $zm_request->getPageName()) {
   $zm_runtime->setThemeId(’default’);
}


This, for example, will switch to the default theme if the contact us form is displayed.

It is possible to have multiple switched per request (in the above example, the default theme could decide to switch to yet another theme under certain conditions..). Obviously, performance will suffer from too many switches.

A related feature is theme inheritance. This means that, like in zen-cart, template files/resources that can’t be found in the current theme will be looked up in the default theme. This may be disabled by setting ‘isEnableThemeDefaults‘ to false.

If disabled, templates will execute a little bit faster. However, it requires to have a “complete” theme. Depending on the complexity of your template changes this might mean that a lot of files need to be copied without any change. One potential downside is that files may need to updated as new  ZenMagick releases require modifications to those files.

Let me start by saying that  I do not mean to ridicule anyone, so don’t get me wrong - if this is a rant it’s more about zen-cart and how it forces people to do unreasonable things rather than any contributions or contributors.

Every now and then I browse the contributions section on the zen-cart site to see if there are new mods worth looking at.  I really am amazed that there have been over 600 downloads for a mod named ‘Telephone not required on signup’. This is remarkable on two unrelated levels.

First of all, why would anyone need to change this via an admin control? I know, it’s nice to have choices, but isn’t that too much? How often have you changed the phone number field from mandatory to optional (or vice versa) in the last year?

The second reason is, of course, that in ZenMagick this is possible by commenting out a single line in the validation configuration. Agreed, no nice interface, but then, you don’t need to download a mod, patch a core file and run some custom SQL to get the same result! Your choice…