I’ve just update the ZenMagick tasklist with a new item. The planned change is around ZenMagick settings.

Settings have been around since the very beginnings of ZenMagick. and I am going to keep them. Still, some more thought should go into the names and I intend to rename pretty much al of them

Luckily, there shouldn’t be a lot involved for users as most settings are uses internally. So, except for some minior changes to local.php nothing more should be required.

My hope is that this change will allow to build a useful UI to manage settings, even if it was just to display them including some useful explanation. I haven’t worked out all the details, but I am optimistic that there should be support for legacy settings (at least for a while).

Yes, it’s time again for the traditional release anouncement anouncements.

I’ve got a few spare minutes and thought I do a quick walk through the changelog.

• Code cleanup
  There has been quit a bit of work in that area, in particular plugin admin / storefront views and controller are now a lot simpler to implement
• ZMDatabase migration
  I’ve finished the migration of all services. There are still a few plugins using $db and also one or two other classes that need database access. However, the bulk is done and the rest will move in their own time.
• plugins
  Lots of fixes and improvements. A lot of that can be attributed to writing more unit tests, in particular for plugins.
• Logging
  Logging code moved into it’s own service. This allowed to easily create a new plugin to support FirePHP.
• exceptions
  There is now code to gracefully handle exceptions thrown in controller classes. Support for views is still outstanding but hopefully not far away.
• result list
  The result list related code has been greatly improved.
• search
  There is a new search tool (ZMProductFinder) that neatly wraps the current search. More so, it allows to integrate search into the result list concept. As a result there is a new simple search page using those new features.
• tests
  Heaps and heaps more and better tests! It’s fascinating to see how writing test cases for existing, apparently good code, can help to improve ZenMagick even more!
  I also spend some time giving the test UI a nice tree view for to structure the available tests and allow to run individual tests.
• orders
  The order code [at least for the current set of features] does not depend on zen-cart any more. That means it is faster and more consistent. It also means that now all columns of the orders table can be updated via the order service.
• quantity discounts
  This has been integrated into core, so the current plugins is going to be obsolete soon.

Discounts based on quantities are a standard zen-cart feature. For some reason this has never been implemented in ZenMagick and thankfully the available plugin has taken care of things so for.

As it is the only contributed plugin, I have been very hesitant to integrate quantity discounts into core.

However, I figured I should perhaps do this before too long and though, oh, well, just grab the plugin code, massage it to what my coding/formatting standards are and be done – wrong!

After some research in the zen-cart code I found that there are actually quite a few things the current plugin does not support. First of all, the plugin will do percentage discounts, no matter what type is set up. Also, that discount will always be based on the base price, so specials are not handled properly.

Doh, seems I should have looked at this earlier, but then, no one seems to be affected by this, so I wonder if quantity discounts are actually a more esoteric feature (I suspect that this is related to the small user base, though).

Anyway, the next version will include full support for all available quantity discounts. Again, unit testing helped tremedously to keeo me sane while comparing zen-cart and ZenMagick results.

I think one of the more useful plugins I can still think of would be some sort of collection of developer tools.

The plugin would most liklely start by wrapping up the language tool, console and theme builder. However, that would still not add any value, so I’d be interested to hear about other things that would be useful.

So far I was able to come up with the following list:

• Database mapping GUI
  This would replace/extend the current CLI app to generate mappings
• Skeleton builder for new pages
  Something that creates an empty controller, mapping and access rules, an empty view file
• Form validation rule builder
  Something to interactively generate validation rules that can be cut&paste
• Service wizard
  A (meta) builder that would be able to generate a new service class for a new database table. It would create support methods for the typical CRUD operations

Anything else???

As you can tell from the more recent posts, a lot revolves around plugins in ZenMagick.

With the core store functionality pretty much set (except for the database access code and the service classes that use it), most new stuff happens in plugins.

I have started building plugins that build on top of others (optionally) and that creates some new challenges. A good example would be the token service and the (still to be released) auto_login plugin which will be able to use that token service to avoid having to store the users password (even though it is just the hash) in a cookie.

While it is possible to write conditional code for this (and have plugin config options), there are cases where this does not alwasy work so well.

Two examples are test cases and cron jobs.

At the moment unit tests and cron jobs (I think there is currently only a single plugin that offers that) are included in the plugin package and typically are resepectivley located in a tests or cron subfolder.

While this works good with the cron and tests plugins installed, there is one case where things break: core.php.

Currently, a plugin would check in it’s init() method if the tests or cron and depending on that load the plugins test and/or cron classes.

