Extension Command Laravel Package

Product Decisions This Supports

• Fleet plugin/theme lifecycle as a product feature. Every command needed for a "manage plugins across my sites" capability — install, activate, deactivate, update, delete, inspect — is exposed as a discrete, scriptable verb. This directly supports building maintenance dashboards, one-click patching, and bulk remediation without reimplementing WordPress plugin semantics (activation hooks, multisite network activation, drop-ins, must-use plugins) in our own codebase.
• Automation and drift detection. wp plugin is-active / is-installed return meaningful exit codes (0/1) and wp plugin list --status=... filters by state, so health checks, "is the security plugin actually running?" monitors, and config-drift alerts can be built on a stable contract rather than screen-scraping.
• Machine-readable everything. --format=json|csv|yaml|count and --field= let us pipe output straight into our own reporting, billing/usage metering, or compliance evidence — a real build-vs-buy win versus writing WP-internals PHP.
• Update and patching policy decisions. update, update_version, auto_update, auto_update_indicated, tested_up_to, wporg_last_updated fields make it feasible to define SLA-driven patch windows, flag stale/vulnerable plugins, and report on auto-update coverage per site.
• Compatibility gating before a rollout. requires, requires_php, requires_wp, and requires_plugins (plus --ignore-requirements) let us decide whether to block, warn, or proceed on an update — a product decision about how aggressive our patching default should be.
• Bulk and scoped operations. --all, --exclude=<slugs>, and --network support onboarding/offboarding workflows, staging-to-production promotion, and per-plan feature gating (e.g., "exclude our bundled plugins from customer-initiated bulk actions").
• Reproducibility and rollback posture. --version=<version>, --force, --slug, and --with-dependencies (dependency resolution from the Requires Plugins header) enable pinned installs and deterministic provisioning — useful for deciding whether we promise one-click rollback or only forward-fix.
• Use cases to prioritise: managed WordPress hosting control panels, agency maintenance retainers, WP-as-a-service built inside a Laravel application, CI pipelines for bespoke plugin/theme repos, and migration tooling that must install a known plugin set on a fresh site.
• Build vs buy: buying here is essentially free — the command surface is already present on any WP-CLI installation, is MIT-licensed, and is maintained inside the official WP-CLI project. The only thing we build is the orchestration layer (job queue, audit log, retries, UI).

When to Consider This Package

Adopt when:

• Our product already touches WordPress sites — we host them, maintain them, provision them, or test plugins/themes against them.
• We need programmatic plugin/theme operations and want to avoid writing WP-internal PHP (bootstrapping wp-load.php, calling activate_plugin(), handling multisite edge cases ourselves).
• We can invoke a subprocess. WP-CLI is already bundled in standard WP-CLI distributions, so there is no additional dependency to add, patch, or audit.
• We need an auditable, stable contract: documented commands, documented exit codes, documented output formats.
• Multisite support matters (--network, --activate-network).
• We need installs from sources beyond wordpress.org: local zip, remote zip/URL, or a wordpress.org directory URL.

Look elsewhere or add a wrapper when:

• We expected a Composer library. This is a WP-CLI command package, not something you require into a Laravel app. There is no service provider, no PHP API, no typed objects. Integration means Process::run('wp plugin install ...') — which means we own escaping, timeouts, concurrency, idempotency, and output parsing. Budget for that wrapper explicitly; it is the real cost of adoption.
• We need in-process, transactional control. This package does not give us rollback, dry-run diffs, or atomic multi-plugin updates. If our value proposition depends on "undo this update," we must build snapshotting (files + DB) ourselves.
• We need premium/commercial plugin licensing flows. Only wordpress.org, zip files, URLs, and single PHP files are handled. Vendor license-key activation and authenticated download endpoints are our problem.
• We are not a WordPress shop. Nothing here transfers to a general PHP/Laravel product; the domain is entirely WP plugin/theme lifecycle.
• We can't safely shell out (shared, locked-down runtime, no exec, no writable filesystem) or can't guarantee the wp binary version on target hosts — pin the WP-CLI version in our images or the contract is unstable.
• Reading the signals correctly matters. 90 stars and "0 dependents" understate adoption: this ships inside the WP-CLI bundle, so it is installed on effectively every WP-CLI host; dependents aren't tracked because it isn't consumed as a standalone Composer dependency. Do not treat the low star count as an abandonment signal — but do verify the release cadence in our own environment rather than trusting a single date field.
• Security review. --insecure exists (TLS validation bypass), and everything runs with the privileges of the PHP process. Treat it as a privileged tool: allow-list slugs and versions, block arbitrary URLs, and never surface raw user input to the command line.
• Licence/procurement: MIT, no vendor negotiation, no seat cost — a low-friction approval.

How to Pitch It (Stakeholders)

One-line summary: This is the official WordPress command-line component that installs, activates, updates, and removes plugins and themes. It is not a library we embed — it is a tool we call — and it lets us offer plugin management as a product feature without writing WordPress internals ourselves.

For executives:

• Cost to adopt is near zero. No licence, no vendor, no new dependency to procure; it is already present wherever WP-CLI runs, and it is maintained by the official WP-CLI project. Our investment is in our own orchestration layer — job scheduling, audit logging, and UI — not in plugin-management logic.
• It shortens the path to revenue-bearing features: bulk patching, update reporting, security-plugin assurance, and one-click provisioning, all of which are natural upsell or retention levers for hosting and maintenance offerings.
• It reduces operational risk and labour. Automated, auditable, repeatable plugin operations replace manual per-site toggling, and the JSON output gives us the evidence trail customers and auditors ask for.
• Honest caveat: the tool performs the actions; it does not provide rollback, transactional safety, or premium-plugin licensing. We should scope the first release as "managed updates with clear reporting" and treat undo/rollback as a separate, funded initiative.

For engineering:

• Shape of the integration: a thin service around Symfony Process (or Laravel's Process facade) that builds argument arrays — never string concatenation — enforces timeouts, sets --format=json and --field= for machine consumption, and maps exit codes to typed results. Never parse the default table output.
• Why it's the right dependency: it is the reference implementation of these operations, already versioned and tested upstream with a Behat/PHPUnit suite, and it handles the ugly edge cases (multisite network activation, drop-ins, must-use plugins, dependency resolution via Requires Plugins) that we would otherwise get subtly wrong.
• What we own: input validation and allow-listing, escaping, concurrency limits, retry semantics, audit logging, secrets handling, and the decision to never expose --insecure or arbitrary remote URLs through the product surface.
• What we deliberately don't do: reimplement plugin activation, or promise atomicity we can't deliver. If transactional updates become a requirement, that is a separate design with filesystem and database snapshots.
• Version discipline: pin the WP-CLI version in our images and treat the command surface as a contract we test against — this is a subprocess boundary, so a version bump is a real integration change, not a silent minor upgrade.