Question

I am trying to build a basic plugin system like the kind you often find in a CMS like WordPress. You have a folder of plugins which tie into the main system’s operation through event notifications using an Observer or Event design pattern.

The problem is it’s impossible for the system to know which events the plugin wants to act upon – so the system has to load each plugin for every page request just to find out if that plugin is actually needed at some point. Needless to say, that’s a lot of wasted resources right there–in the case of WordPress, that adds up to several extra MB of memory for each request!

Are there alternative ways to do this?

For example, is there a way to load all this once and then cache the results so that your system knows how to lazy-load plugins? In other words, the system loads a configuration file that specifies all the events that plugin wishes to tie into and then saves it in APC or something for future requests?

If that also performs poorly, then perhaps there is a special file-structure that could be used to make educated guesses about when certain plugins are unneeded to fulfill the request.

Answer 1

I do have a plugin management tool, but I only every used it with predominantly procedural plugins, and with all includes usually loaded at once. But for an event-based and lazy-loading API I could imagine using shallow wrappers for the plugin management, and resorting to autoloading for the actual extensions.

<?php
  /**
   * api: whatever
   * version: 0.1
   * title: plugin example
   * description: ...
   * config: <var name="cfg[pretty]" type="boolean" ...>
   * depends: otherplugin
   */

 $plugins["title_event"] = "TitleEventClass";
 $plugins["secondary"] = array("Class2", "callback");
?>

In this example I’d assume the plugin API is a plain list. This example feature-plugin-123.php script would do nothing but add to an array when loaded. So even if you have a dozen feature plugins, it would only incur an extra include_once each.

But the main application / or plugin API could instead just instantiate the mentioned classes (either new $eventcb; for the raw classnames or call_user_func_array for the callbacks). Where in turn it would offload the actual task to an autoloader. Thus you have a dual system, where one part manages the list, the other locates the real code.

I’m thereby still imaganing a simple config.php which just lists plugins and settings like this:

<?php
include_once("user/feature-plugin-123.php");
include_once("user/otherplugin2.php");
include_once("user/wrapper-for-htmlpurifier.php");
$cfg["pretty"] = 1;

Again taking in mind that these are just wrappers / data scripts, with the plugin description for managability. One could as well use an actual register_even() API and define an additional wrapper function in each. But listing classnames seems the simplest option.

The aforementioned management tool is kind of rusty and ugly: http://milki.include-once.org/genericplugins/
But it’s uneeded if you just need a list (sql table) and no settings management. That overhead is only for prettyprinting the plugin meta data and keeping a human-readable config.php.

In conclusion:

spl_autoload() on the include_path, and a simple event->classname registry, one wrapper script each, simply included all at once.