Wordpress No Content Laravel Package

Product Decisions This Supports

• Platform architecture (build vs. buy): This package is the concrete dependency that makes "WordPress core as a Composer-managed artifact" viable. The decision it informs is not whether to build a core mirror (don't — this is commodity plumbing), but whether to standardize the platform on Composer-driven WordPress (Bedrock-style) versus traditional monolithic installs.
• Deployment model / roadmap: Supports a move to reproducible, version-pinned builds and immutable artifacts. Core becomes a lockfile entry rather than a manually copied directory, which enables consistent staging/production parity.
• Security patching cadence: Because the package tracks upstream WordPress automatically, it lets you define and enforce an update SLA (e.g., patch within N days) with CI testing before promotion — a governance decision, not just a technical one.
• Content/platform separation: Dropping wp-content from core makes themes, plugins, uploads, and custom code independently managed concerns. This is the enabler for agency portfolios, white-label fleets, and multi-site platform products.
• Use cases: Agency multi-site management, enterprise WordPress platforms, any team already on the Roots stack (Bedrock/Sage/Trellis), and CI/CD pipelines that produce deployable artifacts.
• Licensing/compliance: GPL-2.0 aligns with WordPress core itself; no commercial license negotiation or legal review overhead.

When to Consider This Package

Adopt when:

• You are standardizing on Bedrock or otherwise want WordPress core as a Composer dependency.
• You need reproducible, version-pinned deployments and artifact-based CI/CD.
• You operate multiple WordPress sites and want a uniform, auditable upgrade path.
• Your team is fluent in Composer, PHP dependency workflows, and Git-based deploys.
• You want wp-content managed outside core (custom layout, separate repos for themes/plugins).

Look elsewhere or proceed with caution when:

• You rely on managed WordPress hosts that pin or patch core themselves and don't support custom directory layouts — the package adds friction without benefit.
• Your team lacks Composer experience; the operational overhead outweighs the gains.
• You need vendor SLAs or long-term commercial support — this is a small, ecosystem-maintained package (low star count, single-organization stewardship).
• You depend on plugins/themes that hardcode the default wp-content path or assume a stock install.
• You have a legacy stack with no CI/CD and no appetite to build one.
• You require audited release provenance — verify the automation/mirroring process, and keep a fallback to wordpress/wordpress or a self-hosted mirror.

How to Pitch It (Stakeholders)

Executives: This is a small, free, GPL-licensed packaging of WordPress core that lets engineering treat WordPress like any other versioned software dependency. It is not a new product — it is plumbing that lowers the cost and risk of running many WordPress sites: faster and more consistent security patching, reproducible releases, and cleaner separation between platform code and site content. Direct cost is near zero; the real investment is process discipline (CI/CD, deployment standards). The primary risk is ecosystem maturity — it is maintained by a small team — so adoption should be paired with an internal owner and a documented fallback plan.

Engineering: It strips wp-content from the core package so WordPress can be installed via Composer alongside our plugins and themes, producing a locked, reproducible build. Pin versions, run upgrades through CI, and deploy immutable artifacts. Note that it tracks upstream automatically — we should define our own update policy rather than implicitly consuming "latest," and retain an escape hatch (official WordPress tarball or a self-managed mirror) if the package lags or changes maintenance. Expect integration work around directory layout, wp-config handling, and any plugins that assume default paths.