I thought I’d give everyone a heads up that I’ve finished the toolbox code refactoring that removed the $echo parameter from all methods. With the exception of l10n and i18n that should be the last big change to templates.

I also fixed the Language Tool – sorry, I think it must be broken in 0.9.8 already. Seeing that hasn’t been a single complaint so far I assume it’s not widely used

I’ve also started working on some basic branding of the installer and admin pages. If this gets released it definitely makes ZenMagick a separate product – at least the full installation release.

… or, things to come II

For the last few releases I’ve been bumbling along, changing whatever I fancied and never really worried about anyhting. The closer ZenMagick moves towards a 1.0 release, the more difficult it becomes to continue doing that.

There is a long list of things I want to do and also a list (not on paper) of things that I think should be in 1.0. There are two things I really should get done to give the releases a bit more direction and also (re-)assure users that there is actually hope to get to a 1.0 release at all!

1. Prioritize the visions list and split it into two listsl; one including things that will be in 1.0 and one with things to come.
2. Eventually I’ll have to face the fact that after a 1.0 release I’ll have to spend more time doing proper branching in order to keep the APIs stable for a while. At the same time there should be work on future versions with new/changed APIs and stuff from the visions list that didn’t make it into 1.0.

I guess one reason why it takes me so long to get there is #2. Branching and maintaining several branches (for example a 1.0.x branch and also a 1.1.x branch) is not something I am particulary looking forward.

in conclusion, I will try to start working on a more substantiell roadmap towards a 1.0 release and put that on the wiki once it is fleshed out enough to be of any use.

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!

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!

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.

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.

I’ve filed two new bugs for 0.9.3 which are also still in 0.9.4. Doesn’t shed a good light on my testing, but there are simple workarounds for both.

I just wished someone would have told me before – I am sure there must have been people struggling with this. Sigh.

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 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.