I’m coding a very complex plugin which it’s organized as a parent “container” class and several subclasses, where each subclass is an optional/mandatory element which usually (but not always) maps to his own add_submenu_page.
Basically, it’s a plugin with his private set of let’s call them “subplugins”.
Every subclass/subplugin has its own (big) set of add_action and add_filter. So, technically speaking, my plugin’s subplugin is a valid WP plugin, simply it’s not called directly by WP itself.
Since i planned…actually tons of add_action…I’m wondering if i should refactor my plugin using a ‘private’ Observer/Mediator pattern ie. collect all relevant add_actions to my parent class only and baking up a pattern to notify/forward subclasses of events, reducing the impact of my plugin to WP event ques.
Is it a good idea or it’s absolutely not necesssary? Can u help me with some code for the class refactoring?
tnx in advance for help,
gabriele
The event queue is fundamental to WP, so it’s pretty fast and getting faster all the time.
So, I don’t think it makes any sense, performance wise, to make your own sub-queues.
Refactoring your code so that you don’t have to make each add_action() call manually is a different matter.
So … I basically took the same approach, dont know if it is correct. I think many people come to this approach since it flows naturally forth out of using the settings api.
here: http://plugins.svn.wordpress.org/wp-favicons/trunk/includes/class-load-configuration.php
I thinks this automatically is done by most because e.g. a module: http://plugins.svn.wordpress.org/wp-favicons/trunk/includes/class-module.php corresponds to what we need to do for the settings api
here: http://plugins.svn.wordpress.org/wp-favicons/trunk/includes/class-init.php
(where the plugins check if they should be activated if they are turned on on the corresponding admin page) (and can be represented as abstract: http://plugins.svn.wordpress.org/wp-favicons/trunk/includes/class-plugin.php)
a plugin derived from the abstract plugin class then either or all : sets extra fields, defines their own admin help screen, verifies its own fields, executes admin page actions, executes client side functions such as filters
a plugin attaches itself via Addfilter e.g.: http://plugins.svn.wordpress.org/wp-favicons/trunk/plugins/sources/inc/class-module-sources-plugin.php which corresponds to a “do filter” always present in each plugin so can be a further abstract layer if multiple plugins re-use the same “do”.
and can attach to your own filters in classes at the backend e.g. http://plugins.svn.wordpress.org/wp-favicons/trunk/plugins/request/request_cache.php
adds specific filters in the plugin-add filter
So from the other side “the backend site” I defined just my own filters where each of the plugins can attach themselves to e.g. http://plugins.svn.wordpress.org/wp-favicons/trunk/plugins/metadata_favicon/inc/class-favicon-factory.php defines filters such as “Config::GetPluginSlug() . ‘search'”
So in general… I think the settings API drives us to this approach naturally.
So… then some come to the point (your question) in which you would think to re-factor your own add-actions to ‘something else’ which could be observer/mediator patterns or anything else.
But… since we followed the WordPress approach using the settings API (the whole thing above), by using this making it easy for 3rd party’s to “hook in to” actions, write their own help page extensions etc… I would stick here also with add_action just because “the rest” of the design also follows this and it make it probably easier to comprehend the whole code.
Another nice example for distributing a plugin with sub-plugins is this one.