I’ve spend some time today playing around with the isEnableZMThemes setting and the consequences.

The main issue so far is that even though Zen Cart templates work fine now, quite a few plugins are useless, because they manipulate the final HTML via the call to ZMPlugins::filterResponse().

To fix this, I created a new file patch today. It’s the first since quite a long time which goes to show that things have been rather stable for a while.

The new patch will modify includes/application_bottom.php and insert a single (rather long) new line. That line contains the full response filtering and event handling code required to make plugins work.

For example, the page_stats plugin is now able to inject the page stats into Zen Cart templates and even page caching does work!

So, from 0.9.5 on it will be possible to cache the  HTML repsonse from a Zen Cart template using any of the available caching implementations (xcache, memcache, file) to speed up page delivery!

This brings us a lot closer to a stripped version of ZenMagick that does not include theme code and only supports plugins and admin enhancements. I wonder if that would be good to go back to the zen-cart site as add-on…

There has been a setting isEnableZenMagick in ZenMagick since the very first releases. Initially, it was intended as simple switch to disable ZenMagick completely. However, over time this morphed into a ‘disable themes‘ flag and recently is was a bit broken too.

I checked in some changes to get this working again. To reflect the changed behaviour I also renamed the setting to isEnableZMThemes.

I thought about removing the flag completely. After all, if you want to get rid of ZenMagick, the easiest way is to remove all patches using the installation page. However, it occured to me that keeping the flag might actually increase the potential user base. Reason being that with the storefront disabled, ZenMagick would become interesting for people that would like to use the admin enhancements (for example the Catalog Manager).

Also, to counter the claim about ZenMagick being a Zen Cart fork, the project could perhaps be broken into two packages:

• ZenMagick (core)
  The API and basic admin pages
• ZenMagick themes
  The majority of the code including the default theme, controller classes, etc.

So this is only a thought I don’t even know if want that. It would be a bit of work to get the current build process changed to create two separate packages. I suspect at least some files would need to be split in order to cleanly separate functionallity. Oh well, another item on my list of things to think about.

As part of my work on the new product picker I’ve upgraded to jquery 1.2.6. So today they release 1.3!

Sounds like a goor release with tons of new stuff. I guess I’ll be upgrading again soon

In a way  this is good, because it means I’ll be reviewing all used JS and try consolidate things a bit. In particular the used plugins should be looked at again. Most use cases are quite simple, so it would make sense to review the available options again and go for the best performing alternative.

Another thing is that I noticed that the catalog manager page doesn’t support injecting header code. This is going to be more important with more plugins coming and each having its own requirements.

In fact, I might change the current system of passing around a ZMPluginPage instance to another service. This would also make it a lot easier to avoid including the same file more than once. It also would mean there is no need to change the admin page .php file for each new plugin that wants to include something different.

Of course, there are also the other usual suspects like IE compatibility. I’ve noticed a few glitches in the category tree and right now, the product picker doesn’t really look that good at all :/

On the plus side, I’ve extracted the javaScript and CSS into separate files, cleaned up the code, wrapped it in it’s own class and generally am finished with the actual UI JS coding.

Next will be a bit more layout and beautification. After that the jquery/plugin review. Suggestions for good and simple widgets are welcome. I’ll be looking at plugins/code for:

• (non-)modal dialogs
• a tree view
• tabs (incl. lazy loading via Ajax)
• a date picker
• other suggestions?

1. Dynamic CSS

Yesterday the question popped up whether it is possible to access the ZenMagick API from within a CSS / JavaScript file.

This obviously involves a performance penalty. Nevertheless it is possible.
The first step is to rename the file. This is essential, because otherwise your PHP will never be executed. For example, you’d rename your site.css file to site.css.php. The second step is to include the ZenMagick file external.php.
Example: (This examle assumes that your CSS file is located in the theme’s content folder)

<?php include '../../../external.php'; ?>
After that you can start using the ZenMagick API as you would in any other template file.

2. Organizing template files in subfolder

Currently all views with the exception of email and popup templates are stored in  a single folder. With the way URLs are mapped in ZenMagick (ZMUrlMapper) it is easy to change that.

Let’s have a look at how things are done for popups right now (core/settings/url_mapping.php):

$urlMapper->setMapping(null, 'popup_search_help', 'popup_search_help', 'PageView', 'subdir=popup');

The main_page value popu_search_help is mapped to a template (also) named popu_search_help. However, the property subdir is set (on the configured view ZMPageView).This means the view will look for the template file in a subfolder popup. To add to this twist, there is some magic code to trim everyting up to the first ‘_’ in the template name when constructing the final filename. This has historic reasons and is likely to be removed in the future. So, this mapping will resolve to (within the theme folder): content/views/popup/search_help.php.

There is another way of archiving the same that is a bit more sane (and a lot simpler), though:

$urlMapper->setMapping(null, 'popup_search_help', 'popup/search_help');

The template value is considered to be the filename without the set template filename extension. So this second mapping will resolve to the same file as the first, just in a much more elegant way.

Conclusion: To organize your view templates in different folders, all that is requires it to add a relative path to the mapping.
Please note that this would require some more mappings than there exist now. Typically, the main_page value is the template name, so nothing needs to be configured at all.

I’ve made a few changes regarding filenames today:

