Plugins: Only allow for addition of features?

[mark]

The plugin architecture is pretty cool. I wanted to get something clear in my mind though -- and maybe this will help anyone who is thinking about developing a plugin with OJS. The architecture only really allows for the addition of features -- correct? By that I mean, if I (or someone else) wanted to augment OJS to have a feature removed (e.g., not display the breadcrumb menu), a plugin couldn't do that. This would instead require editing the PHP code directly. (??)

In theory it would be sort of cool to make a plugin called "OJS Lightweight" that allows journal managers to reduce the feature set for their journals while letting journal managers retain the full feature set of their journals. Plugins would be a candidate for this because plugins operate at the journal level. But the current plugin architecture wouldn't allow for that - it would require editing the OJS code itself and so it would make site-level modifications that would affect all journals.

Is this sketch accurate? Or am I missing details or painting with too broad a brush?

Mark

[asmecher]

Hi Mark,

This is a really tricky one that we're still trying to address. The plugin structure was added after OJS 2.0 was released, so we had to find a way to fit plugins into the existing system in a way that wasn't disruptive. As a result, there are things that plugins can't currently do easily (though with hooks it is possible to step in and change existing parts of OJS, rather than just adding new functionality, depending on what exactly you want to accomplish).

What we hope to do to increase the flexibility of plugins is gradually move some of OJS's functionality into plugins and out of the core. This is already taking place with, for example, the OAI metadata formats, citation formats, reports, and other aspects. This will make the core smaller, and will also allow plugins to interoperate with OJS functionality as peers, rather than as grafted-on bits of code that are less capable than the core itself.

It's particularly tricky to accomplish a good plugin structure in PHP, as PHP's powers of introspection are much more limited than, say, Java. We also have to keep in mind that a lot of infrastructural development can come at a cost to performance.

In other words, it's a complicated problem with lots of trade-offs -- but we're doing what we can.

To follow your example of removing the breadcrumb menu, that would currently be a tricky removal to accomplish with a plugin. We're breaking templates up into smaller pieces to make them more modular, which will eventually address this requirement (it's possible for plugins to interact with core template files fairly easily, but not pieces within a template). In the meantime, I would suggest modifying the core template to conditionally remove the breadcrumbs.

Regards,
Alec Smecher
Public Knowledge Project Team