Order of plugins pre-solution

I was told that there is some major recoding of the core in the process, I just have a little idea.

I would like to develop some plugins, like .htaccess caching and so on, but i need to control their order on events, so that for example caching would go last under all circumstances. We don’t support this, and it prevents many great plugins to be developed - for expample that HTMLPurifier would be useless if it would be second out of five plugins on onPagePrerender.

There must be some SQL query call, that gets the plugins for an event. I don’t know where this is. As far as i know, there is no ORDER BY clause in this statement, I have observed that plugis are called in order they are stored in the DB - AND THAT DOES NOT EQUAL IDs.

So, I had an idea to add some pre-solution to the next release: just ADD some ORDER BY, so the developers could control the calling order in SOME way now, until some more robust solution comes.

I would suggest to add a "priority" column and order it by that, in worst case we can order it by name, so it would be changeable in the manager. The second solution can be problematic, becouse it can change the orders in present instalations, next to the first one that would not, if the default value of priority column would be 0.

I tried to do this change myself, but did not find where that SQL call is. It looks like it has something to do with caching, i’m not sure.

I like the idea, the only potential issue I can see is that plugins can be attached to multiple events and the order of priority may change depending on what event it is attached to. For example, something may need to come first on an event such as onDocFormSave but be last in the process for onPagePreRender. (I suppose the interim solution would be to duplicate the plugin for each event, not ideal by any means but would work I think)

Still, I think your suggestion should definitely be explored ... it’s one of the problems I have faced in the past with my autolink plugin and people who use plugins like Textile.

Right, the ordering needs to be done in the intersection table between Plugins and Events. We can add the priority column without any forward compatibility problems with the new code to the site_plugin_events table and change the query in the cache_sync.class.processor.php file.

Someone will just need to come up with an interface for managing the order by event.

This sounds like a neat idea, we could have a screen that listed all of the plugins tied to a certain event and use something similar to the ajax menu sorting to sort the order of execution for the plugins. If I have time I will try to give this a look.

Quote from: garryn at Sep 28, 2006, 04:34 PM

I like the idea, the only potential issue I can see is that plugins can be attached to multiple events and the order of priority may change depending on what event it is attached to.

Is that really o big problem? The plugins will be called anyway at both/many events and my "solution" is really a quick fix, it’s more than nothing. As far as I know, it would be really usefull on onPagePreRender, that the only place where I need it.

I made a workaround for this, and that is destroying all ob_start()s and calling them again, with MY callback function. This ensures that my code will be triggered really at the end of processing. Bud this is so so dirty...

Is that really o big problem?

I wasn’t saying it was a problem, just raised it as something to be aware of that’s all.

A combination of Jason’s suggestion regarding the addition to the database and Kyle’s idea of using a modified Menu Index type interface will work a treat - this will be an excellent boost to the flexibility of plugins.

I added the field to the database like Jason said and it works great, I have started to work on the interface for setting the run order and will hopefully get it done this weekend.

Quote from: kylej at Sep 29, 2006, 06:27 AM

I added the field to the database like Jason said and it works great, I have started to work on the interface for setting the run order and will hopefully get it done this weekend.

OH, that’s great kylej, thanks a lot!
M.

I have completed a working version of this. Hopefully it will make it into the next beta, if not I will put instuctions on how to set it up in here.

Quote from: kylej at Oct 02, 2006, 06:19 PM

I have completed a working version of this. Hopefully it will make it into the next beta, if not I will put instuctions on how to set it up in here.

FYI, this is merged into trunk at revision 1607