Through an article on The Repository, I stumbled on this blog post in the WordPress.org Make Plugins blog.
The team is calling for new volunteers (and sponsors for them), since the submitted Plugins to the wp.org plugin repository now reached over 500 per Week.
The team always had made a fantastic job, trying to keep up with the amount of the submission. Till 2023 the team was lead by Mika, who is now involved in the (in my opinion great) initiative of the FAIR decentralized plugin repository. The WP plugin team made some good changes to their workflow and tooling lately, like the “Plugin Check” plugin.
After being able to bring down the queue list to 0, why the problem now is happening again?
The “problem” – rise of AI
Short answer: AI.
With the rise of AI (assisted coding), nowadays it is easier and faster than ever to create a Plugin for WordPress. Which is, on one side, a good thing, since developers are now able to bring there ideas to market in a much faster time, but on the other side brings a huge burden to the Plugins team, since all of them have to be reviewed.
I have no plugin myself in the wp.org plugin repository (yet), but recently also have started to bring my long list of backlog ideas to life – with the help of AI assisted coding.
How many WordPress developers does it need to change a light bulb?
– An unknown wise person (not me)
None – there is a plugin for that.
Before, if I had an idea for a WordPress plugin, the bar to actually work on and release it was high. Since to code a good structured and secure plugin, it would take weeks or even months, not to forget the work afterwards, to keep it up with the latest changes from WordPress, bugs or security issues. And of course support – mostly helping your users in the forums of the plugin.
With AI that bar has become significant lower. Now even more, since there is a new official wp.org MCP server. That whole AI movement is a good thing, IF you know what you are doing and still strife for quality and security. To help me with that, I recently created my own plugin template, to use for new projects. So “automatically” it brings me features like PHPCS and PHPStan for code quality and local End-to-End testing with playwright and the fantastic WP Playground CLI.
How to handle these submissions?
Reading that articles and given the struggle the team now has again, I want to list some ideas here, that came to my mind.
Disclaimer: I’m not part of the Plugin Team and have no insights in their workflow. So maybe I don’t have the full picture or describing things that already exists.
The ideas kind of build up on one another, but of course could be implemented individually.
Idea 1: Automation – test, quality checks and code review
I’m a big fan of automation and automatic processes. In fact as Developer Experience Engineer, that is part of my job. Some automatic checks are already used, with the Plugin check plugin and apparently on submission. So what could be improved?
With wp playground and its cli, you can quickly spin up a browser based WordPress.
I’m using it in my plugin template together with Playwright, to get an easy test setup for my plugins. With blueprints, you can set up a new page, add the plugin and then run tests on it. WP.org could run automatic tests that check if the plugin breaks the site or functionalities. One step further could be to require plugin authors to provide specific tests in their plugins. But that would require a solid base setup, that could easily be integrated.
PHPCS and PHPStan are fantastic tools to check code quality and prevent the more common bugs. They are already in use for WordPress itself and could be adapted for plugin submissions.
And lastly, since the problem is mostly triggered by AI – it could also help to solve it.
Not replacing code reviews by experienced human developers, but maybe as a first check.
WordPress uses it for example in the hosted playground. If your blueprint fails to run, there is a button “Troubleshoot with AI”. That could be done either similar to how GitHub is providing it with Copilot code reviews or through a specialized service.
Idea 2: Trusted Authors
Another help could be establishing the status of trusted authors. Plugin developers that already accepted good quality plugins in the repo, could be awarded with the trust to release new plugins more freely.
It still can pop up on the queue, but maybe with a lower priority or an easier workflow.
Of course that does not prevent the case that the author getting “lazier” and hopping on to the vibe code train.
Similar to how it works with translations and the GTE role (Global Translation Editor), trusted authors could also be eligible to provide plugin reviews.
Idea 3: Automatically accept and review later
Another, probably more controversial idea, is to move the (human) review process.
Upfront on submission you still have the automatic checks, but when they pass – the plugin gets added to the repository.
For this, there could be a new tag, that tells a user if the plugin is “Untrusted” or “Unreviewed”. Later if the plugin team has reviewed the plugin, the tag gets changed to “Trusted” or “Reviewed”. Of course then there should be a link or tooltip to explain the status.
A problem with this approach is, what to do when there a problems found in the manual code review. Just push another update or revert. How would that work with sites already have that plugin?
Idea 4: WordPress sites only show reviewed plugins
Building up on idea 3 that plugins get accepted and then reviewed later (letting aside the problems mentioned), there could be a filter on that new tag.
As default set to trusted, only reviewed plugins are show on the wp.org list and in sites. But the user has the option to see and install untrusted plugins.
Idea 5: Automatic updates only for reviewed plugins
Also building up on ideas 3 and 4 is about plugin updates.
The update system with the ability to auto-update is one of my favorite features of WordPress. Even when at my work, we don’t use it, since we utilize a composer approach.
Automatic updates (or even the info for update checks), could get a filter for unreviewed plugins. So the user can update via click, but maybe not automatically.
Conclusion
The shown ideas here, can help in my opinion. But of course I’m not claiming to have the best of full solution to this.
Maybe other initiatives like the mentioned FAIR for decentralized repos or the new composer based wp packages by the roots team, are the way to go – putting the user (or site admin) more in control and responsibility.
That way it would also be easier for plugin authors to provide a more standardized way to bring their premium (paid) plugins to users.
Let me know in the comments what you think about all of this – but please be friendly.
Credits
Featured Image Photo by Daniil Komov on Unsplash.
This blog post was written by me – a human.
Leave a Reply