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.

Lately, I have been wondering if zen-cart really needs the sidebox manager. Sure, it is nice to have an admin interface to configure sideboxes. However, the question is: ‘Do we really need a GUI for something that gets touched very rarely. I would expect that for most sites this is actually a one-off thing.

So, wouldn’t it be better to leave the decision about sideboxes to the template? In fact, that would be much more in line with the ZenMagick approach of *not* supporting layout/design aspects via configuration options.

One benefit would be that it wouldn’t be necessary to create sidebox dummy files any more. Themes could have custom sideboxes, or even content that is spread across multiple files without having to worry about anything.

I guess one reason why I personally do not like the current system is that it is one of the last bits of logic that rely on files rather than code.

Oh, well, just my thoughts - luckily things work well enough as they are so there is no imminent need to change more than necessary

In my (in)frequent series of random posts I present today a small piece of code to manipulate the label of the tax order total line during checkout.

Now, that wouldn’t be soo exicting, however it doesn’t require any template changes

Let’s start with the code:

class GSTPatcher {
public function onZMViewStart($args=null) {
global $order;

$key = 'GST';
if (isset($order->info['tax_groups'][$key])) {
$order->info['tax_groups']['Includes GST'] = $order->info['tax_groups'][$key];
unset($order->info['tax_groups'][$key]);
}
}
}
ZMEvents::instance()->attach(new GSTPatcher());


So, what is happening here? To begin with, a small class is defined with a single method onZMViewStart(). As the name suggests, the method is a callback function. In order to have it called an instance is registered (attached) to the ZenMagick event service ZMEvents.

The event view_start is raised? right before the actual page content is generated. The event service will then try all registered objects for a matching callback method. If found, it is called.

The method itself is rather simple. All it does is to modify the map of order totals of the current cart (in an $order object!).

Right, another distraction! I just checked in another plugin that allows to take advantage of the recent changes to the logging code.

The plugin adds support for FirePHP by means of a custom ZMLogging implementation. Pretty neat, indeed!

EDIT: Originally I just thought it would be cool to have something fancy like this. However, as it turns out, even after using it for a day or two I start loving it. In particular with translating the errlevel to something FirePHP understands it becomes a lot easier to browse the log (with the custom error handling enabled).