Some people might have noticed issue 363 to add support for twig templates to ZenMagick.

As you can see from the initial comments, I first thought we might add this as a plugin. This was a fair assumption, considering that a long time ago I already had a working prototype of a twig plugin working with ZenMagick.

However, with symfony just around the corner, it seemed worthwile investigation how twig is integrated there. As it turns out there is a Templating component with some nice separation of concerns – something symfony is quite good at.

To make a long(-ish) story short: we now have a (still inactive) implementation of that template engine interface that also implements the largely undocumented ZenMagick template API. It does need a bit more work, but once that is in place it should be possible to switch to using twig just by using a different file extension.

However, I still don’t know how much more work will be invovled to provide access to the same features/methods in twig as there are right now in PHP. OTOH, perhaps we won’t need them in their current form any more…

One of the things I’d like to get started on is to set up (and start using) the symfony2 routing. For this I think it would be a good time to rethink the current urls and come up with some improvements.

I’d like to get some ideas for urls, so if you have an opinion on what urls should be looking like, please check the  tracker issue and leave a comment.

The current ZenMagick release does suffer a bit from performance issues. Progress on this is tracked in issue 353.

There are a number of improvements that have already gone into the code that is going to be ZenMagick 0.9.14.

• Conversion of code into namespaces
  This is a biggie, as using namespaces means we can slowly switch off folder scanning to find global classes. The biggest remaining block of code is the shared folder. I am reluctant to rush that bit, though, because the plan is to take the time to improve/refactor code at the same time.
• The view component has seen a major refactoring.
  The main reason for this was that most of the Savant features had already been re-implemented in the view classes, so it seemed easier to port the last bit (the fetch() method) as well and drop Savant (and two levels in the stack traces) completely.
• Conversion of system config/container files to XML
  All container config files that are shipped with ZenMagick are now in XML. According to the symfony docs this is the fastest alternative.

In addition to the above I managed last night to fix a regression that created excessive SQL updates against the configuration table. This has improved the SQL stats quite a bit.
Looking at the current (outdated) demo site I can see that in 0.9.11.1 the homepage used about 300 queries. The most recent code for 0.9.14 gets away with ~100.

Despite all this progress there is more to do. In particular the time spend in the view is not acceptable. Another potential issue are the zencart wrapper classes during checkout. Right now they take up just too much time.

Lots to do…

Today the first ZenMagick 0.9.13 release candidate has been published.

Right now only the mod version is available. Themes, plugins and the full-release version might be added later this week.

This version is labelled release candidate  despite the fact that there are still a few issues open that might include further code changes. The rationale behind this is that the code is quite stable and the remaining issues won’t affect this. There is also a chance that some or all will be moved over to 0.9.14 should they not be ready for the final release.

The build has been tested on top of the current german zencart version.

Right now there aren’t any release/update notes available. People interested in trying the new code are encouraged to check out the issue documenting required changes.

If you happen to come across ZenMagick and wonder if there are sites out there using it, there is a (non comprehensible) list of sites. (Might need some checkout again, though)

Christmas is approaching fast and it is time to prepare for the (traditional) ZenMagick Christmas release. We’ haven’t always managed, but always aimed for having one.
This year is no difference and things are looking promising.

I am sure we will have to push a few tasks into the next release, but that is more a matter of organizing issues. Some surely should be ‘meta’ issues and have subtasks. Alternatively, we could probably have an ‘ongoing’ target that never expires.

Regression fixing is well under way and there is even a store online that uses a RC version of 0.9.13. All good signs that the code is ready to be released.

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);

For a new client project I’ve started looking at the php-rules project again. The project has all the ingredients for building a nice promotion system. However, the code has some shortcomings when it comes to PHP 5.3.

To cut a long(-ish) story short, I’ve forked the code (with the blessing of the author) and it now lives on github.

I’ve made some rather bigger changes to learn more about the code and to add some more structure – I hope it doesn’t affect performance too badly.

Feel free to have a look and give it a try. The tests are based on simpletest which is not included.

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.