Today I finished the still missing conversion/import of static page contents into (abused) ezpages into the database.

This will be disabled to start with and people keen to use this will have to opt-in manually, but it is good to finally move towards a system where there is only a single storage system (the database) for language specific content.

The admin interface includes a new manage content option – a stripped down version of the EZPage management UI. Content in this new system are just blobs of text with a name and language. Same as static pages (define pages in zencart speak) the name is the identifier and for each language different text can be created/edited.

The new code is controlled by a setting, so no changes to templates are required for now. To opt in the following steps have to be taken:

1. Enable the new code by setting ‘zenmagick.apps.store.staticContent‘ to true.
2. Run the ‘Import Static Pages’ option from the ZenMagick installation page.
   This is a one-off task to get you started; of course you can create all needed content from scratch using the admin UI

Today I came across an interesting issue related to class loading. Someone asked me to look at an out-of-memory issue upgrading a (slightly older) ZenMagick installation to PHP5.3 in order to prepare for a ZenMagick upgrade (good on ya!)

The upgrade seemed to work fine, but just for the homepage. All other pages ran into out-of-memory issues in ZMLoader (may the code rest in peace).

First I thought, ‘oh, well, it has to run out of memory somewhere‘, but with nothing left to analyse I decided to add some debug code to check what the loader was trying to load. Not surprisingly, a lot of actual classes. But then the list changed to just strings. Nothing random, mind, stuff you just remember from looking at zencart code. Here is an example:

resolve class: ZMNetUtils
resolve class: Always Free Shipping
resolve class: ZMAlways Free Shipping
resolve class: /index.php?main_page=static&cat=conditions
resolve class: ZM/index.php?main_page=static&cat=conditions


So as was evident, the (no longer used ‘ZM’ prefixing magic) was causing an endless loop. Still, why would PHP try to resolve those strings as classes?

Further digging lead to this bit of code in zen_not_empty:

} elseif( is_a( $value, 'queryFactoryResult' ) ) {

This is the second else case after a check for an array value. Together with a small note in the PHP docs about un-deprecating is_a in PHP 5.3! things started to make sense.

Every call to zen_not_empty with a value that is not an array will run into the above check and cause a class lookup for the given string (most common case).

So, adding a simple is_object() to the above code sorted the memory issue and also is a performance improvement as it avoids unnecessary class loader lookup:

} elseif( is_object($value) && is_a( $value, 'queryFactoryResult' ) ) {


Today I fixed issue #211, which means ZenMagick now supports symfony2 style routing.

Right now all current url mapping code is still in place and in order to use the new routing it needs to be explicitly enabled.

The coexistence with the current code is a mjor plus, because it means we can use the routing to enable build in nice urls, while still using the frown controller infrastructure.

As usual, there are some small differences between ZenMagick and symfony.

1. Controller naming pattern
   ZenMagick uses a reduced naming pattern: Class:[method]. Since in ZenMagick code can come from a number of different places it didn’t make sense to require a bundle. Also, with namespaces it is still possible to use the same class name with just a different namespace.
   The method name is optional and if missing will default to ‘process’ – the traditional single entry point for ZenMagick controller classes.
2. Controller method parameter mapping
   When using a custom controller, symfony will match request parameter by name with the corresponding method parameters. This works just the same in ZenMagick. However, in addition there is some more magic that supports mapping of:
   • ZMRequest
   • ZMFormData
   • any other class as model class

   This means using PHP type hints for parameter will allow to map a populated form container object to a parameter, the current request instance (ZMRequest) or any other object used as form/model container.
   In the future support for more special classes/interfaces is planned, for example validation, messaging, etc.

So far, controller methods to handle a request, typically processGet() or similar had to return a ZMView instance. With the new controller code those methods are also free to just return a string – the viewId.
Support for returning the viewId together with some custom view data will be added soon.

I have to say that integrating symfony components so far has been good fun. Routing, though, has been the most rewarding component so far.

I hope that pretty soon we will have some good default routing for storefront and admin, so enabling routing will mean to have nice, clean and structured urls for your online shop.

As some of you might remember, there has been a bit of back and forth with the forum registration settings.

After having taken the time to look at a few available captchas it seems that the current one does really work! It’s been a few days now, and so far there has been 1 spam account since the new captcha has been enabled.

That means registration is now enabled again and hopefully will stay that way from now on.

Its a busy time for me, so progress on ZenMagick has been up and down. This week has been good – I’ve got a first working draft of the block admin UI. Only, I just realized that the current db structure doesn’t allow to manage separate settings per theme – hmmm.

Last week I had this urge to see some progress, so I worked my way through a number of small issues – nice to see the number of open tasks go down, although the big ones are still out there waiting…

Good news: I just pulled all symfony2 upstream changes and ran the vendors script to pull those changes – all still working

Time for another update. As usual I am going to tell you that things are progressing nicely

And this is no lie! I’ve ticked off a few issues this week already, although those were all small changes. It felt good to see the list shrink, though!

I am very determined to finish the block admin – it is the basis for a lot of other template related changes. For example it will replace the current sidebox admin and allow to manage arbitrary elements anywhere you like.

A full list of items still to be done is in our issue tracker. Besides that, I do have some client related work that unfortunately takes precedence every now and then.

Still, I am in a good mood (enjoying German summer also helps!) and looking forward to the next release.

I’ve spend a bit of time today looking at captcha alternatives for the forum – I’ve installed a new one and registration is open now!

I’ll have an eye on registrations – typically there shouldn’t be that many, so if it gets too much I’ll have to try another one. Luckily I do have a small list of plugins to try