Preparations for starting to use the symfony routing component are almost complete. This will replace the current url mappings – another piece of ZenMagick code retired in favour of a proven, externally maintained component.

With the url mappings gone things will be a lot easier and perhaps it will even be possible to drop the sacs mappings as well – although the sacs (access control code) will most likely stay as it is.

There are a few more components to refactor and reconsider, for example validation and form handling. Once those are sorted there will hopefully be time again to work on real features, rather than rewriting the framework over and over again.

Using symfony will hopefully allow us to do that. It has a huge user base, active development and should allow to concentrate more on the actual shop development – and with that improving online shopping with ZenMagick..

Last week I was pointed to a discussion thread about ZenMagick in a german forum. One thing that came up was the fact that ZenMagick has still more than 100 bugs before a potential 1.0 release.

This referred to the ZenMagick issue tracker. It might be good to point out that this is, in fact, not quite true. The issue tracker is used to track bugs, features and general tasks. So, as of now there are 16 bugs in the issue system.

Of those 16 bugs there are none that are critical. So, what I am saying is that ZenMagick is really quite usable – and there are new stable versions every 3-5 month.

Had a bit of fun today with running out of disk space for the demo site.

Investigation showed that the zencart debug code was active and I was looking at 5000+ myDEBUG-xxxxxxxxx.log files in the cache folder. Since I do not have ssh access I came up with this to run in the console….

$dir = DIR_FS_CATALOG.'cache/';
$handle = @opendir($dir);
while (false !== ($file = readdir($handle))) {
if (!is_dir($dir.$file)) { unlink($dir.$file); }
}
@closedir($handle);

I’ve spend a lot of time recently working on some mock objects for the checkout process. The main one is a class called ZenCartCheckoutOrder.

The main idea is that an instance of that class can can be created and given a ZenMagick shopping cart instance would look and feel just like the zencart order class. With this (and some other hickery pokery) an evironment can be created that allows to use zencart modules without zencart actually being loaded. To be fair, this is not archived yet, but it is already used by the module wrapper classes in ZenMagick for the regular checkout.

One of the nice things I added was some assert code to compare a freshly instantiated zencart order instance with the mock object. This effectively means we are comparing pretty much all checkout relevant data as seen by zencart and ZenMagick, respectively.

The result is a much improved ZenMagick shopping cart class that now should cope with pretty much all price/tax configurations.

In the medium term these mock classes should allow us to use those legacy modules without having to load the full zencart stack – this is going to be a bit reduction in overhead. However, this is still some time away, but the light at the end of the tunnel is getting bigger

EDIT: For the worried people I should probably add that if numbers were wrong so far this would have been purely presentational, because the actual order process is still 100% zencart so far. That means the actual order will be the same in zencart and ZenMagick.

NOTE2: In actual fact, the exception to the above note is that payment modules that generate a complex order button form (or url) would be affected by this.

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.

Just a quick heads up that I got an email from DPS about changes to the URLs for payments.

I hope that all customers of DPS will get this notification, but I thought I mention it anyway, just in case.

Basically, the urls used to talk to DPS change. This is a pretty minor (one line change) in the DPS payment modules I wrote a long time ago.

Still, not applying those changes will result in broken payments, and I am sure no one wants that.

I am not sure if/when I will be able to update the current versions, but I will try.

Today ZenMagick 0.9.12.1 was finally released!

It’s been a long time coming and I am really happy with the result. Its the first release with input and contributions from more than 2 developers and I really appreciate all the time and thoughts people have put into this release. (Of course, developing a live site on trunk kind of makes you really interested in getting things done …

So, grab it, upgrade, start from scratch and let us know what you think.