Learning from existing plugin systems

One of the other defining characteristics of RedFeather is the fact that the core implementation comprises of a single PHP file.  Despite this, it still provides a highly extensible architecture capable of being customised and tweaked to suit different situations.  Plugins can be written to add new fields to the workflow, introduce new pages and functionality, or change the site’s appearance.  While the concept is nothing new, writing such an architecture while still maintaining the desired simplicity of RedFeather presents a distinct challenge.  By looking at existing implementations of plugin environments it is easy to appreciate the potential complexity of such a system and identify ways to simplify.

The first architectural style I analysed was the ‘hook system’ of plugin management, as used in both WordPress and MediaWiki.  In these programs, each plugin is associated with a special point within the code, known as a ‘hook’.  Each hook corresponds to a different point in either the execution of the code (for adding additional processing), or a point in the rendering a page (for adding content).  The advantage of this system is that is allows for the greatest possible flexibility while still maintaining complete control over how and where the program can be extended.

As you might expect, the code overhead associated with this system is considerable and would turn RedFeather into an unreadable mess of complexity.  Framework code would need to be written to support the processing of plugins in general, then additional code to handle each category of hook. Furthermore, every page and feature in the system needs to be written in a specific way to support the plugin environment.

The EPrints platform utilises an entirely different system which relies largely on inheritance.  Writing a new feature is done by creating a subclass of an existing one and adjusting the functionality as required.  Plugins are loaded automatically on server startup and configured using additional scripts within the cfg.d directory.  The main advantage of this system is that it is possible to entirely rewrite or extend any part of the platform, although a larger understanding of the core EPrints code.

In the interest of keeping these blog posts readable I shall continue this topic in my next post.