Plugin code integration with core

[Oleg]

Existing topics about plugins talk about how they are distributed and named, sidestepping what I think is the most important issue, which is how is code from plugins going to be merged with code from the core?

Let's take a simple example. I want to display a block on the index page above the forum list. Let's say the content of this block is dynamic but not dependent on any other code used for index page. I want to make this block available as whichever mods are renamed to, let's say a plugin. Here are the changes, which are all additions in this simple case, that I want to perform:

1. I want to run a code fragment as part of generating forum index.
2. I want to pass some variables from the code fragment to my template.
3. I want to render a new template.
4. I want to position my template in a particular location on forum index.

The requirement is that there is "core" code which does not have these changes, "plugin" code which implements them, and some logic inside "core" code which would call "plugin" code at the right times with the right arguments.

My best idea so far involves decorators. A plugin may decorate any function in the core or in an earlier loaded plugin, using 'before', 'after' or 'around' modes. In before mode the decorator is called before the core function and output of core function is appended to the output of decorator. After mode is similar, and in around mode the decorator is called instead of the core function and the output of decorator is taken as final output, with decorator having an ability to invoke the core function.

Before and after only really make sense for templates; for php code around mode should do everything desired.

The small problem with this approach is I don't see how it can be implemented in php. These implementations (ok, I only read this and this) are not decorators, and evolution of the examples on stack overflow is particularly striking as wrong.

What I'm thinking of is ruby's alias_method, and specifically rails' shortcut of alias_method_chain.

[Rotsblok]

Perhaps a method like mediawiki (they "hook" into the system.. calling from their "config.php" the hooks and on what classes they hook into.).. Make it possible to "connect" into a class (if i understand correctly phpBB4 will be mostly be build on classes)

Hope it makes sense

[Oleg]

Hooks technically work but have several drawbacks.

1. Every hookable piece of code needs to have special code added to it to call the hook. Adding this code in many places is a lot of work. Adding it to every function is unlikely to ever happen.

2. Calling hooks takes time. If there are many hookable locations, the time it takes to check for and call hooks gets large even when there are few or no hooks actually defined.

Consider the template requirement of the example in the first post. How would it be achieved with hooks? Would you hook every block of every template?

Because of these drawbacks I doubt hooks can provide the kind of extensibility that is required even by existing modifications.

[code reader]

if you look at the hook system implemented by phorum, it would answer both your questions.
it is *not*very expensive (performance-wise). actually, it's extremely lightweight.
it *does* support hooking-inside-templates.

you are right in that moving in this direction requires work, but this is no different than any other architecture change. i am yet to see implementation plan for plugin system that does *not* require significant amount of work to implement.

one nice thing about such a system is that once the infrastructure is in place (and this infrastructure is laughably small), making more and more call-sites in the code "hookable" does not need to happen in a day - it can be done incrementally, as need arises.

i suggested such a system almost as soon as rhea was announced, and received an answer that a different plugin architecture is in advance stages of deployment.
admittedly i did not have as much time lately to follow the changes to the code base closely, so maybe it's already there and i didn't notice, but i did not hear much about this selected system since.

peace.

[Oleg]

I think that a system which does not require making functions 'hookable' in order for plugins to alter said functions' behavior would be preferred. Of course, if this cannot reasonably be implemented hooking is better than nothing.

I was considering having empty proxy objects implementing __call magic method to dispatch method calls to both core and plugin implementations.

[Rotsblok]

As a non coder I have little knowledge of server loads etc.. Im just brainstorming

If you add the possibility of hooking into classes how big would be the extra load.. I think it would not be so big.. as most of the time the hooks will be empty (default situation) and when adding a enhancement or plugin they just add or alter stuff. The main thing is how do you process the action after it.. that would be more generative to coop with the added parameters. But then again you just might have to store it and the constants might be significant less..

