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.
I’ve spend a lot of time recently working on some mock objects for the checkout process. The main one is a class called
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.
Good news: I just pulled all symfony2 upstream changes and ran the vendors script to pull those changes – all still working
Right, so I’ll try to get back into weekly updates – even if there isn’t a lot to report…
Work on ZenMagick 0.9.13 has started and there is lots to do. I hope (not going to promise, though) that this release won’t take as long as the last one, but we’ll have to wait and see.
As yo can see there has been some progress already, in particular the integration of the swiftmailer bundle is shaping up nicely. The admin app is already using it and the plan is to convert the storefront code too, perhaps with a new simple zencart transport as wrapper around the current/old zencart code for those that still need it.
The next thing ticked of is a refresh of the RSS code. The code has been moved into a proper PHP namespace and the sidebox template now takes advantage of using the dependency injection container to lookup the required instances to pull the RSS feed to display.
Like in similar situations this now allows to use the container to configure the RSS cache directory and other aspects f the RSS code.
Finally, the github submodules have been refactored and are now gone. Instead there is a new script vendors.php that pulls all the required libraries into the right place. This is only relevant for people that want to run ZenMagick right off github.
The next things on my list are to finally finish the block admin UI and a number of other admin UI related tasks.
Time is flying when you are having fun, so in that respect is has been a very short week.
We’ve made lots of progress, so here’s a quick summary:
Lots of work here – looks like it is almost ready to move into HEAD, at least to provide basic functionality.
We do have a new
Settings class that improves and extends the current
ZMSettings code. It also now supports imports: – something also found in symfony config files.
Also, the reorganized setting of config files/locations now also supports environments. The environment can be controlled by:
SetEnv ZM_ENVIRONMENT production
- front controller
index_devel.php?rid=… or index_test.php?rid=…
The event system has been upgraded too, building on and extending the symfony2 EventDispatcher.
The bootstrap code (
bootstrap.php) has been slimmed down quite a bit and a few things have changed order to make more sense.
The currents system of auto loading static PHP code (per convention all .php files in the class path with a filename starting with a lower case letter) has been deprecated and removed from the bootstrap sequence and all other places (plugins/themes).
There are a few outstanding items that still need to be tackled for the next release, most importantly Dependency Injection. With the current core.php system already removed from the code base there is definite need to allow plugins and themes to customize core classes.
With the improved bootstrap and settings code the location of config files (and support of local.php, etc) have changed. This will require a little bit of work for theme and plugin authors. For the next release documentation should be ready to guide upgrades and changes.
There are a number of bugs that have been fixed, most notably a bug in the zen-cart admin integration, removal of debug code and a couple of edge cases in the WordPress plugin.
Well, as is usually the case, once a release is done it is time to start looking what lies ahead. We’ve made good progress on getting new infrastructure set up to organize the future development of ZenMagick. That is good for several reasons:
- It brings new people on board
- It will hopefully streamline development, which, in turn, will result in getting more done in less time
- Gives us a lot better integration of the various systems than what we’ve had so far with sourceforge (which might not actually be their fault, but could also be sloppy use of what they offer).
The next big step that we’ve taken with ZenMagick 0.9.11 is moving on to PHP 5.3. This gives us a range of great new options and also a much better choice of 3rd party libraries (like doctrine) to use.
There are a lot things we can do now, for example using proper namespaces, replacing the current core.php system with a few pre-build phar files and a lot more.
The obvious advantage of using existing libraries is that there is less code that we have to write and maintain. Ideally this will happen all within the framework, so regular users that are just concerned with templates should not have to worry.
Getting finally to a point where it becomes clear how things are going to work in the long run also means it is now time to start with some proper documentation. So far documentation was hard to do as things changed just too fast. Reminds me: if there is a good technical writer out there willing to help write some good documentation, please let us know!
ZenMagick 0.9.11 is released – finally!
It’s been a long release cycle with lots of interesting changes and I am very happy to finally have pushed this release into the wild. One thing I think I might have not mentioned before (it’s in the release notes, though) is that ZenMagick 0.9.11 (and all future releases) will require PHP5.3.
Of the changes the one I like most is definitely the integration of the zencart admin pages into the ZenMagick admin UI. it all started from a chat in the zenmagick chat room (xmpp) and some playing around with code. After that things were surprisingly easy and perhaps will be a good example of doing the same with storefront code (using ZM exclusively and loading zencart only where required).
Please be aware that there is a new bug tracker and more that we now use to coordinate development. There is, of course, also the forum for all questions that you may want to ask.
I am sorry to have to tell you that the next ZenMagick release 0.9.11 will be delayed until sometime in January 2011. It wasn’t an easy decision, but there is no way for a thorough release build and documentation before Christmas.
To be clear, there have been some last minute regression fixes, but nothing major. Its entirely to blame for me to be rather too optimistic about the spare time I would have in the last and current weeks.
So, Merry Christmas everyone – enjoy the break (if you happen to have one) and/or the snow (if you have some and don’t need to travel…)
Despite a bad cold things are progressing – slow but steady! So things are looking rosy for the promised Christmas release (becoming sort of a tradition to release before Christmas, it seems).
I’ve finally managed to fix all price related unit tests and make them pass too! The new date handling code is checked in and really simplifies things a bit. So, if you look at the roadmap for 0.9.11 things are looking swell!
Lets hope that the admin integration work does make ZenMagick attractive for a lot more people – and developers…