The Requires Plugins header lets a plugin declare other WordPress.org plugins it depends on. WordPress then refuses to activate it until those are installed and active, and refuses to deactivate or delete a dependency while dependents are active. It matches slugs, not versions, and says nothing about whether a dependency is safe.
Definition
The header was introduced in WordPress 6.5. It holds a comma separated list of WordPress.org formatted slugs, such as my-plugin. The folder and file form, my-plugin/my-plugin.php, is not supported, and commas in slugs are not supported either.
/**
* Plugin Name: Express Payment Gateway Checkout for Shop
* Requires Plugins: shop, payment-gateway
*/
What WordPress enforces
Per the core dev note:
- A dependent plugin cannot be installed until its dependencies are installed.
- It cannot be activated until its dependencies are active.
- A dependency cannot be deactivated while dependents are active.
- A dependency cannot be deleted while dependents are installed.
If a dependency is removed through FTP or a deployment, the admin shows a notice instead.
What it does not do
| Assumption | Reality |
|---|---|
| It pins a version | No, slugs only |
| It covers plugins outside WordPress.org | Dependents can declare them, but the interface does not offer an install link and users must install them manually |
| It covers must-use plugins | Not officially supported at this time, per the dev note |
| It covers themes that need plugins | Not supported at this time |
| It checks security | No |
Why agencies should care
Dependencies are another path into your site. Installing one plugin can now mean the interface offers a second, and your inventory should list both. Treat a dependency as something you chose, review and update, not as an automatic add-on.
Steps for each new plugin:
- Read the header in the main file and note every listed slug.
- Review each dependency the way you would review a primary plugin.
- Record both in the inventory, with an owner.
- Check update status of the pair together, because a break in one can disable the other.
The header also helps you in an audit: a plugin that lists a dependency it never uses is a question worth asking the author.
Premium add-ons for a base plugin have a similar need. The dev note adds a filter that lets a premium version stand in for a free slug, which shows the slug match is a naming convention, not an identity check. Compare it with the Update URI header covered in our post on that field.
Example of a gap
Imagine an add-on that declares a base plugin as a dependency. The base plugin is vulnerable, and a fixed version ships. The header will not tell you, because it matches a slug and not a version. Your inventory is what shows that the base plugin is behind, and your update routine is what fixes it. Use the header as a convenience for installation order, and keep your own records for everything else.
Quick check
Does it install dependencies automatically?
The interface can offer to install WordPress.org dependencies, but dependencies outside WordPress.org must be installed manually.
Can I rely on it to keep versions compatible?
No. It matches slugs and does not compare versions.
Sources
Last reviewed: 19 October 2026.
