A WordPress plugin dependency is another component required for correct operation.
The requirement can affect installation, activation, loading, features, data, or external services.
WordPress can enforce declared relationships, but it cannot discover every operational contract.
What is a WordPress plugin dependency?
A dependency supplies code, data, configuration, infrastructure, or behaviour another plugin needs.
The relying component is the dependent. The required component is the dependency.
Dependencies form directed relationships
If plugin A requires plugin B, the relationship points from A toward B.
Removing B can break A. Removing A need not affect B.
A dependency is not merely an integration
An integration enhances behaviour when another component happens to exist.
A dependency makes some promised behaviour impossible without that component.
Required and optional relationships differ
Required dependencies belong inside installation, activation, and operational controls.
Optional integrations need graceful absence, clear status, and limited feature loss.
WordPress supports declared plugin dependencies
WordPress 6.5 introduced core handling for declared plugin dependencies. The full walkthrough is in plugin version requirements.
The official developer note documents its behaviour and present limits.
The Requires Plugins header declares relationships
A plugin author lists required WordPress.org-formatted slugs inside the main header.
The Plugin Handbook defines the accepted header format.
The header uses slugs, not file paths
Each entry identifies a plugin slug separated by commas.
A path such as plugin-folder/plugin-file.php is not supported there.
Core reads the relationship from installed headers
Core gathers dependency slugs while inspecting installed plugin headers.
The code reference exposes the responsible dependency reader.
Core blocks installation when dependencies are missing
The standard interface prevents dependent installation until declared dependencies exist.
This guard reduces incomplete setups through normal administration screens.
Core blocks activation when dependencies are inactive
A dependent cannot activate until each declared dependency is active.
The plugin screen explains which requirement remains unmet.
Active dependents protect their dependencies
Core prevents deactivation while an active dependent still requires that plugin.
This protects an obvious relationship from an accidental dashboard action.
Installed dependents also prevent deletion
A declared dependency cannot be deleted while its dependents remain installed.
Deletion would otherwise leave a known incomplete component set.
The plugin screen shows both directions
Dependent rows can list dependencies. Dependency rows can list dependents.
That visibility helps administrators understand protected actions.
Dashboard enforcement has boundaries
Filesystem deployment can still remove a dependency outside WordPress controls.
Core then reports the missing relationship on plugin administration screens.
A new dependency can arrive during an update
Core presently permits an update that introduces a missing dependency.
The dependent can remain active while WordPress displays an administrative notice.
The declaration has no version constraints
Requires Plugins cannot express minimum, maximum, or compatible dependency releases.
Installed and active does not therefore prove interface compatibility.
Loading order is not guaranteed
The core dependency feature does not order normal plugin loading.
Authors still need hooks, existence checks, and appropriately timed initialisation.
Defensive code remains necessary
Check required functions, classes, interfaces, versions, and service capabilities.
Fail predictably before code reaches an unavailable interface.
Hooks reduce fragile load-time coupling
WordPress hooks let components interact at defined execution points.
The official hooks guide explains actions, filters, and callbacks.
Do not execute dependency calls too early
Top-level calls can run before another plugin exposes its required interface.
Attach initialisation to an appropriate hook and verify the contract there.
Circular dependencies are invalid
A cycle makes every member depend on another unavailable member.
WordPress detects declared cycles and prevents affected activation.
Break cycles by redesigning ownership
Move shared contracts into one lower-level component without reverse dependencies.
Alternatively, replace requirements with optional hook-based integrations.
WordPress.org dependencies have hosting restrictions
Directory-hosted dependents can declare only dependencies hosted on WordPress.org.
That limitation protects predictable discovery within the directory interface.
Third-party plugins receive different assistance
Externally hosted dependents may declare external dependency slugs.
WordPress cannot provide an installation link for those external packages.
Must-use dependencies are not officially supported
Core dependency management does not officially cover must-use plugins.
Keep explicit deployment checks for code inside the mu-plugins directory.
Themes cannot declare this relationship
Core Plugin Dependencies does not manage themes requiring plugins.
Theme authors still need checks, guidance, and graceful behaviour.
WP-CLI behaviour differs from the dashboard
WP-CLI can install a dependent before its declared dependencies.
Activation remains blocked until its dependencies become active.
Bulk activation can need another pass
Alphabetical processing can encounter a dependent before its dependency.
Automation should inspect results instead of assuming one command completed everything.
Runtime dependencies extend beyond plugins
A plugin can require PHP extensions, WordPress APIs, jobs, or filesystem access.
Requires Plugins represents none of those operational conditions.
External services create remote dependencies
Payments, email, search, licences, analytics, and storage can depend on remote systems.
Track authentication, availability, quotas, regions, contracts, and data flows.
Data can be a dependency
A plugin may expect options, tables, indexes, posts, or generated files.
Installed code cannot operate correctly when required state is missing.
Configuration can be a dependency
Correct keys, endpoints, roles, pages, and mappings may enable promised behaviour.
Record configuration contracts without storing secrets in documentation.
Scheduled work can be a dependency
Queues, renewals, imports, exports, and clean-up may require dependable scheduling.
A healthy page request does not prove those background paths work.
Shared libraries create hidden coupling
Two plugins can bundle different releases of the same PHP library.
Namespace strategy and loading behaviour determine whether they collide.
Add-ons often depend on parent interfaces
An add-on may call parent classes, hooks, APIs, settings, or schemas.
Its true contract can be narrower than simple parent activation.
Dependency presence is not dependency health
An active dependency can still be misconfigured, outdated, degraded, or incompatible.
Health checks must inspect the capability actually consumed.
Map dependencies as an inventory
Record dependent, dependency, purpose, interface, owner, source, and required version.
Add configuration, data, service, test, failure, and recovery details.
Label evidence separately from assumptions
A header, vendor matrix, code reference, and observed behaviour carry different confidence.
Mark unverified relationships before they guide production changes.
Find transitive dependencies
Your plugin may require an add-on that requires another service.
Trace the complete chain until every operational prerequisite has ownership.
Separate hard and soft failure
Hard failure can stop activation, requests, checkout, publishing, or administration.
Soft failure may remove one enhancement while core behaviour continues.
Design graceful degradation for optional integrations
Hide unavailable controls, preserve stored data, and explain the missing capability.
Do not turn an optional integration into a fatal bootstrap call.
Make required failure explicit
Name the absent component, expected version, affected feature, and corrective action.
A generic fatal error hides the actual dependency problem.
Test missing-dependency states deliberately
Remove, deactivate, misconfigure, and disconnect each dependency on staging.
Confirm administrators retain a usable recovery path.
Test incompatible dependency versions
Exercise supported lower, current, and planned releases where contracts change.
Verify rejection messages before unsafe calls execute.
Test unavailable remote services
Simulate timeouts, invalid credentials, rate limits, and malformed responses.
Confirm retries cannot duplicate payments, messages, or records.
Monitor dependency contracts, not plugin labels
Check queue progress, API responses, data writes, hooks, and expected output.
An active badge says nothing about those paths.
Give every relationship an owner
Ownership includes release review, compatibility testing, credentials, and incident response.
Unowned dependencies become invisible until they fail.
Document recovery from dependency loss
State whether recovery means restoration, reactivation, reconfiguration, or service failover.
Include data reconciliation after the dependency returns.
Review dependencies before handoff
Transfer licences, accounts, keys, repositories, contacts, schedules, and documentation.
The recipient needs control, not merely a plugin list.
Review dependencies before deletion
Identify dependents, shared data, external callbacks, jobs, and retained configuration.
Dashboard protection covers only the relationships core understands.
Avoid unnecessary hard coupling
Do not require a large component for one replaceable convenience.
A stable interface or optional adapter may reduce operational risk.
Multisite changes the dependency scope
A network-active dependency can support dependents across several sites.
Document network activation, site activation, and per-site configuration separately.
Build-time packages are dependencies too
Composer and JavaScript packages may produce the shipped plugin archive.
Preserve lock files, build instructions, registries, and reproducible release tooling.
Bundled libraries need provenance
Record each bundled library version, source, licence, and security ownership.
A vendor archive can conceal vulnerable transitive packages.
Browser assets introduce another dependency layer
Frontend code can expect global scripts, styles, translations, or generated manifests.
Missing assets may break interaction without producing a PHP error.
Webhooks reverse the direction of traffic
An external service may depend on a reachable WordPress endpoint.
Track signatures, retries, ordering, deduplication, and endpoint ownership.
Identity providers can block administration
Single sign-on plugins depend on remote identity and local fallback access.
Test emergency authentication before the provider becomes unavailable.
Caching can disguise dependency recovery
Cached errors may remain after the required component returns.
Cached success may also conceal a newly broken live path.
Data schemas require coordinated compatibility
A dependent can read columns or values owned by another plugin.
Private schema access creates fragile coupling across releases.
Prefer public contracts over private internals
Use documented hooks, functions, endpoints, and extension interfaces.
Internal classes and tables may change without compatibility promises.
Contract tests protect integrations
Test the exact input, output, error, permission, and timing assumptions.
Run those tests against every supported dependency release.
Observability should name the failed dependency
Logs should identify component, operation, state, and correlation evidence.
Avoid logging credentials or unnecessary personal data.
Credentials need least privilege
Grant only the operations needed by the consuming plugin.
Record rotation, revocation, storage, expiry, and emergency replacement procedures.
Quotas create capacity dependencies
An available service can still refuse work beyond its allowance.
Monitor consumption, reset periods, throttling, and safe backpressure behaviour.
Latency can become functional failure
A slow dependency can exhaust workers and delay unrelated requests.
Set bounded timeouts and choose deliberate fallback behaviour.
Dependency concentration increases blast radius
One service may support checkout, forms, accounts, and administration.
Map shared failure before calling each integration independent.
Set a dependency budget
Every required component adds updates, monitoring, access, and recovery work.
Reject dependencies whose benefit cannot justify that ongoing burden.
Plan dependency retirement
Define replacement, data migration, callback removal, and credential revocation.
Retirement ends only after monitoring finds no remaining consumers.
Vendor abandonment changes the graph
An unmaintained dependency transfers security and compatibility ownership to you.
Replace, isolate, fork, or remove it through an approved plan.
Incident triage starts with the graph
Identify the failing capability and every upstream provider.
Then isolate evidence without randomly disabling unrelated components.
Record a known-good dependency baseline
Preserve versions, configuration checks, service responses, and successful journeys.
Future failures then have a concrete comparison point.
Review the graph during every architecture change
New features can silently introduce services, libraries, jobs, or shared state.
Require dependency documentation before approving production deployment.
Know the honest weak case
A loose integration may work better without a formal dependency declaration.
It must remain useful, safe, and understandable when the integration disappears.
Use the plugin dependency checklist
- Name the dependent and dependency.
- Define the required capability.
- Classify required or optional behaviour.
- Record declared dependency evidence.
- Record supported version ranges separately.
- Map transitive plugin relationships.
- Include services, data, jobs, and configuration.
- Check loading and initialisation timing.
- Test missing and inactive states.
- Test incompatible dependency versions.
- Test remote failure and recovery.
- Assign operational ownership.
- Monitor the consumed capability.
- Document restoration and reconciliation.
- Review the map after every material change.
Frequently asked questions
What is a WordPress plugin dependency?
It is another component required for installation, activation, or correct operation.
What does Requires Plugins do?
It declares required plugin slugs and enables core interface protections.
Can Requires Plugins specify versions?
No. Teams must track and test compatible versions separately.
Does WordPress control plugin loading order?
No. Authors still need hooks, existence checks, and defensive initialisation.
Are external services plugin dependencies?
Operationally, yes. Core does not represent those remote service contracts.
The verdict
A dependency graph is an operating model, not only a header. Review WP Block Suite’s $299 lifetime licence.
Leave a Reply