As some might have noticed, I haven’t upgraded the demo store since 0.9.5. Since 0.9.6 has been out for a while I decided that I’ll be skipping one release. In any case there hasn’t been too much change that would have been visible anyway.

0.9.7, on the other hand, should will have some more interesting changes, for example the currently missing ‘people who bought this also bought…’ feature.

As mentioned before, plugins will be a hot topic in the next release. Converting everything to using widgets forces me to really look at all plugins (more than just applying simple API changes).

An early warning that I’ve just checked in a massive change that will affect most/all plugins.

I’ve converted the plugin baseclass to only support widgets. That means when upgrading to 0.9.7, not only will there be new versions of pretty much all plugins, there will also be the need to uninstall and install again :<

I’ll have a think about a way to avoid that, but so far just couldn’t.

The change will make plugin related code a lot simpler and help to further improve plugin management (in a follow up change).

EDIT: I should probably add that the main reason for this change is that this way all the ugliness of converting nice short plugin options into upper case zen cart configuration defines is hidden in the plugin class. Also, plugin forms will be a lot easier in that there is no need to wrap form field names with ‘configuration[PROPERTY_NAME]‘.

As an additional benefit this allows to have options with multiple values!

The last week has been good for plugins again. Despite the fact that I have had to fix a number of 0.9.6 bugs, there has been plenty of time to improve plugins and even add a (admittedly small) new plugin.

As promised, the quick_edit plugin now uses widgets – and only widgets to render the form input fields to update product details. I’ll have to remember to update the wiki once this is live….

The next plugin to receive some attention was zm_settings. I’ve added a new option to display all current settings of the core and mvc packages. All of those are system settings (obviously!), so this is read only. The nice thing is that the code can easily be extended to show all settings, however, since it expects description text as well it will be some time before that is going to happen. Of course, after that there should be an option to edit, too…

I fixed zm_hoverbox3 which was broken due to bad cut&paste and similar happened with zm_recaptcha. The zm_recaptcha plugin also got upgraded to the latest reCAPTCHA version and a new option added to disable the captcha once a user is logged in (kind’a makes sense, I guess).

Finally, a new plugin zm_fual_slimbox has been added. This was in response to some inquiries about ZenMagick support for Zen Cart’s fual slimbox mod. The plugin took me about 2 hours and shows how easy it is to do! I might add that the plugin is a little simpler to set up IMHO.

As mentioned there have been some fixed for rather annoying bugs in 0.9.6, so make sure to check the bug reports every now and then or subscribe to the bug tracker RSS feed.

I had a question today about how to get the fual slimbox mod working in ZenMagick. Since I’ve done lightbox and hoverbox3 integration before, I figured it wouldn’t be too hard.
Turns out I was right , so as of a few minutes ago there is a new plugin in the repository to allow using Fual Slimbox.

I’ve tried keeping things as simple as possible, so in contrast to the original mod there is no additional HTML generated. All required is to add something like <code>rel=”lightbox” to image links as required.

I probably won’t release this standalone, but as part of the next ZenMagick release…

EDIT: The theme is now available in the themes section for 0.9.6 downloads.

Today I’ve had the pleasure to find a new, contributed theme in my inbox!

The theme is based on the precision theme with a focus on providing a clean, CSS based valid three column layout. Best of all, it’s already used, so a preview is already online [the version I checked in has a slightly different colour schema, though]

I’ll try to make this available for download ASAP (meaning this could take a few days…). Thanks you David for your time and dedication and Host Western Slope for making the code available.

Widgets as a concept have been in ZenMagick for some time. However, they never really took off so far. Mostly, I blame myself for this. Since I added them I had all these plans of how they could be useful.

Now, with ZMBeanUtils having matured widgets have a chance to to wake up from their hibernation. I’ve already added a few more form widgets and there are more to come. Also, more store specific widgets will be added (at least that’s the plan).
Right now the only place where widgets are properly supported is plugins. The settings plugin really depends on it and soon I’ll be converting the quick edit plugin to use widgets rather than custom (and cumbersome) functions to control the form input fields. Once that is done, both plugins will be more powerful than ever and also easier to customize.

And again, for people to lazy to read the changelog, my weekly update.

Since my last update I’ve spend most of the time fixing regressions from previous changes and also working on lots of smaller things, to numerous to list all.

• added a new ZMRequestHandler interface
  This optional interface may be implemented by plugins to get a reference to <code>$request</code> during their init (actually, this adds a new method <code>initRequest($request)</code>)
• fixed an issue with the page navigation/pagination when filter are used on category pages
• cleaned up init plugins
• as per my previous post I fixed the openID plugin and upgraded to the latest openidenabled version
• removed a couple more dependencies between core, mvc and store.
• improved the settings plugin, added a new text are widget and support to create settings using it
• moved some generic code into the form widget base class
• moved the widget code into mvc
• continued improving the development environment, in particular testing with both Windows and Linux
• checked in initial version of a new plugin to allow to tag products
• added the ability for plugin controller classes to force a refresh of the plugin page; this is good as it avoids having to do that manually after a data change performed by a plugin controller

Overall,  I am quite happy about the improvements, in particular the fact that this includes a number of plugins.

During my process of reorganizing my dev environment I finally managed to set up a new local openID test server. That lead me to discover that the plugin is currently broken!
I’ve no idea right now if it works in 0.9.6, so, please, please let me know if things are broken and I’ll see that they get fixed.

However, I suspect that the code refactoring for 0.9.7 is partly to blame… Either way, I’ll take the opportunity to also upgrade the plugin to the latest version of the used openidenabled library.

Apologies to everyone having trouble with this.

One sideeffect of using ZenMagick’s core.php feature is, that it is a great tool to validate PHP code during massive code refactoring.

The way it works it makes sure that all code is loaded for every request. That means it’s great to verify that:

• PHP syntax is correct in all code
• there aren’t any duplicate classes or functions
• in some cases code behaves differently when loaded all in one go

Other times it’s a pain, though. Right now I’ve been investigating an issue with firing events that works without core.php and breaks using core.php. Usually, these cases require some debug code to figure out which exact implementation is used and then adjust the initial order of classes in core.php :/

Another week and the code cleanup is reaching it’s first milestone. The move from core to lib is complete and both core and mvc now are as clean as possible. That means it’s possible to use core all by itself and mvc (admittedly, there isn’t a lot in there yet) on top of core.

So now it’s down to regressions – I’ve mostly fixed the core.php feature (it was working at one stage but seems at least a bit broken right now).

I also suffered from forgetting to check in moved classes a bit which meant that across my different environments (and locations) this caused a bit of distress…

The last bit of refactoring for this phase concerned ZMRequest and the fact that is currently is a singleton [kind of, at least]. I’ve split the class into a mvc base class and a store specific subclass.

After a short phase of regression hunting I’ll move forward with some of the planned new features. More specifically, I’ll start working on a product association handler to allow to tag products (categories might come at a later stage). I am sure this is going to be quite useful (and I know already of some eager to use it