• core/settings/settings.php got renamed to core/settings/defaults.php
• core/settings/zenmagick.php is now core/settings/constants.php
• and I renamed local.in.php to local.php.in

(more…)

I have read the recent announcements for Zen Cart 2.0 with great interest. Obviously this will mean a lot of work for me (and everyone keen to update).

For obvious reasons I have mixed feelings – it’s great to see Zen Cart finally catch up with a lot of other good carts. On the other hand there is a lot of overlap of features between Zen Cart 2.0 and ZenMagick.

Even though it is hard to really asses where this will leave ZenMagick, I am confident that there is still room (and need) for a lot of the things that make up ZenMagick. We’ll have to wait and see the code in detail, though.

Meanwhile I’ll be working on another release that should bring a few new things again. I also might push a minor bugfix release, since I found a few things broken in 0.9.4 (and 0.9.3, for that matter). We’ll see.

So, it isn’t quite a Christmas release, but still 2008!
There isn’t too much new stuff in it – it’s mostly maintenance. Still, I figured that releasing the full list of plugins might be a good idea.
I am sure there have been bits and pieces that changed but never made it into new releases, so this would be a good time to catch up.
On the other hand, some plugin code changed and pretty much all plugins were affected, so I won’t feel too bad removing deprecated code in the future.
Of course, there have been new plugins too, but I have written about those, so nothing really new.

I’ve been pondering whether to have another release before Christmas for a while now and I think it would be a good idea. As far as releases go this is going to be a pretty minor one.

I spend a some time fixing some small things that croped up and als refactored a lot defines away (making them consts in service classes mostly). Some theme related defines about directory names got removed completely as they do not really change a lot (and shouldn’t either).

On the plus side there are going to be two new plugins. Firstly, the already annourced form handler and also the code I’ve been using on the demo store to switch themes.

There is also some new code in the form of new cache implementations and also a new ZMDatabase implementation using PDO.

The only real downside is that I’ve touched every single plugin. That in itself is probably not a bad thing, however the sourceforce file release interface requires to set platform and file type for each separately and that is a real pain.

I have just checked in some changes that untangle security and url/request mappings.

So far, views using ZMRedirectView as view class had a parameter of secure=true in the mapping to make the redirect to a secure url. That means, however, that information about secure URLs were stored in two different places, and even more so, potentially could get out of sync.

With the changes as of today that is no longer the case. I also changed ZMUrlMapper to allow to configure a couple more things, including the controller class and a form id for automatic validation (not supported yet).

All in all, this means that the url and security mappings now are able to control pretty much all aspects of request handling as a proper MVC framework should be able to.

it is worth noting that mappings are only required if defaults are not sufficient. This would  be the case if:

• the view class is not the default (PageView)
• the view id used by the controller is not the page name (typically the case for POST requests)
• the views template name does not match the page name (for example, all products use product_info as page name, but the template name is derived from the product type)
• a controller class is to be reused for a different page name

I should perhaps also mention that the reason for all these changes was the need to do what the last list item describes.

As a result of this now being implemented, there is going to be a new plugin called zm_form_handler. What it does is that it allows to set up an unlimited number of page (names) with corresponding templates, where each page/template contains a different form. Forms can be validated using the page name/id as form id. Sucessfully submitted form data will then be emailed to a configurable email address (or the store email).

So, this is what every better ISP offers as CGI or custom form handler.

Considering that static pages and custom forms (incl. email notification) are often searched for features (and also pretty basic stuff), it’s good to finally be able to be able to offer this!

EDIT: The next would be, of course, to get rid of the secure parameter on url generating methods and leave the decision about that also to ZMSacsMapper! I’ll have to ponder that for a while, though…

For those waiting for 0.9.2 – things are progressing, although on a somewhat reduced speed.
Using the new unit testing plugin (to be released with 0.9.2) I managed to iron out some inconsistencies in ZMAccounts, which were causing some strange errors.

Handling of custom fields is not working as expected – there was a surprising number of places where things were actually not working!

Looks like I will have to look at the old database code again – ZMCreoleDatabase does break the phpBB plugin – somehow the active database is not switched. Unsurprisingly, this works ok using ZMZenCartDatabase….

Email support is greatly improved – in particular now that I have found a quite good place to keep all the custom code in one place do the templates start to look like templates and not spagetti code. I’ve added new templates for gv_queue, gv_mail and coupon. That means there are only two more emails left and those do not seem to be to important (unless someone complains loud enough).

There will be some new business events – ZM_EVENT_CREATE_ACCOUNT, ZM_EVENT_LOGIN_SUCCESS and others. I think there will be even more- in particular the fact that it is now possible to modify objects passed into the event handler make this much more useful.

There is also an event that allows to customize the context of all emails. This will allow for injecting custom data to make emails more powerful. (In fact, this is how ZenMagick now prepares emial content, rather than having code in each template).

The view code has been clean up a bit and is now more consistent. This should make plugins with more than one view much easier to create.

I’ve also added support for session token to secure forms against XSS. Forms to be procected can be configured dynamically (this allows, for example, the OpenID plugin to take advantage of this feature, too).

And, of course, the usual number of fixed bugs is in the mix as well.

The code is currently tested and I would expect a release within the next few weeks.