What is ZenMagick?
About two years ago I wrote a post Is ZenMagick for you? This post is an updated version which is supposed to put things into perspectice, in particular the current status and future plans. (more…)

What is ZenMagick?About two years ago I wrote a post Is ZenMagick for you? This post is an updated version which is supposed to put things into perspectice, in particular the current status and future plans. (more…)
Looks like finally with WordPress 3.4 it will be possible to use the API by loading the WP code from within a class/function.
It is amazing that is has taken so long to get this done, but as I remember there used to be a lot more globals that depended on file being included from global scope.
Good news, though, as it will finally allow to write a ZenMagick WordPress plugin without using any hackery
It’s been a long long time sine I last wrote about what is happening with ZenMagick.
For the most part the reason for this is that I haven’t been working on ZenMagick for the last – uhm 3 month or so.
Having said that, this doesn’t mean the project is stalled or abandoned. Quite the opposite – there have been more (and more drastic) changes to ZenMagick that ever. Johnnny has been VERY busy converting ZenMagick to a mostly full blown symfony 2 application.
I hope to be back into coding soon and there is definitely a release planned (don’t ask me what version number that will be, but it might be a 1.0 [at least it would deserve it]).
Changes are too numerous to list here. Let me just mention that we do use HttpKernel, a lot of the ZenMagick code has been moved into bundles and the doctrine ORM is mostly ready for action.
I’d prefer to be more specific, however I too have some catching up to do! For all interested the best way to keep track of what is happening is to follow the ZenMagick git commit logs (if you look carefully at the url, you’ll notice that the source now is owned by the ZenMagick organization on github…)
And it happened again. Due to some issues with renewing the domain (the ISP changed owner in between), zenmagick.org is currently down.
And thanks to the apparently stupid go daddy it always is a mission to get it back. Looks like there have been problems renewing the domain for the ISP itself – sigh.
I’ll update this post once things have improved…
Apologies, mano
UPDATE: Apparently the domain will be back tomorrow – hold your breath. Is it really true that Go Daddy do domain renewal processing only once a week??
I am very close to having the new pricing code pass all shopping cart tests. In fact, one benefit of this change is that for the first time it is possible to run a complete cart test over all products in one go.
The stats for that look something like this:
Client IP: 127.0.0.1; PHP: 5.3.10; ZenMagick: ${zenmagick.version}; environment: prod; total page execution: 31.5726 secconds;
databases: zmdev(ZMDatabase): SQL queries: 23325, duration: 19.6571 seconds;
includes: 526; memory: 63176704
Right now I do have one test randomly failing. The attributes are randomly populated (select, radio and text), so it takes a bit to log what is actually breaking things.
Still, this is a major improvement and means that ZenMagick contains all relevant pricing code – and all of that only once!
Since the checkout order instance is already populated from the shopping cart, all data is derived from a single set of business logic – yay!
Another bonus is that the shopping cart now is populated just from a simple array containing product id, quantity and attribute details of the products in the cart. In fact, this is the same data zen-cart uses.
This also means that we now can start tracking cart actions separate from zen-cart (and verify that they match). The ultimate consequence of that is native cart actions that just use ZenMagick code rather than the zen-cart cart instance internally.
Still some way to go, but a big step, nevertheless.
This week I have taken another stab at improving the ZenMagick pricing code. The main reason right now is to further reduce the number of SQL queries per request. As part of the process to encapsulate zen-cart logic as much as possible there is a class ZenCartCheckoutOrder that is compatible with zen-cart. However, it is populated entirely from the ZenMagick shopping cart class.
Unfortunately, the shopping cart class itself still relies on zen-cart, so the more logic is in ZenMagick, the better, because with the internal caching in the ZenMagick service classes, all relevant data will only be loaded once and once only!
Of course, pricing is not the most trivial part of zen-cart, so getting that right is a mission and tracking down pieces of code one by one to see what is actually going on.
The good news is, that so far all common cases like discounts, attribute pricing, quantity discounts, sales and one time costs are already working. The remaining differences are all around word count issues, etc. Hopefully one more improvement to come with the next version.
To make things work reliably, there is an option to assert that calculated values are in sync with zen-cart, which makes life a lot easier…
After having published a first snapshot of the upcoming ZenMagick 0.9.14 it seems time to write about what is new and shiny in the next release.
Perhaps the biggest change is that zen-cart is now loaded on demand and ZenMagick is the main request handler.
What does that mean?
It means that for example, ZenMagick is responsible for session handling. It also means that no zen-cart code is loaded unless ZenMagick allows it.
Right now that *is* still happening, as there are still some missing bits in the ZenMagick request handling. However, we are nearing the point where this is no longer the case. At that point, zen-cart will only be loaded on demand, and only the bits relevant for checking out and ordering.
As a side effect of these refactorings, we have added a number of modified zen-cart core files into a bundle (the symfony plugin system), so file patches can be obsoleted. On the other hand it means that relying on zen-cart core file patches will not be that easily possible any more.
A second major milestone is the integration of yet more symfon2 components, as can be seen in the list below.
Other, biggish changes include:
For a more complete list of all changes please check the roadmap for 0.9.14.
I’ve finally written some reasonably easy addition to the ZenMagick PHP templating engine that allows to set the crumbtrail (and other bits, if required) in the actual view.
This is something I’ve been struggling for a long time. The crumbtrail code has been a source of bending backwards and ugly code for a very long time.
Now, the view can just do something like: $crumbtrail->addCrumb('Foo') and be done! As you might have spotted, the code in itself hasn’t changed at all. The only change in the templates so far has been to the layout file to use the new fragment() method to ‘mark’ the place where to put the crumbtrail and then *after* the view has been included the marker is filled with whatever crumbtrail has been set up.
One nice thing is that right now the views do not anything, because the crumbtrail is set up by the controller classes. So, it will be possible to migrate each view individually by moving the crumbtrail code from the controller class to the view template – yay!
Probably nothing to get too excited about, but it has been a long time coming…
There are some big changes coming in ZenMagick. One of the big concerns was (and still is) the integration (or lack thereof) with zencart.
To pave the way for some real improvements for this there has been a huge amount of work to make things simpler, cleaner and faster.
Right now ZenMagick is integrated via a number of file patches and additional files (overrides) in storefront and admin. Last week we removed
init_templates.php)And, there is more to come.
This means for the next release/upgrade there will be some cleanup required to get rid of obsolete files. On the plus side – wait, that is already the plus side!
In the grand scheme of things this will mean faster request handling (more/no zencart code used for most of the time), less conflicts with zencart code and generally we expect a much more predictable behaviour.
Of course, with so many changes there are things to consider. For one thing, ZenMagick will, for the first time ship with custom versions of core zencart files. This means if those files are patched in your system right now, those changes will need to be applied in our version. OTOH, those files are mostly not the commonly modified files.
I will write up some more details once the dust has settled a bit…
To see the progress I am digging through the resolved issues and that list is slowly but steadily growing.
Right now there are about 7 issues left, although some might not get resolved for the next release.
One of the bigger issues is to upgrade ZenMagick to using the symfony routing component. This is not a small task and even after I thought I was finished with the component integration there was still plenty to do and improve.
Now all that is left to do is waiting for someone to donate a routing config file
So, what else is new?
Some of the above changes have had widespread impact on the codebase, so upgrading has do be done with care.
In addition there is the ongoing work to migrate code to namespaces and generally improve the code (while doing that).
Next on the list of things are (in no particular order):
I am sure there has been more, but the above seem to be the bigger tickets.
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..