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.

One of the new features in the upcoming Zen Cart 2.0 version is going to be a reduced number of database queries for price lookup. Most of those queries are attribute related and therefore do not affect all stores/products.

Due to the current work on making ZenMagick properly available for Zen Cart templates, I’ve had the chance to do some easy comparisons. (more…)

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’ve been playing around with implementing new ZMCache provider. xcache is nice and easy to test, in particular since it comes with a simple admin interface to dump the cache entries.

I just found something similar for memcache and it was really a big help.

Besides being able to verify that adding/removing from memcache worked, it helped figuring out how to retreive the stored items and, more importantly, the cache keys.
Since ZMCache supports grouping of entries the only way to handling this is to iterate over all entries and compare prefixes.

Initially I implemented some internal tracking. However, I wasn’t sure whether that would stay in sync over time. Iterating over entries might not be the most performant operation, but considering that this is ever going to happen from within the admin interface of ZenMagick this should be fine.

EDIT: I’ve started moving this article to the wiki and will not update this post any more!

In my last post I started a list of things to do before the magic 1.0.0 release. I’d like to keep this post as a reference for things to do. Hopefully, I’ll be adding (and removing!) things often as I go.

(more…)

Right!
After spending quite some time on fixing regressions from my refactoring madness its finally time to get ready for the next release.

Rather than reiterating the things that have been changed/added/fixed/improved I’d like to talk a bit about what is coming next. I am aware that I never much of a roadmap for ZenMagick. One of the reasons being that there was just too much to do and I never had real priorities. With the changes coming in 0.9.1 there isn’t a lot left to be done for the templating side of things until we’ll eventually hit ZenMagick 1.0. The API, on the other hand, still requires some work.

While the API is pretty much complete as far as the storefront functionallity is concered, it lacks quite a bit when it comes to the admin side. What I mean is the ability to create and update data. While there has been some work in that area, there is still a lot left. As a general rule, create/update functionallity is available where it was needed.

With the introduction of the new database code I hope to finally get this big gap filled and make ZenMagick even more attractive for integrators and people interested in extending zen-cart.