In the case of using core.php, this is decrepit as all classes will be loaded in any case. This can create conflicts if the test and cron job base classes are missing.

With the current loader code I can see a few possible solutions here (none of which I really like):

1. Optional plugin code could be stored in files with a different extension.
   The loader would need some more code to allow to register class files with different extensions
2. Move those classes somewhere else
3. Provide optional dummy base classes in core

With the first option, things become more complex without a lot of benefit. Also, I’d have to figure out how to enable syntax highlighting in vim

The second is perhaps ok for tests, as there could be a separate group for plugin tests in the test plugin. However, that means to split up the code into different plugins which is not very pratical. Also, in the case of cron jobs it’s even uglier.

The third option is the worst and I just list it here for completeness. Adding code in core that is plugin specific is definitely not something I’d like to consider at all.

So, at the moment the first option seems to be the best in terms of keeping things separate and also using existing features (the loader in this case), even at the cost of additional code to support this.

If anyone can thing of other ways of handling this I’d be happy to hear those. However, considering that there is only a single third party plugin I won’t hold by breath

I am not sure what it is this time, but the zenmagick.org domain ceased to exist – sigh. I hope this does not cause too much trouble. I’ll write an update once I know more…

EDIT: All good again – seems like the domain renewal did not work as expected. Again, good and prompt service from hostingdirect!

Despite some odds, I managed to improve the GUI for the ZenMagick unit tests quite a bit. Most importantly, it is now possible to run individual tests (read: methods) of a test case (read: class that extends ZMTestCase).

I have to say that, even though simpletest does allow all sorts of customizations, it’s not very straightforward and logic is not always were I was expecting it. In some cases, it also suffers from the fact that some details (for example line numbers) are not really accessible via the official API. I do hope that this will change in future versions as there is a lot of potential for improvements in that area.

Since the first version of the GUI does not scale well with a third level of dependencies, treeview saved the day!

So, her’s what it looks now:

Unit Tests organized with treeview

I’ve just checked in some changes that allow the auto_login plugin to use the token service plugin.
The way this works is that not the user password is stored in the cookie, but a generated, time limited hash value (the token). The association of the user and hash value are stored in the database.

Also, this removes the need for storing the user id in the cookie, which should make things also a bit more safe.

The trickiest bit of all this is actually that the token plugin needs to be sorted in a way that it is loaded before the auto_login plugin, but that is trivial using the sort order in the Plugin Manager. (This actually reminds me that I always wanted to have a nicer Plugin Manager interface. Maybe now would be a good time….)

Please note that the wiki pages will hopefully be updated once the plugins are live!

Next on the list of things to do with the token service.

I am currently looking at writing a plugin to add support for phpBB3. While reviewing the code of the phpBB2 plugin I realized that giving the user the ability to change the nickname does actually not make not a lot of sense, as it is read-only in phpBB!

So, I have changed the default template to just display the nickname rather than allowing to edit.

(Actually, I might change that back [or at least to some conditional logic that allows entering a nickname if the field is empty]. That way people could get signed up even at a later stage, rather than having to register separately)

wiki work

As some might have noticed I started reorganizing the plugin repository. Since plugins are one of my main focus for current and future development it seemed like a good idea to make this section more useful.

Also, even though most plugin pages do look a bit empty right now, I will try to make en effort to improve those over time. I think it just needs some time to getting used to a system where code changed do not only require source code documentation (for the generated API docs), but also some time to document things in the wiki. However, it would be great if anyone could give me a helping hand…

checkout code

On a different tak I have decided to spend some more time improving checkout related classes and code. Since most checkout classes are wrapper around existing zen-cart classes and data this will be a longer process and I expect this to take at least a few minor releases.

search

Also, there is already some new code to wrap the search logic in a way that is compatible with the result list code (the new improved version, that is ). Again, not quite there yet, but already looking good. Another good example where unit testing is a great tool to stay sane!

Once this is in place it should be much easier to customize the search and perhaps improve the results a bit.

new plugins

There are going to be a few new plugins for the next release. The list is not final, but so we’ll have:

• firephp
  A plugin that implements logging using FirePHP.
• Who’s online
  I decided to extract this code from core as I haven’t seen too many sites using it
• phpBB3
  This is not finished yet, but it looks like it will be ready for the next version!

tasklist

I’ve added a few things to my tasklist for 1.0.0. Some is just fun stuff (like widgets), other things (for example the product list default sort) would be really good to have.