as for example plugging in a gallery with albums can use the forum database structure by simply adding a 4 value (1 to 3 are for forums,categories, linking forums) and adding a blog plugin just have to know what is free so get the largest value in the table add 1 and pass it on.. so that will be for example 5. The main structure just wants the basic stuff like a type identifier (1 to n), a name, a description and so on.. getting it out.. the basic stuff just grabs the stuff loads the plugins and they tell what what is. so the core stuff will tell he 1 to 3 are forums. the gallery will tell the 4 is mine and deals with it. and so on. The core stuff just stores his own "constants" in the db.. and there is just a simple major retrieval class.

So when viewing forums.. the class viewforum will call the retrieval class to retrieve all data.. it (viewforum) will ignore the types that are unknown to him (4 - 5) as that isn't in his "constants" table.. and processes it further.. if a plugin wants to also retrieve the albums i.e when viewing the forums.. the can just add it to the "constants" table of viewforum class and hooks into viewforum class to tell what to do with the "unknown" type identifiers. So the whole thing would become more flexible it think..

So the core files will do just basic stuff.. adding things to the db, retrieving input variables, and outputting the templates.. viewforum would be a "plugin" then as it just tells the core stuff what to retrieve from the database.. and giving the output to the core output for templates..

Hope this makes sence...

[Oleg]

I had a look at how plugins are done in MyBB, Wordpress and Phorum.

MyBB

The first thing that I curiously noted was that while mybb itself claims to be gpl-licensed, many plugins have licenses which are incompatible with gpl. Some prohibit modifications, others prohibit redistribution, and some prohibit both. Since plugins have no choice but to be derived from forum itself (by virtue of the plugins using db class, template class, etc.) I wonder how this works out.

Mybb plugins are essentially a combination of umil, automod, modx file and actual plugin code in a single file. The file defines methods for installing and uninstalling the plugin by running hardcoded db queries (which are db-specific -- mybb supports mysql only?), performing file edits (regexp find and replace -- surely can't work when two plugins modify the same line of code?), as well as using a (more extensive) hook system to get the plugin code called at desired times. Since plugin install modifies templates without user intervention I must assume either the entire template tree must be chmodded o+w or template edits are done in database only, which would create problems during updating, unless all plugins are uninstalled before updates and reinstalled later, which however unconditionally nukes db columns created by plugins, causing data loss, so hmm.

Conclusion: mybb has a more extensive hook system and questionable license practices.

Wordpress

Can you say spaghetti code? I pulled the polldaddy plugin, and it comes with a 4,000+ lines, 173,000+ bytes php file containing an ungodly mess of html, php and html-php combos that must be templates. There appear to be functions doing all sorts of things which I'm assuming is possible because wordpress provides a huge number of hookable locations and helpers to be used by plugins to integrate with wp. Just to make sure I'm not insane in thinking things don't have to be this way I downloaded 'views' plugin for drupal and it at least appears to split templates into own files, which it has more than one of.

Conclusion: I won't be installing wordpress anytime soon.

Phorum

Plugins come with manual installation instructions for editing templates, much like phpbb's mods do. The hook system is more extensive and appears to rely on autodetection of hooks via plugin/hook naming conventions. They seem to have template functions for invoking hooks as well, but clearly these are not enough due to having to edit templates manually for some plugins anyway.

Conclusion: phorum has a better hook system.

---

I'm not arguing that hooks won't work. They will, if enough effort is put into them. What I'm really looking for though is an infrastructure solution that does not require adding code for every hookable location. Or at the very least one requiring an order of magnitude less code than phorum (best so far from what I'm gathering).

[igorw]

Thanks for the review. Could you provide some links to the sources?

[Oleg]

Sure.

Mybb: http://mods.mybboard.net/view/edit-reason
Wordpress: http://wordpress.org/extend/plugins/polldaddy/ (top plugin on the plugins page)
Drupal: http://drupal.org/node/649642
Phorum: http://www.phorum.org/phorum5/read.php? ... msg-126730

Recently I've been getting quite impressed with drupal. Apparently its ticket system automatically tests any patches attached to comments, very handy. From reading a couple bug tickets development process is very solid as well.

[MichaelC]

Apparently its ticket system automatically tests any patches attached to comments, very handy. From reading a couple bug tickets development process is very solid as well.

Sorry for the off-topic note but perhaps phpBB should put this feature into their bug tracker?