The Plugins and Error Handling summary from the PKP Turin Sprint, hosted by the CRAFT-OA project in October 2024, is now available.
Sprints involve PKP community members joining diverse groups to work on PKP software and support. In October, the CRAFT-OA project and the University of Turin hosted eight working groups at the PKP Turin Sprint. This is a summary of one such group’s work.
Abstract
This working group focused on addressing challenges that PKP users face with plugins in OJS, such as compatibility issues, server crashes, and error handling. Intending to create a more stable environment for users, especially those without technical expertise, the group worked on a GitHub tool for disabling plugins, enhancing plugin descriptors, and resources for plugin management.
Working Group members
- Alec Smecher, Public Knowledge Project
- Peter Reimer, hbz NRW
- Obiajulu Odu, UiT Arctic University of Norway
- Carlos del Ojo, Crossref
- João Martins
- Jonas Raoni Soares da Silva, Public Knowledge Project
- Hanna Varachkina, UGOE / SUB Göttingen
- Erwan Bourrand, OPUS – Université Paris Cité
Background
The group uses a lot of plugins. Editors can’t install them but can enable them if installed. This can cause problems:
- Plugins can crash the whole OJS instance sometimes
- Some plugins have different expectations of PHP versions on the server
- It’s necessary to look into the logs to figure out what’s happening, and possibly uninstall broken plugins on the server
It would be wonderful to reduce the problems caused by broken plugins to keep the site running.
It is possible to install third-party plugins that will create different kinds of exceptions. This problem arises mostly when new versions of PHP are installed and the currently installed version of the plugin is not yet compatible.
Goals
- Exception handling on integration points – e.g. hook calls
- Tool to disable a broken plugin (Done here!: https://github.com/PAYS-upcite/manage_plugin_tool )
- Semver information and application into version.xml plugin descriptor.
- Create a post on the support forum to capture other use cases/experiences, so that we receive good feedback from the community. Crowdsource it from the sprint plenary. In addition to the forum, it might be interesting to check the survey results (search for “plugin”): https://zenodo.org/records/10853503
Discussion
Developers prefer different tools for development environments. Some chose VS Code, as it allows easy containerization and has useful features like email capture. Others prefer Spacemcs or VIM. Managing and upgrading plugins is a frequent challenge for PKP users without a strong technical background.
Examples:
- Inline HTML plugin caused an error after a server upgrade to Debian, which is not compatible with older PKP standards.
- Custom locale plugin failed after filesystem template changes.
Finding and interpreting error logs can be difficult for some members of the PKP user community. Upgrading outside of a controlled environment or sandbox can make troubleshooting very challenging. Some things that could provide support are:
- enhanced plugin visibility
- automated tests
- error-capturing mechanisms
- Visibility improvements and updates on the plugin compatibility page
- GitHub’s manage plugin tool for enabling and disabling plugins efficiently.
Relevant issues/discussions:
- Disable plugin upload
- https://github.com/pkp/pkp-lib/discussions/9559: Probably too generic discussion for the group, the issues below are a better fit.
- Handle plugin exceptions (Jonas self-assigned and converted to an issue https://github.com/pkp/pkp-lib/issues/10514)
- https://github.com/pkp/pkp-lib/issues/7308: Probably can be updated/closed, regarding the “behaving well during upgrades”
- Extra settings for the version.xml (checking the application/PHP/extensions compatibility)
- https://github.com/pkp/pkp-lib/issues/5255: Not important, but if it has a cheap fix, it’s doable to do it while inspecting the code
- Problem when a plugin exists only in the database, perhaps not suitable for the group
Plugin development Resources:
- Plugin guide: Contains documentation on writing and releasing plugins
- Release notebook: Contains developer-oriented information on each new release. For example, how do I make my 3.3-compatible plugin ready for 3.4?
- Good code formatter: PHP CS Fixer. Suggest running all your PHP through it!
Results
- We coded a plugin that will break the system in different ways.
- Repo: https://github.com/asmecher/worstPluginEverPlugin
- The different ways it can fail can be switched on/off in the config.inc.php file.
- The plugin was originally developed for OJS 3.3, and then we created an upgrade path to version 3.4
- We created a PHP script that will deactivate a plugin from the command line in case the backend is not available anymore
- In the version.xml plugin descriptor, Erik worked on adding smarts so that OJS knows whether the plugin is compatible or not.
- Jonas worked on catching and handling errors in hook registrants (the most common case where plugins will break): https://github.com/pkp/pkp-lib/issues/10514
Next Steps
Gathering community feedback through the PKP Community Forum
Thank you
We once again thank the Sprint host institutions, and all participants for their valuable contributions to the PKP user community. Special thanks to the CRAFT-OA Project and the University of Turin for their support and partnerships.
