The launch of OMP and the redevelopment of OJS 3.0 on that new codebase gives us the opportunity to tackle a bunch of improvements around our support for plugins.
Read on for some details about our plans for the near future!
Plugin support was added to OJS way back in 2005 with the release of OJS 2.0.1. It introduced the central concepts that are still used today:
- The hook registry, where plugins can register against hooks for an opportunity to interact with the system at various hook points;
- Plugin categories, such as “generic”, “importexport”, etc., each of which defines a lifecycle and API for a plugin to interact with;
- Plugin management, which is an area of the setup interface where Site Administrators and Journal Managers can interact with plugins, e.g. to access their setup forms.
Several additional plugin categories and management tools were added since the initial release, but the basic idea remains the same.
Overall this structure worked well and we used it successfully to decrease the size of the core application by providing flexibility via plugins. It also allowed us to facilitate the exchange of adaptations of the system that were useful for several users but didn’t warrant distribution to the whole OJS user community.
However, there are several things needing improvement:
- Multiplication. PKP added more and more plugins to the distribution of OJS, and as of OJS 2.4.7 over a hundred plugins are included.
- Third-party distribution and discovery. Plugins that aren’t included in the distribution were relegated to the Plugin Gallery forum; finding the newest version of a plugin would involve possibly paging through a long conversation about the plugin looking for the most recent file. There is no indication of trust or support.
- Code sharing. OJS and OMP share a lot of code, but until recently it was necessary for forked versions of common plugins to be maintained separately, such as the TinyMCE, Static Pages, and Custom Block plugins.
- Compatibility and testing. There was no clear indication of the compatibility of a plugin with respect to an application (does it work with OJS? OCS? OMP?) and version (OJS 2.4.1 and above?).
- Version control. Plugin versioning was done ad-hoc and code was not typically managed. Updates were distributed as .tar.gz files attached to forum posts.
- API improvement. The plugin category API hasn’t developed much in order to maintain broad compatibility.
Solutions for OJS 3.0 (and OMP 1.2)
OMP 1.2 and forward, and of course the forthcoming release of OJS 3.0, include numerous improvements for each of these aspects. I’ll highlight some specifics of each below:
Plugin Gallery Built Into Software
To fix the discoverability, compatibility, and trust problems, we’ve introduced a Plugin Gallery right in the application, mirroring what WordPress has done with its own plugin ecosystem.
Here is the plugin management area, similar to what was available in OJS 2.x but using more modern UI elements, and on the second tab, the discovery area where new plugins can be found and installed.
(A shout-out to @NateWr — anything that looks remotely visually attractive is generally his work.)
In the discovery area, information on any installable plugin will be available, including compatibility details, authorship, installation instructions, screenshots, etc.:
To get a plugin into the plugin gallery, developers will submit it to the PKP website. We won’t necessarily review all the plugins we receive, but there will be badges used to indicate levels of maturity and trust.
Each plugin will identify its level of compatibility with each version of the software, possibly even spanning several applications. And the discovery area will connect users to the plugin developers to help promote maintenance and improvement of the plugin — more on that in just a moment.
Using github.com For Plugin Code
We’ll be recommending (but not requiring) the use of github.com for the distribution and management of plugins. We have a few examples that serve as references for anyone curious about best practices. If you want a single example to explore in detail, try the new static pages plugin.
Implementing each plugin as a github repository provides not just top-quality revision control — but also issue tracking, pull requests, documentation, social tools, and the rest. It permits plugins to live a healthy life outside the core PKP codebase, and frees the PKP codebase from having to manage their concerns as well.
We have been moving plugins out of the application repositories in order to manage them externally and decrease the plugin count in the .tar.gz file; we’ll continue to do that.
Improved Plugin API
With OMP 1.2 and OJS 3.0 we’ve broken a few elements of backward-compatibility, removing some of the legacy code and cleaning up the plugin API. General plugin API changes are described in detail on github.com; individual plugin category parent classes have been better standardized across applications.
Possible Cross-Application Compatibility
With the plugins moved into separate github.com repositories and APIs better standardized across applications, it becomes more likely that a useful OJS plugin will also be usable for OMP. The new static pages plugin mentioned above does just that — it’s coded in a general enough way that the same code can be used for both. Less code to maintain and fewer forks to worry about. As we push more and more of our codebase into the shared pkp-lib repository instead of the ojs or omp repositories, the likelihood of this being possible for a given plugin will increase.
Automated Testing of Plugins
As I mentioned before, we’ve been doing a lot of work on automated testing.
All of these new possibilities — cross-application plugins, third-party code, and better documentation of version compatibility — will be greatly facilitated by the use of automated testing. Tests can already be included in plugins — see again the static pages plugin — and when the plugin’s code is added to the PKP repository as a submodule these tests are automatically run as part of the application test suite. This relieves the burden of compatibility checking with so many possible permutations.
In the near future we’ll be improving this further by scripting a Travis build environment for plugins where it won’t be necessary to link it to the PKP repository via a submodule, and where it’ll be possible to specify what versions of the applications you want to test with. Stay tuned for details.
OMP 1.2 and OJS 3.0 will involve some work for anyone who’s written plugins before — particularly around the front-end code, as the user interface has changed considerably. We hope that you’ll find the improvements sufficiently motivating. Watch for us to start putting the wraps on OMP 1.2, and once that’s finished, final release plans for OJS 3.0 are next.
Public Knowledge Project Team