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.

ZenMagick does support the concept of environments. For example, there are different config files for ‘dev’ and ‘prod’.

One of the ways to switch to a different environment is to change index.php to index_[environment].php.

So far this was limited to admin, but no more! The only issue is that yo will need to change the storefront url (for testing, mind) to something similar to the ZenMagick admin url:

zenmagick/apps/storefront/web/index_dev.php?main_page=index

This can be helpful toggling logging settings, or even the db used.

The other reason is that there is (and will be more) code that is conditional to the environment. One example that I added today is that in dev mode a new event is fired for each fetched template. This allows to see (roughly) how much time each template takes to render…

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…

Last week I helped analyze a case where moving a zencart installation to a new server caused the dps payment module to break.

It didn’t take too long to find out that the redirect from the pxpay payment page back to the store was quite long. After some more digging it was then found (not by me) that suhosin has a restriction on get parameters of 512 characters. The urll in question was more than 3000 chars long, though!

Changing that in the PHP configuration easily solved this problem. Looks like suhosin is gaining popularity, IMO. The second time lately that I had to deal with this.

Might be worth adding a check to the installation script to issue a warning or check those parameters in order to avoid having to debug every time…