plugins – still moving
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:
- normal plugins
Any plugin that is not a… - 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 see the “plugins” folder has multiple sub folders for different types of plugins, but is that really necessary? I mean what if the plugin does more than 1 thing or what if it does something different from all things listed? I think there should be no need to separate plugins to multiple sub categories like that.
Regarding plugin panel for ZM, please please checkout out WordPress’s one, I think it’s the best one around that is simple enough.
Comment by Raine — December 2, 2009 @ 4:57 am
You are probably right and, in fact, there are plugins that do more than one thing. Since I am rewriting a big chunk of the plugin code right now we might strip that down.
Still I’ll leave the option in – perhaps people would like to organize plugins in some way
Comment by DerManoMann — December 2, 2009 @ 10:26 am
I should add that with the current plugin refactoring the request subfolder will be morphed into general. Also, the init plugins have already been moved into store specific code in the ZMEventFixes class.
Since there aren’t that many admin plugins (and some do more than one thing, as you pointed out) they should end up in general as well.
Another side effect of the admin UI rewrite is actually that plugins do get executed in admin too. That might be ok for the page stats plugin, but for most that obviously doesn’t make sense.
For that I’ve added a generic context property to plugins to allow to specify one, or many or’ed, contexts. The plugin service will then have to figure out which ones need to run…
Comment by DerManoMann — December 2, 2009 @ 10:22 pm