Last week I was asked if it would be possible to use the CSS click-show-hide menu mod in ZenMagick. After some quick testing it turned out that only some minor changes are required in order to get it working.

Of course, there are some things that could be nicer. With product counts enabled the generated category tree uses an additionl 260 database queries (even thought that is not really news).

I changed the mod to using the ZenMagick API which kind of fixed that problem. One minor issue remained, though. The original Zen Cart code calcualtes the product count on a category sub-tree, not just the actual category. So the numbers are not quite the same. I might fix this, even though I doubt that this is a major showstopper.

The really interesting question now is how to wrap up the resulting files. All there is are the original javaSript, CSS and image files (CSS image path adjused to suit the ZenMagick file structure), the class that generates the HTML and the sidebox template file.

(more…)

Zen Cart does have an extensive event system. One thing I feel make it not very useful is that most events are specific to a particular page. For example there is a different NOTIFY_HEADER_START_XXX event for each different page.

In ZenMagick there is the generic controller_process_start event with the actual controller instance as event parameter. In particular plugins that need to run on each page this needs some additional work. (Not much, but there are worse examples).
So, one other outcome of my work to make plugins work (better) with Zen Cart templates is to convert Zen Cart events into ZenMagick events to tigger the same event callbacks from within a Zen Cart template.

Seeing the events using the page_stats plugin is acutally quite impressive. For example a product details page (demo DVD product) looks something like this in Zen Cart:

Compare that with the same page using a ZenMagick theme:

Again, both pages where rendered without any sideboxes.

You can spot the artificial ZenMagick events in the Zen Cart event list as the keys are lower case. The differences are even more impressive with products that have lots of attributes.

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.

I think releasing the themes prior to the next ZenMagick release was probably a bit too optimistic.

I just realised that there are a couple more things that the new themes depend on.

One thing that is for sure is that I added a couple new classes to some of the default theme templates (mostly result list related). On the other hand, it should be possible to figure out what those are based on the theme specific CSS. In any case, downloads do not indicate too much interest (which surprises me, to be honest!).

The next release will be a minor bugifx relase plus some more refactoring, so it seems to be a good idea to get that out of the way before diving back into some bigger changes.

I actually just now released the first four public and free (covered by a Creative Commons Attribution license) themes.
There might be some glitches, as I developed against a trunk version of ZenMagick, but except for a small issue with highlighting the correct header navigation item I can’t think of anything that should cause the to break.