Yes. Guideline 18 of the WordPress.org plugin guidelines reserves the right to disable or remove any plugin, remove developer access in favor of a new developer, and make changes to a plugin without developer consent in the interest of public safety. It promises to use those rights sparingly.
The five rights, as written
The handbook says the team reserves the right to:
- Update the guidelines at any time
- Disable or remove any plugin from the directory, even for reasons not explicitly covered by the guidelines
- Grant exceptions and give developers time to address issues, even security related ones
- Remove developer access to a plugin in favor of a new, active developer
- Make changes to a plugin without developer consent, in the interest of public safety
It adds a promise to use these rights sparingly and with respect for end users and developers.
What this means for people who run plugins
Your plugin can disappear from the directory. A plugin can be closed, and our post on what happens when a WordPress plugin is closed for security covers the practical steps. Your installed copy keeps running, but it stops receiving updates through the dashboard.
Control of a plugin can change hands. The team can replace a developer with an active one. That can rescue an abandoned plugin. It also means the people behind a plugin you chose may not be the people you checked.
A forced fix can arrive. Public safety changes made without the developer are a safety valve for serious problems. They are also a reminder that the directory team is part of your trust chain.
A practical response plan
| Event | What you should already have in place |
|---|---|
| Plugin closed or removed | A list of plugins in use, and a replacement option noted for critical ones |
| Developer access changed | A habit of reading the changelog and version notes on updates |
| Forced security update | Staging site, backups and a rollback path |
| Plugin abandoned | A rule for how long without updates you tolerate |
Keep an inventory with plugin name, version, purpose, owner on your side and where it came from. An owner is important: without one nobody notices a closure notice.
Review changes after maintainer changes
When a plugin's author listing or ownership changes, treat the next update like a new install. Read what changed, check for new external calls, and test on staging first. See guideline 8 on plugins that load code from elsewhere for what to look for.
Keep expectations realistic
The guidelines are the directory's own rules and do not constitute a guarantee about any single plugin. The handbook says it intends to enforce them with as much fairness as humanly possible. Treat directory review as one layer, and keep your own staging, backups and inventory as the others.
Safeguard offers asset discovery and dependency scanning for the software you build and run, which helps you keep an inventory current. For site plugins, the same inventory habit makes closure notices actionable.
Quick check
Will a removed plugin stop working on my site?
Not automatically. The installed code stays until you remove it, but it no longer receives updates from the directory, so plan a replacement.
Is a forced change by the directory team normal?
The guidelines reserve it for public safety and promise sparing use. Treat any such update as a prompt to test on staging.
Sources
Last reviewed: 19 October 2026.