There is also going to be some more work in refactoring the core code. While this is not strictly necessary, I have the urge to do that just to make myself happy (I hope that is reason enough

Parallel to all that there are plans for a lot more work around plugins:

• admin – maintenance
  There are a few plugins that I started, but never finished. Those would make the Catalog Manager a lot more useful. However, those will most likely depend on the missing data access features of the API (namely, creating and updating date like products, categories and other)
• facets
  This is something I started as a reaction to some discussion about alternative ways to navigate the catalog. Eventually, I hope this will be good enough to replace and improve the current result list/filter code (not sure about the sorter, though). It should be more performant (using some form of caching) and generally smarter.
• other
  There are a couple other plugins I can feel coming. This might include some more support plugins for zen-cart mods, but also some new features for the storefront side of things.

Finally, there is more need to trim the code and make it perform better. I plan to have a look at what other PHP based apps do for that and see what seems useful. Suggestions welcome.

So, again, not much of a real roadmap, but I think that a version 1.0 is finally (far, far) far away becoming visible. If you feel I have missed anything important, please, please comment or write me an email.

Happy weekend, everyone

I am (again, again, again) agonizing over ZMCategories.

As part of the database code changes I am reviewing all services and model classes and there is heaps that could be improved (from a coding point of view, most of this work won’t be visible to regular users that just mess with templates).

There are actually two things that make this rather tricky:

• Internal caching
  The current implementation does a lot of internal caching in order to be fast.
• The active flag on categories (via applyPath(..))

Initially caching was not a big issue until I added support for multiple languages. Now that I want to add support to create and update categories (for admin tools) there is a second dimentions: the status. Further complications are that the code builds a tree structure to support the category tree navigation.

The second is actually just something I’d rather implement differently as it depends enirely on the cPath request parameter and that shouldn’t interact with a service.

So, I plan to change two things:

1. The meaning of the method isActive() in ZMCategory will change and be similar to the same method in ZMProduct.
   Active categories are visible in the store, inactive aren’t.
   This should actually not be a big issue as this method is used only in the default categroy rendering method zm_build_category_tree_list().
2. The whole logic currently done by ZMCategories::applyPath() will have to go somewhere else. Again, potentially the only code affected is zm_build_category_tree_list().

Any objections? – let me know…

EDIT: As it turns out,  changes are really confined to zm_build_category_tree_list(). That means unless your theme uses a custom version of zm_build_category_tree_list() there is nothing to fear

Not sure if anyone remembers that some time ago I moved all the caching code into the zm_page_cache plugin. That is, all code but the class ZMCache. I was reluctant to move that class as ir provides some basic caching for everyone to use.

However, right now I am in the position to need some caching and it turns out things are not that simple. Well, maybe they are, but it’s not as nice as it could be.

There are mainly tow reasons:

• If each plugin is responsible for it’s own caching only, there will be a growing number of Cache Manager plugin pages, one for each plugin.
• Should there be different caching options (file, memory, etc) there is no easy way for a cache user to take advantage of that. Even worse, it means ZMCache is right now bound to doing file caching.

To remedy this situation and to bring caching more in line with the service infrastructure I’ll be adding another service ZMCache (unless the plural of cache is caches!). This is going to be a cache service that can be queried to get a cache instance that will be what is now ZMCache. I would expect the current ZMCache class to be renamed into something like ZMFileCache.

Another advantage will be that there is no need for individual cache manager pages and it will be much easier to show more cache stats without having to modify each and every plugin that uses caching.

Also, this might be a good way to use more caching in ZenMagick core. For example, some of the more time consuming things like validation rules, etc could be serialized and cached, rather than building them from scratch for every request.

Other thoughts?

I have just checked in a change that converts the current page caching code into a new plugin. This might perhaps be a good time to explain the reasoning behind my shifting code into plugins.

Having build a reasonable effective plugin architecture I think it’s worth using it for several reasons:

• It shows that it works!
  This is perhaps not a very technical reason, but I think it is  important to show that  a lot of different things can be archived by writing reasonably simple plugins
• It keeps  the core small
  While this is true it is also true that critical stuff should probably stay in core. However, this offers the opportunity to build your own caching code and easily integrate it into ZenMagick.
  Another example of a plugin that actually contains/modifies some very elementary functionallity is the Smarty plugin that completely changes the way templates are evaluated; still, it’s good to have this ability to plug in different templating systems without having to modify core.
• Besides being useful it can be used as sample code
  Again, not very technical, but probably crucial when trying to motivate other people to write plugins of their own

In addition to the above, plugin performance is not far off from core code performance. This is especially true when using core.php. In that case, all code is back together in a single file and the only overhead is the creating of the single plugin class.

With 0.8.5 out of the way I think it is time for another iteration of performance measuring and improvements.

With the amount of new code there should be a few things I can do to make ZenMagick a bit faster.

One thing I’ll be looking at this time is to review the use of ‘zen-xxx’ functions. I tried to be as conservative as possible using them and in most cases there isn’t really the need other than some lazyness to write another service class.

Still, looking at the subversion files you can see that I have been experimenting with alternative init sequencenes (cutting out even more zen-cart code). This is not to drift further away from zen-cart, but to avoid loading and even executing code that is never used.

I wouldn’t expect this to work anytime soon, though. In particular, most of the mods that do work via ZenMagick plugins require the normal zen-cart init code in order to work properly.

Things I’ll be looking at are more like this:

1. Found 2 lines of code using zen_xxx()
2. zen_xxx() calls zen_yyy() and zen_zzz()
3. none of the later are used anywhere else
4. convert zen_xxx into either a service class, a new method of an existing class or a simple function

This is definitely going to improve a few things. For example, the new ZMTaxes class will help reduce database access by using internal caching (per request) and there are more cases like this.

This exercise will hopefully also give me a better idea of where most of the dependencies between zen-cart and ZenMagick are to be prepared for new releases…