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
- *all* of the remaining admin integration files
- the first batch of required file patches (replaced by one new file patch, though)
- the current storefront override file (
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?
- Plain object controller
Together with the routing integration there is now support to use any given class/method as controller. That means the method can be mapped to a request and there is no restriction to the proccess method any more.
This is in line with the way other frameworks do things and something people have been asking for quite some time
- Admin Store Status widget refactoring
The refactored code now allows plugins and other code that has access to the service container to register custom status checker to this widget. That means all important status checks can now be in a single consistent format/place.
- bootstrap refactoring
The files bootstrap.php and mvc.php are no longer supported and have been removed. The whole bootstrap/request handling process has been replaced by the zenmagick\base\Application and zenmagick\http\WebApplication classes.
This also allows to bootstrap individual components only, bootstrap without an application and more.
ZenMagick is now using .po files for translations, just like WordPress (in fact it uses the same code for handing .po and .mo files). Applications, themes and plugin now can contain translation files that will be merged during bootstrap.
Doctrine integration is progressing with some issues remaining that might only get fixed once we allow ZenMagick to control the request entirely, rather than run as a subsystem of zencart.
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):
There is an (empty) store-installer application now in the repository. Not sure if there is enough time to get this going for the next release, but things are moving forward.
Paving the way for the stand alone installer is a new upgrade option. This will replace the current installation page and hopefully be even simpler.
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..
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.