The WordPress directory is not having a normal year. The Plugins Team, previously the Plugin Review Team, published its 2025 retrospective, and weekly submissions have doubled and settled at roughly 330. That is close to 1,300 plugins a month arriving in the queue. Anyone doing WordPress plugin development for the directory is now standing in a much longer line.
The popular answer to that is to let AI write the plugin. AI has certainly lowered the cost of producing one; it has not moved what the review requires. So the queue fills with first-time authors submitting code nobody has read carefully, and reviews are up 40.6% to keep unsafe plugins out of the directory.
What the 2025 numbers actually say
The team reviewed 12,713 plugins last year. Approvals rose 66%, which sounds like the happy part of the report until you reach this line: nearly 4 in 10 plugins never got a reply from their author after the first review. Somebody submitted, got feedback, and walked away. If you intend to keep a plugin listed, navigating the WordPress plugin review process means answering the reviewer.
The same report counts more than 59,000 issues detected over the year. The checks are getting deeper, not lighter, and two of them are automated: an AI-assisted internal scanner and the Plugin Check plugin (PCP), which pick up everything from branding problems to direct database queries that skip the escaping layer.
A common catch: the direct database query
Unescaped input is the one the automated scans never miss, and it is not only beginners who trip it. I have watched experienced developers do this under deadline. PCP flags it the moment you push an update.
<?php
/**
* The Naive Approach: Direct DB query without escaping
* This will trigger a security flag in PCP.
*/
global $wpdb;
$id = $_GET['id'];
$results = $wpdb->get_results("SELECT * FROM {$wpdb->prefix}custom_table WHERE id = $id");
/**
* The Senior Dev Approach: Prepared statements
* Use this to pass the WordPress Plugin Development security check.
*/
function bbioon_get_secure_data( $item_id ) {
global $wpdb;
return $wpdb->get_results(
$wpdb->prepare(
"SELECT * FROM {$wpdb->prefix}custom_table WHERE id = %d",
$item_id
)
);
}
Run the Plugin Check plugin before they do
Since October 2025 the team scans every version update automatically, so a problem you did not catch locally becomes a problem they catch for you. Running PCP yourself, locally or in CI, is the cheaper order to do that in. My post on plugin standards covers what it tends to complain about.
Use the WP-CLI interface rather than the admin screen. It is quicker and it drops straight into a deploy script. There is more on the command line side in my guide to fixing WordPress via WP-CLI.
# Running a strict check on your plugin slug via WP-CLI
wp plugin check my-custom-plugin --format=json --threshold=errorThe official GitHub Action runs the same check on every push, which catches the accidents: a minified file shipped without its source, a stray eval() left in from debugging.
If plugin review is eating your week, I take this on as contract work. I have been building on WordPress since the 4.x days.
What it means for how you work in 2026
The bar for approval has not risen. The scrutiny behind it has, because the team is the same size and the volume of code is not. A plugin with unresolved flags now sits in the queue for a long time. Following the WordPress coding standards from the first commit is what keeps you out of that pile.
Scaffolding with AI is fine. Handing it the security decisions is not, and neither are the race conditions and transient handling that decide whether a plugin survives contact with a real site. Those are still yours to get right, and the directory is now checking.
