Free tools Windows power users keep installed
One-click scans. No signup required.
Some links on this page are affiliate links: if you buy through them we may earn a commission, at no extra cost to you.
To use one WordPress plugin from another, build a separate add-on in its own directory and connect to the existing plugin through documented actions, filters, or APIs. Do not edit the installed plugin’s files: updates can overwrite those changes. WordPress’s developer handbook puts the rule plainly: “Don’t touch WordPress core.” The same extension-first approach keeps plugin code update-safe. See the Introduction to Plugin Development and Plugin Basics.
What “using another plugin” means
An add-on normally does not copy or modify the other plugin. It waits for the target plugin’s public extension points, then adds or changes behavior with its own code. Those extension points may be WordPress hooks, a documented API, or functions the target plugin explicitly supports.
Actions let your callback perform work when an event occurs; filters pass a value to your callback so you can modify it and return the result. WordPress summarizes actions as: “Actions allow you to add data or change how WordPress operates.” Learn the two hook types in the Hooks handbook.
Choose the dependency model first
| Decision | Required add-on | Optional integration |
|---|---|---|
| Is the target plugin essential? | Yes. The add-on has no useful purpose without it. | No. Core features work alone and integration is an enhancement. |
| Can WordPress declare it? | Use Requires Plugins when the target is a WordPress.org plugin with a supported slug. |
Usually omit the header and detect the target safely at runtime. |
| When the target is absent | Prevent activation or show a clear admin notice; never produce fatal errors. | Disable only the integration and leave the rest of the add-on usable. |
| Public distribution | Directory submission brings readme and directory-guideline requirements. | A site-specific package can remain private and does not need WordPress.org submission. |
Plugin dependencies were introduced in WordPress 6.5. The Requires Plugins value accepts comma-separated WordPress.org-formatted slugs; a file path such as my-plugin/my-plugin.php is not supported. See Header Requirements and the WordPress core announcement about plugin dependencies in WordPress 6.5.
#1 Best Overall
Create the add-on’s files
- Create a directory under
wp-content/plugins, for exampleacme-target-addon. - Inside it, create the main PHP file, such as
acme-target-addon.php. - Put the plugin header at the top of that main file. WordPress scans plugin files for headers and lists recognized plugins on the Plugins screen.
The handbook’s example uses shell commands and vi, but any editor is acceptable. A directory is recommended even when the first version consists of one PHP file because it leaves room for includes, assets, tests, and translations. See Plugin Basics.
A minimal header
<?php
/**
* Plugin Name: Acme Target Add-on
* Description: Adds an integration to the target plugin.
* Version: 1.0.0
* Requires at least: 6.5
* Requires PHP: 7.4
* Author: Your Name
* License: GPL-2.0-or-later
* Text Domain: acme-target-addon
* Requires Plugins: target-plugin-slug
*/Include only metadata that is accurate for your code. The header belongs in the main plugin file; do not add competing plugin headers to included files. If the target is not a WordPress.org dependency, leave out Requires Plugins and perform your own compatibility check.
Connect through documented hooks or APIs
Read the target plugin’s developer documentation, source comments, and release notes to find its supported actions, filters, and functions. Do not infer a stable API from a private class, an internal method, or an implementation detail. Register your callbacks only after WordPress and the target plugin have loaded the code they expose.
Generic action and filter pattern
The hook names below are illustrative placeholders. Replace them with names documented by the specific plugin you are extending.
<?php
if ( ! defined( 'ABSPATH' ) ) {
exit;
}
function acme_target_addon_bootstrap() {
// Optional integration: do nothing if the target API is unavailable.
if ( ! function_exists( 'target_plugin_public_function' ) ) {
return;
}
add_action( 'target_plugin_after_item', 'acme_target_addon_after_item', 10, 1 );
add_filter( 'target_plugin_item_data', 'acme_target_addon_item_data', 10, 1 );
}
add_action( 'plugins_loaded', 'acme_target_addon_bootstrap' );
function acme_target_addon_after_item( $item ) {
// Add your action behavior here.
}
function acme_target_addon_item_data( $data ) {
// Change the documented value, then return it.
return $data;
}Match the documented number of accepted arguments when calling add_action() or add_filter(). A filter callback must return the value it receives (or a deliberate replacement). Keep callbacks narrowly scoped and use unique function or class names to avoid collisions.
Why undocumented internals are risky
Internal names can change without a compatibility promise. Removing another callback can also be difficult to reason about when priorities and accepted arguments differ. The hooks handbook recommends frequent testing, especially when changing or removing callbacks. Prefer a documented hook or API over replacing someone else’s callback.
Handle an inactive or missing target plugin
Required WordPress.org dependency
If the target is declared with Requires Plugins, WordPress can communicate the dependency in the admin. Your code should still fail safely: never call target functions before they exist, and provide an actionable message if the dependency cannot be used. WordPress.org guidance says a plugin may prevent errors by deactivating itself when a required plugin is inactive, but it must not change the other plugin’s activation status. See Common issues.
Optional integration
For an optional integration, guard registration with function_exists(), class_exists(), or another documented availability check. Keep the add-on active and show an admin notice only when an administrator needs to act.
function acme_target_addon_admin_notice() {
if ( ! current_user_can( 'activate_plugins' ) ) {
return;
}
echo '<div class="notice notice-warning"><p>Acme Target Add-on integration is unavailable because the target plugin is inactive.</p></div>';
}
function acme_target_addon_check_dependency() {
if ( ! function_exists( 'target_plugin_public_function' ) ) {
add_action( 'admin_notices', 'acme_target_addon_admin_notice' );
}
}
add_action( 'admin_init', 'acme_target_addon_check_dependency' );Use the target plugin’s documented readiness signal when one exists; a guessed function name is not a substitute for its API documentation.
Rank #4
Use lifecycle hooks for the right job
Activation
Use register_activation_hook() for one-time setup such as default options or, when warranted, database and rewrite setup. The first argument must point to the main plugin file that contains the header.
function acme_target_addon_activate() {
add_option( 'acme_target_addon_settings', array() );
}
register_activation_hook( __FILE__, 'acme_target_addon_activate' );Deactivation
Use the deactivation hook for temporary cleanup, such as unscheduling a task or flushing a rewrite rule that should not remain active. Do not erase user data merely because a site owner temporarily deactivates the add-on.
Recommended Free Tools
function acme_target_addon_deactivate() {
// Unschedule temporary work or release runtime state here.
}
register_deactivation_hook( __FILE__, 'acme_target_addon_deactivate' );Uninstall
Permanent removal belongs in an uninstall routine, not ordinary deactivation. Options and custom tables should be deleted only when that behavior is intentional, documented, and confirmed by the site owner. The handbook’s Activation / Deactivation Hooks guidance explains the distinction.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Test the integration before deployment
- Activate the add-on with the target plugin active and verify every documented action and filter.
- Deactivate the target plugin and confirm there is no fatal error, broken front end, or repeated admin notice.
- Test a clean WordPress site with only the two plugins enabled to separate integration bugs from conflicts.
- Test activation, deactivation, reactivation, and uninstall behavior; check that intended settings persist and unintended data is not removed.
- Test with debugging enabled in a development environment and watch for PHP notices, deprecated calls, and incorrect hook arguments.
- Retest after updates to either plugin because documented APIs can evolve and load order can change.
Package or publish the add-on
A site-specific integration can be installed as a ZIP or copied into wp-content/plugins; it does not need WordPress.org approval. If you submit it to the directory, follow the current submission and directory guidance, including the required readme format and maintenance expectations.
Document the target plugin and tested versions, whether it is required or optional, what happens when it is unavailable, the hooks or APIs used, and how to remove stored data. Keep the add-on’s license and compatibility claims aligned with its actual code.
Common failure modes
- Editing the target plugin: updates overwrite the change. Move the customization into your own add-on and use a supported extension point.
- Calling target code too early: a function or class may not exist at file load. Register integration after plugins load and guard availability.
- Using a file path in
Requires Plugins: that field expects a WordPress.org slug, notfolder/file.php. - Assuming every hook is stable: private internals can change. Use documented actions, filters, and APIs.
- Deleting data on deactivation: temporary disablement should not unexpectedly destroy settings. Reserve permanent cleanup for uninstall and make it explicit.
Frequently Asked Questions
Can my add-on activate the other plugin automatically?
No. WordPress.org guidance says a plugin must not change another plugin’s activation status. Declare a supported dependency or explain the required activation step to the administrator.
Do I need to publish an add-on on WordPress.org?
No. A private or site-specific add-on can be distributed directly. Directory submission is relevant only if you choose public WordPress.org distribution.
What should I do if the target plugin has no documented hooks?
Ask its authors for a supported API or choose a different integration point. Depending on private internals makes updates fragile; editing its files is not a safe substitute.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
