Wordpress Packager Laravel Package

Product Decisions This Supports

• Deployment model: pinned core vs. admin-driven updates. This package makes WordPress core a lockfile entry, which converts "click update in wp-admin" into "PR → CI → deploy." That's not a tooling detail — it decides who owns patching, how fast major versions reach customers, and whether you can promise rollback.
• Build vs. buy (really: adopt Bedrock or not). The real decision is whether to standardize on the Roots/Bedrock deployment model; this is the component that makes "core as a Composer dependency" true. If Bedrock is already chosen, this is the default implementation, not a separate evaluation.
• Capability roadmap: white-label / agency / multi-tenant templates. Because bundled themes and plugins (twenty*, Akismet, Hello Dolly) are stripped, wp-content is entirely yours. Enables a lean, repeatable site template, smaller images, faster cold builds, fewer outdated files on disk to explain in a security review.
• Support/SLA commitments. Pinning core lets you promise "no untested core updates on customer sites" and gives you a revert path. It also caps how fast you can claim "patched within 24h of a WordPress security release" — that depends on upstream artifact cadence you don't control. Pick which promise you sell before adopting.
• Plugin/theme dependency policy. If plugins also flow through Composer, you get a full dependency graph: useful for procurement, license audits, and answering "which sites run plugin X at version Y" in an incident.
• Platform effort estimation. Replaces a bespoke build script (fetch + unzip + strip) or a self-hosted Composer mirror of WordPress. That's roughly a week of platform engineering and its ongoing maintenance you don't spend.
• Explicitly not a differentiator. Opportunity score is low (0.38). Treat it as infrastructure hygiene — good internal standard, poor marketing slide.

When to Consider This Package

Adopt when:

• You're on Bedrock, or seriously evaluating it, and already run composer install in CI.
• You need reproducible, rollback-able core across local/staging/prod, and you (not a third-party admin) own the site.
• You operate many sites where core-version drift between them is a real operational cost.
• You want core upgrades to pass through code review and automated tests rather than an admin UI.

Look elsewhere or skip when:

• You're not on Bedrock. Despite being Composer/PHP, this is not a Laravel package — no service provider, no facade, no framework integration. It won't "modernize" a Laravel app and shouldn't be pitched as such.
• Your managed WordPress host mandates its own core builds or auto-updates, or your deploy process is Git-push/FTP without a build step — the model won't fit.
• WP core's built-in auto-update is your patching strategy; pinning directly conflicts with it.
• You need vendor support or an SLA: MIT, 43 stars, last release 2024-03-25, maintained as part of the Roots org. Star count understates real usage (consumers depend on the generated artifact, not this repo), but there's still no contract and a single-ecosystem blast radius.
• Your only goal is hiding bundled themes — a sane wp-content layout and a couple of constants get most of that without a packaging pipeline.

Due diligence before committing:

• Measure artifact lag against the last 3 WordPress security releases.
• Confirm host support for Bedrock-style layouts.
• Ensure CI can cache or mirror Composer artifacts, so builds don't hard-depend on an external pipeline.
• Check Composer availability for your plugin stack — premium plugins usually need manual vendoring, which becomes your process to own.

How to Pitch It (Stakeholders)

Executives: WordPress core becomes a pinned, versioned dependency in the same lockfile as the rest of the application. Deploys become reproducible and reversible, staging matches production, and every core change is a reviewed PR rather than an overnight click in wp-admin. Security posture improves because we ship only the themes and plugins we actually use; ops cost drops because the build is automated. The tradeoff to accept consciously: we now own upgrade cadence. MIT licensed, no fees, and it's the standard path within an established ecosystem rather than a bet on a tiny project.

Engineering: it's a packaging step, not runtime code. Consume the generated core package as a Composer dependency, run it in CI, keep wp-content in our repo. No new runtime abstraction in the app and easy to reverse — swap the dependency for another core package or a vendored tarball. Two guardrails: pin the version and track upstream release cadence, and mirror artifacts if the build environment can't reliably reach Packagist.