Plugin pollution: feature or bug?

[garyamort]

One of the weird things I've found with Joomla!, the CMS[as opposed to the platform] is that with one exception, plugins suffer from cross-category pollution.

As an example:

JPluginHelper::importPlugin('content');

$results = $dispatcher->trigger('onContentPrepare',...)

Fairly intuitive that this will trigger all the enabled content plugins which have an onContentPrepare method. [I'm lying here for the sake of simplicity, actually onContentPrepare content plugin methods will run, it is up to the developer to not do anything when disabled]

And

// Trigger the onAfterDispatch event.

JPluginHelper::importPlugin('system');

$this->triggerEvent('onAfterDispatch');

Again, intuitive, all enabled system plugins will trigger their onAfterDispatch method.

What is not intuitive to me, is that if I have a Content plugin which contains an onAfterDispatch method - when displaying a content item[ie when the content plugins have been loaded] - my plugin's onAfterDispatch method will be executed.  While the rest of the time it will NOT be executed.

This is because the dispatcher is merely a list of events with no context as to which group they come from.  The group only controls if/when they are loaded, it doesn't control which ones are run.

So I've wondered for some time, is this considered a feature?  That one can effectively "hide" a plugin method for one category in a different category?  IE this gives content plugin developers the ability to have conditional system plugins which run after dispatch but only when the content component is active?

Or is this a mistake?

BTW, the one exception to this is the Authentication category.  The authenticator will load it's own dispatcher, which loads authentication plugins, and after it has successfully authenticated it triggers a complete reload of the system plugins before it allows Joomla to continue.  

-Gary

[Ken Ballou]

Wouldn't it be simpler just to look at the value of the "option" query parameter in the plugin code if one wants to restrict a plugin to certain components?

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/x7EMSO3t0UkJ.
To post to this group, send an email to joomla-...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

[garyamort]

On Wednesday, April 18, 2012 2:56:51 PM UTC-4, Ken Ballou wrote:

Wouldn't it be simpler just to look at the value of the "option" query parameter in the plugin code if one wants to restrict a plugin to certain components?

*shrug*...I dunno.  I was striving to come up with a reason for allowing  JPluginHelper::importPlugin('system'); to load observers for Content, Editors, Editors-xtnd, and other categories.

To me it's non-intuitive and problematic.  If I strongly suspect that a content plugin is mucking up the display - without needing to do any coding I can walk a non programmer over the phone through disabling all the content plugins and then re-enabling them one by one, and they can figure out which one is causing the problem.

But if there is a system plugin that has an onContentPrepare event in it[perhaps because it was originally created via copy and paste] then it's FUBAR.   I actually need to check code to figure it out.

So mainly I figured I'd ask what the reasoning is, or if it just 'is what it is'.

[Sam Moffatt]

To be honest I feel it is actually a feature that any plugin connected
to a dispatcher will respond. Authentication is different because it's
actually a chain of command pattern and I don't think it actually
resets but more visits each plugin in order and then you end up
redirecting shortly afterwards.

In a sense where you have a plugin that responds to various events it
provides the ability to build the system plugin to log various items
from all over the place instead of having to write n different plugins
for each "group" you wish to monitor. We could shift from a single
dispatcher system to using a dispatcher per type and for some of my
own code I certainly do this because I don't wish to pollute the
global dispatcher with my app specific items and it doesn't hurt
beyond maintaining your own.

Cheers,

Sam Moffatt
http://pasamio.id.au