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…

In principle, the Smarty plugin is finished, except for email handling. One additional bonus I found is the integrated caching.

The custom theme supports now the same layout config mechanism that all ZenMagick themes use (ie default_layout, etc..) and the name of the content view is passes as $view_name into the main template.

Downsides so far: It would be required to write Smarty function plugins as wrapper for all ZenMagick/zen-cart functions that we need to use. So, maybe I’ll leave it as proof-of-concept and hope someone else might be keen to write all of those

I also need to investigate as to how sideboxes would work as they tend to do some processing themself. In the worst case custom SMarty plugins would need to be written to provide the functionallity/data required. In a way this would actually be quite neat as it translates into custom controller code for sideboxes which would only be executed when used!

Stay tuned

Configuring page caching with a custom function

This is good for plugins or more complex code. Per default, the function zm_is_page_cacheable() decides whether a page can be cached or not. The name of this function is set up in the setting pageCacheStrategyCallback.

So, setting the value of that setting to your function name will make the cache controller call your function instead of the default.

The wiki plugin is an example for the second approach.

Custom error logging

Since 0.8.1 there is are two new options to control all PHP and ZenMagick logging.

The first is the setting ‘zmLogFilename‘. If the value is not null (null is the default), then all ZenMagick logging is written into that file. Make sure that the file is writeable and there is enough disk space!

The second, even more powerful setting, is ‘isZMErrorHandler‘, This is a boolean flag. The default is false, but when set to true, a custom PHP error handler will be used to log all PHP messages.

Note that the error handler depends on a custom log filename, so just enabling the error handler will not work.

There is, however, still a small bug in ZenMagick that will make ZenMagick log messages not appear in the logfile! This is fixed in subversion and will be in the next release.

An example of how this can be used in local.php would be the following:

zm_set_setting('zmLogFilename', $zm_runtime->getZMRootPath()."zenmagick.log");
zm_set_setting('isZMErrorHandler', true);


I’ve been looking at implementing anonymous checkout recently again. There is some decent code in subversion now, but in order to release sometime soon I might have to disable that for the next release and hope to get it all done after that.

(more…)

It’s about time to give a rough outline of what happens when ZenMagick processes a request. This is assuming a normal GET request, even though POST is virtually the same – the only difference being that the controller will call processPost() rather than processGet(). (more…)

With the first iteration of performance enhanvements in place it is time to look further. Page caching is certainly good, but often does not give the kind of fine grained control required.

One way to break down page caching into smaller pieces would be to allow content views and(side)boxes to be cached individually. In practical terms this could mean to execute the layout on request, but return cached pieces of HTML for particular boxes and/or the content view. (more…)

As mentioned in the readmap update, performance will be the key thing in the upcoming 0.6.3 release.

While there reamain still things to be improved, the already implemented changes will make things way faster.
One very obvious thing to do to make things faster is to cache generated HTML. The cache could be memory, the filesystem or even the database (in certain situations). For ZenMagick, I chose the filesystem, as it is fast and there are existing solutions to handle cached data. Zenmagick is going to use Cache_Lite.

(more…)

Having had some email conversations about current and coming ZenMagick features, I think it is time to write a bit about the short-to-medium term plans for ZenMagick. Also, I realise that the TODO list is not very readble (not even Iuse it very often…)

The next release, which is almost complete, will be 0.6.3 and will contain some bugfixes and quite a few changes to improve performance. I’ve been using xdebug lately and it is a quite valuable tool. I might try other products as well, but for now I am happy enought with it. (more…)