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.

Well, this week was dominated by more cleanup in the MVC code and improvements to plugins.

After some unsuccessful attempts to patch the zen cart installer I picked up a suggestion by Raine about coding conventions. In particular plugins are not well covered so far. I did some coding to see how easy it would be to implement the new conventions and, not surprisingly, it wasn’t bad at all!

So, the code to enforce the new conventions is in place, it’s just disabled. Why? Because it means *all* plugins need to be updated in order to work with the new code. I’ve actually started converting them and I am up to 13, still counting.

So, depending on how many plugins UI manage to convert I’ll decide about enabling the new code or not.

I’ve also spend some time looking at potential admin themes, but nothing more has happened so far. Since it looks like nobody has a real opinion on this I might just go for something I fancy

Working on plugins again has yielded some unexpected benefits – I finally have a good reason to go over all plugins and bring them up to speed with code changes where required. It doesn’t mean that all are broken, but there a re quite a few that still use old/deprecated code. In particular I am working on getting some reasonable code together to make adding admin pages as simple as possible.

Accessing plugin contents from store code is also on that list. That will allow templates to reference / include plugin files either as plain files or as URL. Will be interesting to see how that goes with the new Savant views…

Oh, and I spend a bit of time finding a bug that eventually turned out to be calling a __construct() method on a parent that didn’t have a constructor! Sigh…

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…)

The naming conventions currently state that only core classes should use the ‘ZM’ prefix for class names.

I think that this is not correct. The prefix is part of the unique loader concept in ZenMagick and prohibiting the use of the prefix outside core would take away some of that for advantage.

The prefix is there for two main reasons:

1. It helps avoiding name conflicts with zen cart code.
2. The prefix allows the loader to resolve the actual used implementation at runtime.

Taking away the second from plugins would actually mean that it would not be possible to further customize plugins without changing plugin files.

Perhaps the rule should be changed to something like:

‘The first class to implement some feature should use the ZM prefix.’

That way, all code further down the road can easily extend/replace the class using regular loader features.

Seeing that there hasn’t been a lot of feedback (read: none) regarding my question about an admin theme, I’ve done some digging and found that themeforest has a section on admin themes.

I haven’t thought about buying a theme, but since the prices are really moderate that might be an option. If anyone has a preference, again, I’d be curious to hear those….

I know I’ve mentioned this a few times already, but I am still looking for a nice new theme for the admin interface in ZenMagick.

I think to start this wouldn’t have to be a fully blown theme. Just some nice colours and a working (across the usual browers) multi-level menu would be enough.

If there are any good resources out there for something like that I’d really like to hear about them.

Just realized that I am late again with my update, so here it is.

• zc-base
  I pushed a few more patches to replace split() with preg_split(). Also I managed to improve my git skills a bit and hope I’ll never need to delete the local rep. and clone again to clean up some mess…
• website
  Added a new donations page – not sure if it will change things, though.
• forum
  The forum is slowly picking up speed. Not only that, there is already payback in the form of a few bugs found and fixed!
• build process
  I’ve refined the build process a bit more and a new snapshot incl. plugins and themes are next on my list
• other
  • My commercial work keeps me busy, although it could be more. Maybe I should be the first to use the commercial help section on the forum
  • logo/colours/branding
    I’ve got a (almost) binding offer for a logo, some colours and perhaps a few banners for the ZenMagick project. This should help make this finally feel like a real project.
  • I’ve seen a demo of the code for the new default theme. It’s looking great and will be a major attraction of one of the next couple releases. We’ll have to review how to implement this, though, as some existing themes do depend on the current default theme.
    The easiest way would be to rename the current default theme to something like ZenMagick Classic and make the used default theme configurable. We’ll see.
  • I also just yesterday upgraded to PHP5.3.1. Unfortunately no change with the message ‘Fatal error: Exception thrown without a stack frame in Unknown on line 0′ < that shows up since a few days now :/

I guess that was enough for a week (I suspect some is older, but never mind).

I’ve just checked in a couple more changes to zc-base.

Changes include more PHP5.3 fixes for using the split(...) method and also re-adding the zencart admin function zen_user_has_gv_balance(..). Somehow that got lost during one of the PHP5.3 merges.

Obviously, this means the latest snapshot will break when looking at customers in admin… So, seeing that I there is going to be another snapshot soon I might take the chance and add a set of updated plugins too…

Not sure what or when this changed, but there is now an error message at the bottom of my dev ZenMagick site:

‘Fatal error: Exception thrown without a stack frame in Unknown on line 0′

It seems to happen within the exit statement, so after some research I think it is related to error handler or shutdown handler code. Hmmm….

EDIT: Turns out that it is a bad idea to call parent::__destruct(); if that method doesn’t exist…