Weave Code
Extension Command Laravel Package
wp-cli/extension-command
WP-CLI extension-command provides wp plugin and wp theme commands for managing WordPress extensions from the command line. Install from wordpress.org, activate or deactivate, update, delete, and handle multisite network activation, with bulk actions, exclusions, and force reactivation.
Manages plugins and themes, including installs, activations, and updates.
Frequently asked questions about Extension Command
- Can I use wp-cli/extension-command directly inside a Laravel app?
- No, not as an in-process library. It is a WP-CLI command package that registers wp plugin and wp theme subcommands and expects a bootstrapped WordPress runtime with WP_CLI, $wpdb, and WP_CONTENT_DIR. In a Laravel app you use it as an external CLI surface through Symfony Process, SSH, or CI jobs running on a host that has WordPress and WP-CLI installed.
- How do I install wp-cli/extension-command with Composer?
- In practice you install WP-CLI itself, because this package ships inside wp-cli/wp-cli-bundle. Running composer require wp-cli/wp-cli-bundle and using the wp entrypoint gives you wp plugin and wp theme without managing each command package separately. A standalone composer require wp-cli/extension-command inside a Laravel project adds files to vendor but does not create a runnable wp binary or WordPress runtime.
- Does wp-cli/extension-command support Laravel 10 and Laravel 11?
- The package has no Laravel dependency, service provider, or framework version constraints, so Laravel 10 and Laravel 11 are irrelevant to its own compatibility. What matters is the PHP version on the host, the installed WP-CLI version, and whether a WordPress install is present. Laravel integration is compatibility with your subprocess and queue setup, not a framework version matrix.
- How do I list WordPress plugins from Laravel as JSON?
- Run wp plugin list --format=json --skip-update-check on the target host and decode STDOUT in Laravel. For a single plugin use wp plugin get slug --format=json, and for state checks use wp plugin is-active and wp plugin is-installed, which signal through exit code 0 or 1. Read commands are the safest first integration because they do not mutate the site.
- Is it safe to run wp plugin install and wp plugin update from a Laravel job?
- Treat write commands as privileged production changes, not routine automation. wp plugin install can fetch arbitrary remote ZIP and PHP URLs, --insecure disables TLS checks, --force overwrites installed versions, and --activate or --with-dependencies can pull in transitive code you did not vet. There is no general dry-run or transactional rollback, so put writes behind an allowlist and approval step and keep strict filesystem ownership on the target host.
- Should I use wp plugin install or Composer for plugins in a Bedrock WordPress site?
- Do not mix the two models on one site. Bedrock-style installs manage plugins as Composer dependencies in the repository, while wp plugin install writes into the WordPress content directory outside Composer's lock file. On Bedrock, use this package mainly for read-only inventory, status, and update-availability checks, and let Composer own install, update, and removal.
- How does multisite network activation work with the --network flag?
- The --network flag on wp plugin activate makes the plugin active for the entire multisite network rather than a single site. That changes activation and rollback behaviour, so confirm whether your Laravel job targets a single site or the network before scripting it. Also check that the plugin supports network activation, because some plugins behave differently when network-activated.
- How do I test wp plugin commands in CI without breaking a real site?
- Use a disposable WordPress environment, such as a container or a throwaway database and WP_CONTENT_DIR, and run the real wp commands against it. In Laravel, mock or fake Symfony Process for unit tests, but keep at least one integration test that exercises the actual WP-CLI binary and parses --format=json output. Assert on exit codes, JSON structure, and the resulting plugin state rather than on human-readable success messages.
- Is wp-cli/extension-command actively maintained, and what should I use instead?
- It is maintained in the WP-CLI GitHub organization and ships as part of wp-cli/wp-cli-bundle, so zero dependents on Packagist is misleading. The closest alternative is the full WP-CLI bundle, which includes it, while Composer-managed plugins or REST API endpoints cover different workflows. Treat odd metadata such as a future release date as dataset defects rather than maintenance signals.
- How do I handle errors and partial failures from wp plugin write commands?
- Expect human-readable STDOUT and STDERR plus a coarse exit code rather than structured error objects. A batch operation is only partially atomic, so five installs can leave two installed and three failed while returning exit 1. In Laravel, capture both streams, treat any non-zero exit as opaque failure, and verify actual state with a follow-up wp plugin list --format=json before reporting success.
Weaver
How can I help you explore Laravel packages today?