What WordPress.org Reviews Before It Lists a Plugin

The plugin had five stars, forty thousand active installs, a recent update and a place in the official directory. It also had an unescaped parameter in an admin action, which is the kind of flaw that a code review finds in ten minutes and a directory listing does not promise to find at all. The site owner had done the reasonable thing: checked the signals, saw green, and installed it. The signals were real. They measured something other than what they were assumed to measure.

WordPress.org is the distribution channel for most of the WordPress ecosystem, and the plugin directory is its front door. Being listed means a volunteer review team read the submission and found it consistent with the published guidelines. That is a meaningful gate, and it is narrower than "this plugin is safe". Understanding the difference is the difference between using the directory well and treating a listing as a security audit.

The same applies to the theme directory, with a different team and a different set of requirements. Both are worth understanding, because the directory is where most sites get their code and where most assumptions about that code are formed.

Disclosure: this page contains one affiliate link, and WPSifero may earn a commission if you buy through it. The analysis is about the public review process, and it does not change based on where a plugin is sold.

The directory is a distribution channel with a review gate

The plugin directory does three jobs. It hosts the code, it serves updates to installed sites, and it provides a public page that people use to decide whether to install. The review gate sits in front of the first job: before a plugin appears, a reviewer checks it against the guidelines. After that, the directory serves whatever the developer commits to the plugin's repository.

That model is why the directory is both useful and limited. Useful, because a plugin that ignores licensing, hides code, spams links or hijacks the admin is likely to be caught before it reaches users. Limited, because the gate is about conduct and packaging, not about whether every function is safe under every input. A plugin can pass the review and still contain a vulnerability, and many have.

The correct mental model is a market with a code of conduct and a stall fee, not a certification body. The market matters because it is where the vendors are and because the update pipe is convenient. It is not a guarantee, and treating it as one is how a reasonable person installs the plugin at the start of this article.

What the plugin review team checks

The review is against the published plugin guidelines. The details change, so read the current version rather than a summary, but the categories have been stable for years. Licensing: the plugin must be GPL-compatible. Readability: the code must be human-readable, with no obfuscation. Consent: data collection and external calls need to be disclosed and, where required, opt-in. Conduct: no spam links, no forced branding, no trialware that holds features hostage, no trademark abuse.

Packaging is checked too. The plugin needs a valid readme, a stable tag that points at a release rather than a development branch, and a repository layout the directory can serve. The readme is not decoration; it is the metadata the directory displays and the update system reads.

=== My Plugin ===
Contributors: your-wordpress-username
Tags: backup, migration, database
Requires at least: 6.5
Tested up to: 6.8
Requires PHP: 8.1
Stable tag: 1.4.2
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

Two fields in that header are read more than the rest. Stable tag tells the directory which version to serve as the current release; a mismatch between it and the code is a common cause of a plugin that appears not to update. Tested up to is the author's declaration of the WordPress version they tested against. It is not verified by the review team, and it is not a prediction about future compatibility.

The review is a conversation as much as a gate. Reviewers ask for changes, developers resubmit, and plugins are approved, rejected or closed. The process is run by volunteers and takes time, which is why the queue is a recurring topic in the developer community. None of that changes what the review is for.

What the review does not check

The review is not a security audit. It does not test every input, trace every query or model the threat of a hostile administrator, a stolen session or a compromised update server. Those are the responsibilities of the developer and, ultimately, of the person who installs the code. A plugin can be guideline-compliant and still be vulnerable to a flaw that a security researcher finds a month later.

It does not measure performance either. A plugin that adds fifty queries per page passes the review, because the guidelines are about conduct and packaging, not about query budgets. It does not test accessibility, browser compatibility or the upgrade path from older versions. It does not assess whether the developer will still be maintaining the plugin in two years.

The most important gap is updates. The review happens at submission; later releases are published by the developer without a fresh review of every change. The directory trusts the developer to keep the plugin compliant, and the security team acts when a vulnerability is reported or a plugin is found to be abandoned or malicious. That model depends on the developer, which is why the identity and history of the author matter as much as the listing.

How updates reach a site, and why that matters

WordPress checks for plugin updates against the directory's API and downloads the package from the plugin's repository. The developer tags a release, updates the stable tag, and the update appears in dashboards. There is no per-site approval from the directory and no signature that proves the update is the one the developer intended to publish. The trust is in the account and the repository.

That makes the developer's account security part of every site's supply chain. A compromised developer account can publish an update that reaches thousands of sites before anyone reviews it. The ecosystem has seen this pattern, and the defence is not the directory; it is the practice of updating on a staging copy, keeping backups, and watching what changes.

It also means that "last updated" is a signal about activity, not about quality. A plugin updated last week may have shipped a regression; a plugin updated two years ago may be stable and complete. The useful question is whether the update addressed a security issue, whether the changelog is specific, and whether the plugin is still maintained at all.

The theme directory runs a different process

Themes are reviewed by a separate team against the theme review requirements, which cover licensing, code standards, the use of WordPress APIs, the absence of hidden links or upsells in the public theme, and the expected files. The review is more structural than the plugin review because a theme is mostly templates and styles, and the failure modes are different: a theme that writes to the database on activation, a theme that bundles a plugin, a theme that hides a footer link.

The directory also carries tags such as accessibility-ready, which correspond to additional requirements. A theme with that tag has been reviewed against them, which is a more specific claim than "listed". Block themes have their own expectations: a theme.json, templates, and the site editor as the primary editing surface.

Premium themes sold outside the directory are not reviewed by this team at all. That is not a criticism of premium themes as a category; it is a statement about what the listing does and does not tell you. A commercial theme's quality is a function of its vendor, its changelog and its support, not of a directory badge it never had.

Reading a plugin page like an operator

The public page carries several signals, and each one answers a narrower question than it appears to. Read them together, and treat any single one as insufficient.

The support threads are the most underused signal. A plugin with unanswered threads about the same fatal error is a plugin with a maintenance problem, regardless of its rating. Read the last page of threads, not the first, because the first page is where the resolved questions are and the last is where the current ones are.

For anything that touches payments, personal data or authentication, the listing is not enough. Read the code, or pay someone to read it, or choose a vendor whose code you can inspect and whose security process is documented. That is a higher bar than most sites apply, and it is the bar the risk actually requires.

What this means if you publish a plugin

If you are the developer, the review is a floor rather than a finish line. Read the guidelines before submitting, use a readme that states the requirements and the licence, keep the stable tag honest, and ship a changelog that says what changed. Treat the repository account as a production credential: two-factor authentication, a short list of committers, and a process for releases.

Maintenance is the part the directory cannot enforce. A plugin with no updates for two years is a plugin that will eventually be closed or abandoned, and the users who installed it will be the ones who notice. If you stop maintaining a plugin, say so in the readme and point users at alternatives. That is a better outcome than silence.

For commercial extensions, the marketplace route is separate from the directory and has its own review. WooCommerce Marketplace is where many paid extensions for stores are listed, with vendor review and a support expectation that the free directory does not provide. It is also a paid channel, so the free alternative, a maintained plugin from the directory, deserves a look first.

Where the paid route is the wrong answer: a small site whose needs are covered by a well-maintained free plugin. Paying for an extension adds a licence to track and a renewal to remember, and the directory version may be enough. The decision rule is the one this article has been building: the listing tells you the plugin passed a conduct review, the author's history tells you whether it will be maintained, and the code tells you whether it is safe. Only the last one is about security, and only you can decide whether to read it.