I just realized that the wiki still claims that there aren’t any themes available for ZenMagick. That is, of course, not true!

I’ve updated the wiki’s theme repository page with some information and links to the demo store for each theme. Seing that themes/templates are a popular search topic, I hope that this helps spread the word…

Last night ZenMagick 0.9.5 was finally released! I am quite excited about this particular release, because it includes a couple things that make ZenMagick a lot more attractive to existing Zen Cart installations.

For one thing, there is a new patch that allows plugins to access the final HTML content of Zen Cart templates. This has been around in ZenMagick (for themes) for quite a while and proves to be very powerful.

A lot of the storefront plugins (page stats, page caching, google analytics) depend on this feature and now they can be used with Zen Cart templates too!
If you head over to the demo store you’ll see that the HTML generated by the default Zen Cart template is caches like any other page, following the same rules!

Another quite surprising thing (at least  for me!) is the new PDO based ZMDatabase implementation. It seems to be the fastest implementation so far and the demo store seems to do fine using it, so I might make it the default implementation for the next release.

There are also improvements to existing plugins and, of course, a couple new ones. The most interesting one is probably the phpBB3 plugin. It provides the same features as Zen Cart’s phpBB support, just for phpBB3.

I also really like the new theme toggle plugin that allows to switch between Zen Cart and ZenMagick. Probably not very useful for a production environment, but good to compare features, displayed values, etc.

Of course, this is not the end, and I’ve already started working on the next version. In that context a reminder that with 0.9.6 I’ll be removing a lot of the deprecated stuff. Also, the deprecated API support will be removed before a 1.0.0 release, but most likely not before 0.9.8.

I’ve just updated the demo store with a release candidate version of ZenMagick 0.9.5.

There are some interesting visual and other changes that the demo store illustrates:

• Use of PDO based database API
• New plugin to switch between ZenMagick and Zen Cart template
• Improved event support for Zen Cart templates (that’s what the switch is really for!)
  The extended event support now allows ZenMagick plugins to manipulate the final HTML of Zen Cart templates. That means, all ZenMagick plugins that rely on this mechanism can now be used in Zen Cart templates, too! Obvious examples are the page stats and style switch plugin (even though the style switch doesn’t really work for Zen Cart templates, right now).

One thing that is now good to see is the difference in database queries. Even though the Zen Cart default template and the ZenMagick themes do not display exactly the same data, it’s still impressive to see the difference in queries

I somehow lost my release notes so the public release will have to wait until early next week to give me time to get organized again.

Happy demo’ing!

I happened to notice a  search ‘when is zencart 2.0 actually coming‘ in today’s log. It’s a good question. Unfortunately I do not know the answer, but I do know that the next ZenMagick release is not far!

Today I checked in the final changes to make the category pages use the new sql based pagination code that hopefully will be on par with the way Zen Cart handles it [(except for being a lot more complex, of course ].

That means that the last bit I was hoping to get into the next release is actually in place. I’ll be doing some more testing and try to figure out which plugins need updates. That should hopefully get me to a point where I can write release notes and build ZenMagick 0.9.5 next weekend!

I think I really need to do something about the plugins. Ideally, they would all have their individual changelogs, but right now with core changes that affect pretty much all plugins that seems to be overkill. I guess for 1.0 that might be something to look into, though.

Coming back to the search mentioned above: Of course there is no need to wait for Zen Cart 2.0 in order to enjoy things like:

• Plugins that do not require file changes
• A simple template structure that does not need include/require
• A database API incl. DAO’s, transaction control and support for different database providers
• A MVC based framework
• Flexible form validation with rules to change both JavaScript and server side validation in a single place
• Guest checkout aka. checkout without registering
• and a lot more

Just start using ZenMagick today!

With the number of things on my todo list for the next release shringking fast its time to have a look at what is about to happen in the next ZenMagick release.
I’ve already written about a few things, but I think it is also nice to have it all in one place. (Also, these posts are usually good starting points for writing the release notes!)

So, here’s a list of things to look out for int he next release:

• Banner Management
  So far, banners where identified by index (integer) and needed a setting each in order to work. As of 0.9.5 this is going to be simplified and there is actually already some documentation about how things are going to work.
• Database API
  A number of things changed here, in particular the ability to create type mappings on-the-fly and support for array model data in all xxxModel() methods should make life simpler in a few cases
• define refactoring
  A lot more defines have been converted into consts in the appropriate classes. Defines are fine, however, I feel that consts are a lot more readable and also it’s easier to find where things actually are in the source code.
• ZMLayout refactoring
  The service class ZMLayout has been renamed ZMTemplateManager in reflect the newly added methods to manage CSS and JavaScript resources. Short story is that it allows to add CSS to a page even after the <head> section has been created by the template.
• Support for large result lists
  I’ve explained this already, so I’ll just say that the new solution is SQL based and pretty close (at the bottom) to what Zen Cart currently does.
• Plugins
  As usual there will be new plugins. First, an initial version of a plugin to manage custom ZenMagick settings in the database. It uses some new widgets and I expect that with the number of widgets growing there will be a lot of improvements in the future.
  Secondly, support for phpBB3 at the same level as currently exists for phpBB2.
  There are also improvements and fixes for a number of other plugins that are, of course, listed in the changelog.
• Open
  A couple things are still open, but should be included, time permitting: a new search page based on the already existing ZMProductFinder class, make all unit tests pass!

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…)

Thinking about events yesterday made me wonder why there is actually a very specialised method filterResponse() for plugnis. One of the reasons was that I thought it would be nice for regular code to be able to modify the response, too.

One example of why that could be useful is CSS. In contrast to importing JavaScript, CSS needs to be imported/references in the <head> section of a HTML page. That means if the code that generates the HTML needs some special CSS this needs to be handled way in advance of where the code is actually executed.

One idea is to have some sort of resource manager that is able to access the final HTML and inject all the CSS [either explicitely or by linking .css file(s)]. That way the fact that new CSS rules are required would not need to be known in advance.

One obvious use case would be the new widget class, of course!

Looking at the code I remembered the real reason why this is so special: the HTML contents is passed into the method as parameter and the modified contets returned used as parameter for the next plugin, and so on.

Currently, events do not return values. The only parameter is a hash map that may contain any type of data.

So, to cut to the point, I changed the fireEvent() method to optionally handle return codes. The default behaviour is compatible to the current use, however it is possible for event subscriber to return a changed array.
Strictly speaking this is not really necessary as it is possible to modify the parameter array due to the reference handling in PHP5. Still, should special events require a contract where the parameter is not an array things should be ok.

So, as o f the next release [0.9.5] content filtering will be available to every piece of code that whishes to do so.

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.