Yesterday, May 5, 2026, I celebrate 3 years as part of the WordPress.org Plugins Team. And this last year, the third, has undoubtedly been the most intense, the most beautiful and the one that has most changed the way I understand what it means to contribute to an open source project of this scale.
Let’s see what has happened all this year. Not so much to do the math (although there are), but because when you’re in the day-to-day going through plugins, programming tools, and responding to the queue, sometimes you forget to look back and see how far you’ve come. And this year we have come far.
Tabla de contenidos
The context that changes everything: shipments have skyrocketed
There is a fact that puts everything in perspective. If you look at the history of new submissions per week to the directory:
- In 2022, 2023 and 2024 the average was around 100-150 weekly shipments, quite stable.
- In 2025 we increased to 200-330 shipments per week.
- So far in 2026, we are already at 400-560 weekly shipments.
In other words, in two years the number of submissions to the directory has multiplied by 4-5 times. And the team has not grown at the same pace. This explains why this year has had the focus it has: if we continued doing things as usual, the system would collapse. We had to change gears in tools, automation, AI and processes.
The figures for the year
Between May 5, 2025 and today, in this third year I have dedicated to the Plugins Team:
- 6,335 plugins reviewed between new and replies to authors (3,161 new + 3,174 follow-ups)
- 1,482 plugins approved and published in the directory
- 144 plugins rejected for not complying with the guidelines
- 165 days dedicated to the development of internal tools for the team
- More than 911 hours of work recorded in these 12 months
- 337 active days on the computer (practically every day of the year)
Each of those 6,000+ plugins has an author, an email, a full report, and sometimes a conversation behind it so that the plugin can move forward safely for the millions of people who use WordPress.
Plugin Check (PCP): 1.5 to 1.9, and 2.0 just around the corner
Apart from reviewing, the project that I have focused the most on this year has been Plugin Check, the official tool that helps developers check if their plugin complies with the directory guidelines before submitting it. We started the year in version 1.5 and have reached 1.9.0, but the most important thing is right in front of us: PCP 2.0 with built-in AI for authors.
In this year’s versions, we’ve added:
- New checks: Bad language readme detection, nonce verification, prohibited feature detection, external URL analysis, filename validation, third-party license check, duplicate file detection, privacy policy validation, and many more.
- Check plugin running on updates: until then it only ran on new shipments. It now also validates updates, which fills an important hole.
- CTRF mode and standard output format for integration with CI/CD.
- First AI integration (version 1.8) to detect plugin names that infringe trademarks.
And now comes the big part. PCP 2.0 will bring AI to full review for all authors. The idea is that any developer, before sending the plugin, can pass PCP to it locally and receive intelligent feedback on everything that a human reviewer would tell them: possible security problems, bad practices, incompatibilities with the guidelines, suggestions for improvement. A first smart, accessible, free filter available to anyone in the ecosystem.
If you put PCP 2.0 in the context of the shipment growth I mentioned earlier, everything is understood: it is the only way for the directory to continue operating at this scale. And it is also what I am most excited about at the moment.
A BACKDOOR IN 22 plugins and a potential of 180,000 websites that could be compromised
In April of this year we experienced one of the most compromised episodes this year: 22 plugins infected with a backdoor affecting more than 182,000 websites. The supply chain had been compromised — plugins purchased from Flippa with dormant code that was activated months later.
This incident makes us think that we should be more and more aware of plugin updates. We have been working on it for some time since last year with different meetings at the last WordCamp Europe. And currently Plugin Check already runs on updates, in the absence of the report being sent to the authors. This would be the beginning for the authors themselves to review their plugins and act on their security.
In fact, this was one of the projects we discussed with Matt at the WordCamp Europe pass.
The name change: from Plugin Review Team to Plugins Team
In July we published a very symbolic one: the change of the team’s name. We went from Plugin Review Team to Plugins Team. It seems like a detail, and it is, but it also reflects something important: the team no longer just reviews plugins. Maintains the directory, develops tools, defines policies, manages ownership, responds to certain security incidents, and trains new contributors. The name had to be adapted.
The internal tools: Team Tools plugin and the Reviewer Dashboard
A very important part of the work this year has been to build tools for the rest of the team. Things like:
- PT Tools / PRT Stats: a plugin with dashboards so that each reviewer can see their own statistics and the whole team can keep track.
- Chrome extension for HelpScout (the tool where we manage emails with authors), with buttons to copy links, manage ownership issues, count plugins, set custom timeouts, and more.
- A Reviewer Dashboard to automate part of the workflow and give visibility of the queue in real time.
- Automated stats that run in cron to see directory trends (daily submissions, published plugins, approval rates).
- Import of historical stats to have a complete time series of the team.
I use them and the rest of the team uses them daily. It is an invisible job but it helps to review the effort of the team is enough and if more members are needed. And with the current level of shipments, without these tools we would not get there.
Skills for agents: the new frontier
At the end of the year, already in 2026, we opened another line: skills for AI agents. We started by creating the skill wp-plugin-directory-guidelines in the official WordPress repository, and then added the WPORG compliance skill.
The idea is simple but powerful: that any developer who uses an AI agent to program plugins can load these skills and get the agent to know the WordPress.org guidelines from the first prompt. That vibecoding for WordPress comes out well by default, not by chance.
It’s the other side of the same coin as PCP 2.0: if we can’t check everything by hand because of the scale, what we can do is make the code arrive better from the source. AI at the service of the author, not against him.
Posts published in make.wordpress.org/plugins
During the year we have published quite a bit on the team’s blog. Some posts I’ve worked on:
- More plugins submitted this year (May 2025)
- Doubled submissions this year (May 2025) — even then you could see the trend that has now skyrocketed
- New Plugins Team name (July 2025) — the name change
- Readme in Spanish required (July 2025) — an important policy change
- WCUS Plugin Stats (August 2025) — to bring to Portland
- PCP running on updates (October 2025)
- Automated Tests for Developer Blog (December 2025) — collaboration with the Developer Blog
- Team Recap 2025 Plugins (December 2025)
- 22 Plugins Infected, 182k Websites Compromised (April 2026) — The Backdoor Incident
Events: four WordCamps
This year I have been to four events as a contributor:
- WCEU 2025 (Basel) — Contributor Day and meeting with Matt Mullenweg
- WordCamp Madrid — Contributor Day and Plugin Workshop
- WordCamp Malaga — Contributor Day
- WordCamp Galicia — Contributor Day
Each one with its own flavor, but all four with the same feeling: the open source people who come to these sites are the best that this project has.
Recruit and train the team
Another front this year has been to incorporate new members. The team has grown, and that means interviewing people, training, onboarding, giving feedback, and working side by side with new developers. Work that does not appear in the numbers but that is essential for the team to be sustainable – especially with the volume of shipments we have now.
Thanks, Hostinger
And here I want to stop to say thank you.
All this work – the 911 hours, the 6,335 plugins, the developments, the posts, the events – would not have been possible without the sponsorship of Hostinger, which has been supporting my time dedicated to the project for some time now. In WordPress’ “Five for the Future” model, sponsorships are what make it possible for people like me to put in real, consistent hours on the project, rather than stealing time from nights and weekends.
Hostinger has not only funded my time: it has understood that contributing to WordPress.org is contributing to the entire ecosystem, and in the end it is also good for its customers and for the open web. Thank you truly. Without you, neither the Proactive project, nor Plugin Check 1.9, nor the next 2.0, nor any of the internal tools would have existed in the calendar that existed.
And the team
And of course, thanks to the Plugins Team. Working with a group of people spread all over the world, with impossible schedules, who have their backs, who debate difficult decisions with respect, and who have infinite patience with plugin authors, is a privilege that you don’t see every day.
On to the fourth year. And go for 2.0.
