Wordpress Laravel Package

Product Decisions This Supports

• Build vs. buy vs. host for CMS. This package is the enabling piece for the "WordPress-as-a-dependency" architecture (Bedrock). It lets you decide between managed WordPress, stock self-hosted WordPress, and a Composer-managed WordPress with reproducible, version-pinned builds — and gives you a credible middle path if you want self-hosting without giving up dependency hygiene.
• Platform modernization roadmap. If a legacy WordPress estate is on your roadmap, this is the first migration step: core out of version control, pinned in composer.json/composer.lock, deployed as an immutable artifact. It sequences cleanly into subsequent steps (plugins as Composer deps, config in environment variables, CI-driven releases).
• Patching and security SLA. Pinning core to an exact version makes "which WordPress version is in production?" a query against a lockfile rather than an audit of servers. This directly supports decisions about patch windows, rollback guarantees, and compliance evidence (SBOM-style manifests).
• Portfolio economics for agencies/multi-site operators. One deployment pattern, one upgrade PR per site, no wp-admin drift between staging and production. This changes the unit cost of maintaining N sites, which changes whether a portfolio is viable at a given headcount.
• Attack-surface reduction. The package ships WordPress without the bundled default themes and plugins, so "do we really need twenty-twenty-four in production?" becomes a decision you actively make rather than inherit.
• Feature-level use cases. Automated core upgrade PRs via Renovate/Dependabot, atomic deploys and instant rollback, per-environment config, multi-tenant WordPress products, and CI pipelines that spin up a known-good core version on every test run.

When to Consider This Package

Consider it when:

• You are on, or moving to, the Roots stack (Bedrock, Trellis, Sage), or are willing to adopt Bedrock's directory layout.
• You already deploy via Composer and want WordPress core governed by the same lockfile as the rest of your PHP dependencies.
• You need reproducible builds and immutable releases — no writes to wp-admin in production, no core files committed to Git.
• You run multiple environments or multiple sites and want identical core versions everywhere.
• You want bundled themes and plugins stripped so wp-content contains only what you deliberately ship.
• You need an auditable manifest of exact core versions for compliance or incident response.

Look elsewhere when:

• Your host pins and patches core for you and does not support a custom core path (some managed hosts; WP Engine is a notable exception that supports Bedrock).
• Your team's patching strategy is "non-technical staff click Update in wp-admin." This package assumes deploys, not clicks.
• You are not using Composer at all, or you are on shared hosting without artifact-based deploys.
• You need a vendor SLA or commercial support contract. This is a community re-packaging of WordPress core, not an Automattic product, and it carries no support agreement.
• You need the stock distribution with bundled themes for a simple site and see no value in the extra machinery.

Adoption caveats to state plainly in the decision record:

• The 199 stars and "0 dependents" figures understate real usage — Composer dependents are not tracked, and infrastructure packages are rarely starred. Do not read these as a quality signal in either direction.
• The real risk is release lag: the value proposition collapses if a security release of WordPress core is not mirrored into this package promptly. The future-dated release timestamp suggests an automated cadence tied to upstream releases; validate that cadence over the last several security releases before committing.
• Bus factor and governance: maintenance sits with the Roots team. Acceptable for most teams, but it belongs in the risk register, and you should know the fallback (a different core packaging, or vendoring core yourself) before you need it.
• Core upgrades still require a staging environment and a regression plan. This package makes upgrades mechanical, not risk-free.

How to Pitch It (Stakeholders)

For executives: today, WordPress core is something we install and then patch by hand, differently on every site. This package turns core into a versioned dependency, like any other software we ship — same audit trail, same one-click rollback, same automated upgrade PRs. The business outcomes are a measurable patch SLA, a verifiable answer to "what version is live?", and a lower per-site maintenance cost across the portfolio. It is MIT-licensed with no new vendor spend and no lock-in beyond the Roots ecosystem. The main thing we are accepting is reliance on a community maintainer to mirror WordPress security releases — which we will monitor with a defined fallback.

For engineering: composer require roots/wordpress puts core in web/wp, outside version control, pinned by composer.lock; wp-content stays in our repo and config moves to environment variables. Deploys become artifact swaps, so rollback is redeploying the previous build. Core bumps arrive as Dependabot/Renovate PRs and go through CI and staging like any other change — no more clicking Update in production and hoping. We also lose the bundled themes and default plugins, which shrinks what we have to patch. Cost is real but bounded: we adopt (or already have) Bedrock's layout, and we commit to a staging-and-regression step for core upgrades. This is a well-understood pattern in the Roots community; the work is in the migration, not in the tooling.