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…

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());
$view->setLayout(null);
echo $view->generate($request);
return;

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);
$view->setLayout(null);
echo $view->generate($request);
return;

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

Another “unscheduled” update since it seems I can’t manage a weekly update right now. Things are ticking along nicely, although there haven’t been any major developments.

Main focus (again) was on improving the existing code to make live easier for plugins. Also, a few gaps in the API have been filled, most notably the new ZMTaxClass.

Main code changes:

• Templates now have a new widget() method at their disposal to display/render widgets or widget definitions. This is mostly aimed at making custom plugin pages easier, but templates can use this too.
• Upgraded jquery to 1.4.3 and 1.8.6 (UI)
• all email content generation code is now using the new ZMEMails service – this makes a lot of email related code obsolete and a lot cleaner
• all bean definitions can now be customized via individual settings; for example this line of code would tell ZenMagick to use a custom FooBarclass to be used (with caching disabled) as product service instance: ZMSettings::set('zenmagick.core.beans.definitions.Products', 'FooBar#cache=false');
• address checking for guest checkout (and checkouts generally) has been improved and does not rely on a zencart event any more
• The checkout_payment page controller is now capable to handle basic payment types; this is still disabled since some logic and checks are still missing – still some major progress
• streamlined some ZMShoppingCart methods and further removed dependencies on zencart
• url encoded payment module error messages are now handled by the messages service, so no custom code needed any more (payment_error/error)
• more progress on making $languageId mandatory for all API code
• the product finder ZMProductFinder now supports a new flag to search active only / all products – this is disabled for storefront searches, bu means the searcher code is really useful for new admin functions

There has also been some more testing (and fixes) to integrate the current zencart admin pages seamlessly in the ZenMagick admin UI.

As far as a new release is concerned: there hasn’t been done any planning yet, but I am aiming for a new release for middle of December, so not a lot more work will be added. On the one hand that is a shame as the next release will contain less genuine admin improvements than I was hoping for. OTOH, the zencart admin integration is certainly a big step forward to making ZenMagick admin the place to go to to manage your store

Yesterday I came across a very strange zen cart failure. What happened was that on a dev site the payment options JavaScript validation was broken and the payment selection form was submitted without any checking.

Now, that is not that bad – I am sure that will happen in real live quite often. However, the page I was redirected to was completely broken (blank).

The url looked something like this:

index.php?main_page=checkout_payment&payment_error=usaepay_api&error=The+credit+card+number+starting+with++was+not+entered+correctly,+or+we+do+not+accept+that+kind+of+card.+Please+try+again+or+use+another+credit+card.&usaepay_api_cc_owner=me&usaepay_api_cc_expires_month=01&usaepay_api_cc_expires_year=10


As you can easily see from the url, the selected payment module was USA ePay but other modules will be affected too.  After some digging I noticed a strange response header: 406 Not Acceptable.

And soon enough I found that in application_top.php a very long list of $GET parameters is checked for urls and also length. Turns out that the allowed max. length is not 42 or 44, but exactly 43. Not sure why 43 is more secure than 44, but that is beside the point.

Does this mean it is not advisable to use those parameters as all? I don’t know, but on the other hand putting error messages into the url is not really necessary anyway.

Either way, something to be aware of and keep in mind should you ever have unexpected blank pages after a redirect…

Somehow, today, I started experimenting with integrating zen cart admin pages into the new ZenMagick admin UI.

While the master plan is to re-implement all required features rather than reuse, it would still be nice to have a complete interface without having to switch back and forth.

Instead of trying to describe what it looks like, check for yourself: