Just a quick note that I’ll be moving hosting – again, so a bit of downtime is to be expected in the next few days…
UPDATE: Changing ISP is done, however I didn’t have time to completely upload all files from by backup yet – not sure what is missing, though. The blog at least seems to work. I should be able to finish updating all web content tonight…
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…
I just noticed that the function
zen_get_attributes_price_factor() is using a define that doesn’t seem to be set anywhere in zencart at all.
The name of the define is
ATTRIBUTES_PRICE_FACTOR_FROM_SPECIAL. it seems to control whether to use a special price or the regular product price as base for the calculation at hand. Looks to me as if this has never been implemented properly or it is just an artefact from some code cleanup…
After some conversation in the ZenMagick online chat (you can also use pidgin, Gajim or any other decent IM client, of course..) I started playing around with the view related code in ZM.
A first result can be seen in the screenshot below. [Btw: the theme in the images is the Modern theme created by rubikintegration.com] Essentially it comes down to the following two four lines of code in tpl_index_default.php:
view = ZMUrlManager::instance()->findView($request->getRequestId());
Of course, this doesn’t really scale well, in particular if the view expects some model data provided by the controller. So, some very crude cut & paste (actually just two lines..) and we have:
$controller = $request->getController();
$view = $controller->process($request);
As proof a further screenshot:
Time for another update. There has been a lot of work behind the scenes to make contributing to the project easier. The biggest change in that respect is that we are slowly moving towards using a redmine powered system to replace most of the currently still used sourceforge features.
The new dev system is already up and running and we’ll be slowly introducing features as we go along. If you want to have a look, it’s at http://dev.zenmagick.org/.
Coding wise there has also been some progress – details follow:
- block code for sideboxes/banners
All themes (incl. the default theme) have been updated to using the new block code to display sideboxes and banners. This is (for now) backwards compatible. Once the new block admin UI is finished, this will become the preferred (and only) way to configure things.
- email preview
A basic version to preview all email templates is working and integrated into the admin UI. The is a lot of polish missing still, but it is functional.
- A lot more changes to make the languageId mandatory across API calls.
- Bug/regression fixing as usual