When WordPress says a plugin cannot activate because required plugins are missing or inactive, identify and activate the legitimate dependency first. Removing the dependency declaration or forcing a database flag does not install the code the plugin needs.
Read the exact activation message
Core dependency handling was introduced in WordPress 6.5. The original developer explanation describes how declared dependencies affect activation. The current plugin-row implementation distinguishes missing or inactive required plugins.
A fatal error, an unsupported PHP version and a missing license are different problems, even if they occur after clicking Activate. Record the exact message and installed WordPress and PHP versions before deciding which branch you are troubleshooting. Do not paste a full error log publicly if it contains paths, keys or customer data.
Verify the dependency's identity
Open the dependent plugin's trusted vendor documentation or WordPress.org listing. Confirm the required plugin's name and slug. Similar names do not prove that two packages are interchangeable. A free and a paid edition can have different installation requirements.
Inspect the installed plugin list. Is the required package absent, installed but inactive, or present under a different product? If it is absent, obtain it from its authorized source. Do not download a replacement ZIP from an arbitrary search result just to satisfy a dependency label.
Identity: Confirm the required package slug. First failure: Resolve prerequisite error first. Guard: Do not remove dependency checks. Feature: Supported combination actually works. Explanatory checklist, not a customer test result.
Activate in the correct scope
On a single site, activate the prerequisite and check for its own errors before activating the dependent plugin. On multisite, inspect the relevant site and Network Admin state with the administrator responsible for that network. Do not assume a site-level control grants authority to change network-wide behavior.
For an illustrative chain, an add-on may depend on a form plugin that itself needs a supported PHP environment. If the form plugin fails to activate, repeatedly activating the add-on cannot repair that lower-level failure. Fix or escalate the first failing prerequisite, then work back up the chain.
| State |
Appropriate next step |
| Trusted prerequisite missing |
Install the authorized compatible package |
| Prerequisite inactive |
Activate it and inspect its own result |
| Required package fails with a fatal error |
Diagnose that error before the add-on |
| Both active, feature still absent |
Check configuration, permissions and vendor compatibility |
Do not bypass the dependency guard
Editing the Requires Plugins header or writing directly to active plugin settings can create a state the interface was preventing. It also hides useful evidence from the next administrator. If the declaration appears wrong, ask the vendor to clarify the supported package combination instead of modifying distributed code as a permanent fix.
After activation, test the specific feature the add-on provides with synthetic data. Confirm normal administration still loads and that no new server error appears. If you later need to remove a dependency, review the missing Delete button and network-active guide.
For help with a blocked activation, send the dependency chain, package versions and redacted error. The goal is a supported working combination, not merely a green Active label.
References reviewed October 14, 2026. Examples are explanatory, not customer test results.