Last week I wrote about including a WYSIWYG plugin as default. Since then I’ve extended this to more plugins.

I still think that managing features in plugins is a good thing. However, some plugins are quite essential, so it makes sense to include them in a default package so they are there – ready to be used after installing ZenMagick.

There are still a few open spots to be filled, for example SEO, etc but I am hopeful that those won’t be too hard to fill.

As part of the admin upgrade I am looking at improvements for the plugin manager.

So far the following changes have been made or are planned:

• Simplified view
• Drag&Drop to reorder (this means hiding the sort_order field)
• Ajax enable/disable in overview
• New ‘Upgrade’ option that re-installs the plugin as part of software upgrades
• Option to keep settings when un-installing a plugin
• Popup Edit dialog (loaded via Ajax)

The popup edit dialog still needs some more specs. For one thing this only makes sense if the plugin has real options – enable/disable and sort order will be managed via the overview (see list above).

Another issue is that some plugins currently provide their own implementation. There will need to be some code to figure that out and change the link accordingly.

I still like the idea of plugins being able to add menu items as they wish. With a new menu system it is planned to provide methods/options to add items anywhere, but some of that will depend on the menu structure itself, I guess.

It was pointed out to me that ZenMagick is lacking a few bells & whistles. Well, I always thought that if I do the heavy lifting eventually there would be some users that could create some more lightweight plugins, wrapping up their theme/template work.

To encourage people to do so and to illustrate that it isn’t that hard to convert existing Zen Cart template mods, I’ve checked in two new plugins:

• flyoutCategories
  A port of the css_flyout_menu mod.
• jscrollerSideboxes
  Ported jscroller-sidebox-2.1.

It really isn’t that hard – you really should give it a go and if you need help there is always the forum. Now back to some more serious work, because these two plugins have revealed that resources in plugins (ie. .css and .js files) are not really that well integrated into the layout mananger code.
The downside of that is that they can’t take advantage of things like the minify plugin, and more…

Right now plugins can and do include template files. Mostly those files are views, sometimes storefront related, most often admin views.

For a while now I’ve been postponing to update some of the remaining currently defunct plugins to the new plugin conventions and mostly because they include sideboxes.

The old plugins would create/copy sidebox files into the default theme during the installation process. This is not very nice on a number of levels. It’s error prone (file permissions), not intuitive and generally something I never liked at all

With the enhanced support for storefront views and resources in plugins it might be time to rethink the location of views within the plugin. Right now all there is is stored in a subfolder named ‘views‘. So, in order to keep plugin folders tidy, it would make sense to have a content folder, just like themes. That way all resources, views, sideboxes, etc. would be tucked away and not interfere with the actual plugin code.

Now, if you go that far, you might ask:  Why stop here? Add support for themes! Well, then things get a bit more complicated. In particular since the id of the default theme is configurable, it’s hard to anticipate that.

Of course, it would be possible to declare ‘default’ the name of the folder associated with the configured default theme, but then things, again, become less intuitive (although ‘default’ really really is a great clue!).

So, I think I’ll change the code to expect templates and resources relative to a ‘content’ folder within a plugin. That would mean existing views folder would move one level down to ‘content/views’.

If theme specific customization is required, it is still better to copy the files into your theme and customize them there. Files in plugins should never need to be modified.

Coming back to plugins that contain sideboxes. Since the (to be) content folder is automatically included in the template file lookup [via ->fetch(...)], there is no need to copy any more. To make those sideboxes show up in the admin page, the sidebox dummy patch can easily be modified to scan plugins too.

While refactoring existing plugins I’ve taken the time to think about which ones to keep and which ones to drop (for now? ever?). Right now I am looking at the dual pricing and the price group plugins.

Two thoughts:

1. The price group plugin should be moved into storefront. There are two good reasons for this. First of all, it would mean not having to subclass ZMProducts. Secondly, it is useful and opens the door for more improvements in that area.
2. #1 actually means that the dual pricing plugin is more or less obsolete.

Opinions?

I am making quite good progress on converting plugins. However, as already mentioned a couple existing plugins might not make it to the finals.

There are mainly two reasons:

1. I do not have the time/energy to maintain all plugins any more – hopefully integration plugins for zen cart mods will be taken over by some mod owners in the future.
2. Some plugins are just too far away from what I wish they would be and in order to get a release ready they’ll have to wait.

Right now there are about 25 plugins left. Some are rather simple and I might skip testing them (in particular the integration plugins that usually consist of just the plugin class).

Among the plugins still to be done are also the Catalog Manager plugins. Hopefully the time and work I put into the new infrastructure code will pay off to those going without too much trouble

After some interesting discussions in the comments and also in the new forum, I’ve decided that I’ll add some more changes to the next release regarding plugins.

In fact, it’s a partial rewrite of how plugins generate admin UI content. Precondition for that was to convert all ZenMagick admin pages to using the MVC framework. While this is not complete it now still allows to write proper controller and views for admin pages. A side effect is that it will make it much easier to get to a point where the admin UI could be skinned similar to what themes do for the storefront.

It also means that the new plugin naming conventions will be active in the next release.

I made a small change compared to the previous proposal, though. The word ‘Plugin‘ is now expected to be at the end of the main plugin clas; for example: ‘ZMQuickEditPlugin‘. This means all classes will start with the same plugin specific prefix (‘ZMQuickEdit‘ in the example), which acts as some simple sort of namespace, I guess.

A downside to all of this is that all plugins need to be updated. On the other hand it means I really need to test all of them and I already found a few bugs in existing versions….

I’ll be publishing a new snapshot over the weekend I hope. That should also include the latest zen cart XSS patch in zc-base.

I am still working on redefining how plugin admin pages work. I’ve been going in circles for a while until I realized the reason for that is that there are right now two distinct kinds of plugins:

1. normal plugins
   Any plugin that is not a…
2. catalog manager plugin

So I figured I might start making #1 work and then see what the actual difference is between #1 and #2.

The tricky thing right now is that I don’t want to change things again once the project is in a place where the admin pages can be re-implemented. (I am still not sure if that will be evolution or revolution…).
The plan is to expire the current ZMPluginPage and ZMPluginPageController in favour of *normal* controllers, based on ZMController. In the long run that will help minimize changes required should it come to the planned admin improvements.

These changes go togther with the already implemented (but disabled) changes to support the new plugin naming conventions.

I’ve started working on the proposed change of naming conventions for plugins. Once really positive side effect is going to be that all plugins will receive a bit of polish and catching up on API changes.

Also, I already found a couple that most likely can’t have worked for some time. Not sure if people don’t need/use those or are just to lazy to report bugs…

Either way, I guess I’ll try to push this as last change into the next release. This will mean that some custom code might be broken and you’ll also need to go through your custom plugin settings to adjust some setting names…

A few days ago I wrote about the ‘ZM’ prefix and plugins. The prefix is useful but, as Raine pointed out it would be good to have something to avoid naming conflicts.

Seeing that it will be a while before we can start using PHP’s new namespaces a different solution must be found. (more…)