Wordpress Core Installer Laravel Package

Product Decisions This Supports

• Core platform architecture: Composer-managed WordPress vs. traditional WordPress. This package is the piece that lets WordPress core be installed as a pinned Composer dependency (into a configurable web root, typically web/wp) instead of being downloaded and self-updated in place. Adopting it is effectively a decision to treat WordPress like any other versioned dependency in your PHP stack.
• Build vs. buy for deployment and release tooling. If your roadmap includes standardizing deployments (Bedrock-style layout, immutable artifacts, CI-built releases), this package removes the need to write and maintain custom core-sync scripts. It replaces bespoke "download WP, rsync, hope" tooling with a declarative composer.lock.
• Security patch SLA and release cadence. Pinning core via Composer makes WordPress version bumps a reviewable diff and a deliberate rollout decision rather than an unattended auto-update. That directly supports commitments like "critical core patches applied within X days" and staged/rolling upgrades across a site portfolio.
• Decoupled/headless content strategy. For a Laravel product that needs editorial content, this supports the pattern of WordPress as a content service (REST/GraphQL) managed as infrastructure-as-code, while Laravel owns the product surface. It is relevant to a Laravel roadmap only in that capacity — it is a Composer/PHP packaging tool, not a Laravel integration.
• Portfolio consolidation and multi-site operations. If the org runs several WordPress properties, this underpins a single, repeatable install contract (same core version, same path conventions, same environment parity) — a prerequisite for consolidating hosting, CI, and on-call ownership.
• Vendor and lock-in posture. GPL-2.0, small footprint, single responsibility. The decision it informs is not "which CMS" but "how much of our platform do we want expressed as Composer dependencies," and whether we accept the Roots/Bedrock ecosystem as the convention.

When to Consider This Package

Adopt it when most of these are true:

• Your team already builds and deploys PHP via Composer with a committed composer.lock, and CI produces artifacts rather than pulling code on the server.
• You want WordPress core versioned, code-reviewed, and promoted through environments like any other dependency — not auto-updated by the application.
• You are standardizing on (or already use) the Roots/Bedrock project layout, or you are willing to adopt its web/wp + web/app conventions.
• You need environment parity (local, staging, production) with identical core versions, and you want rollbacks to be a composer.lock revert plus a deploy.
• You are building a headless/decoupled setup where WordPress supplies content to a Laravel or JS front end, and you want that WordPress instance to be reproducible infrastructure.
• You can configure Composer's allow-plugins policy and accept that this plugin executes at install time (a supply-chain control you must review once, then govern).

Look elsewhere when:

• You have no Composer workflow, no SSH/CI on the host, or you rely on managed hosting whose core management (e.g., platform-managed updates and rollback) already owns this problem — layering this on adds conflict, not control.
• Content, marketing, or agency stakeholders depend on WordPress's built-in auto-updates and admin-initiated core updates; you would be removing a capability they use.
• It is a single, low-stakes site where the operational overhead of a build pipeline exceeds the risk being mitigated.
• Your plugin/theme stack assumes default WordPress paths and cannot tolerate a relocated core or custom WP_CONTENT_DIR.
• You need a supported, commercially-backed component with an SLA. With ~39 stars and a reported zero dependents, treat this as a small-maintainer, ecosystem-adjacent utility: acceptable as a thin, replaceable piece of a larger stack, not as a load-bearing dependency you cannot walk away from.

Adoption criteria to gate on before committing: pin an explicit version, confirm the release history and maintainer responsiveness yourself, verify behavior against your current Bedrock/WordPress version, document the manual fallback (install core directly into the web root and manage updates out-of-band), and note the licensing review for GPL-2.0 if any distribution is involved.

How to Pitch It (Stakeholders)

For executives: This is a small, unglamorous component that buys us something we currently handle by hand: WordPress core becomes a pinned, auditable dependency in the same pipeline we already use for the rest of the product. The business outcome is a shorter and more predictable security-patch cycle, one release process instead of two, and the ability to roll back a bad core update by reverting a lock file. It also unblocks using WordPress purely as a content service behind our Laravel product, if that is where the roadmap goes. Cost is low and the change is reversible; the main risk is that the package is maintained by a small team, so we pin it and keep a documented manual fallback.

For engineering: It is a Composer custom installer that places WordPress core at a configured path rather than in vendor/, so core is installed and upgraded exclusively through composer require/update with a locked version. That gives deterministic builds, reviewable version diffs, and environment parity, and it removes any need for the application to self-update core. Caveats to plan for: it is a Composer plugin, so it needs an explicit allow-plugins entry and a one-time supply-chain review; it assumes Bedrock-style path conventions and a relocated content directory; and because upstream activity is thin, we should pin the version, watch the repo, and hold a fallback playbook rather than assume long-term maintenance. Verify the current release and compatibility against our target WordPress version before we commit, and treat it as a replaceable adapter, not a platform bet.

One-line summary: a low-cost, reversible way to make WordPress core a locked, CI-deployed dependency — worth adopting only if we already run Composer-driven deployments and are prepared to own the pinning, plugin-allowlist, and fallback ourselves.