Wordpress Core Installer Laravel Package

Technical Evaluation

Architecture fit

• roots/wordpress-core-installer is a Composer plugin that changes where WordPress core is installed (typically outside vendor/, e.g. web/wp) so WordPress can act as a first-class dependency rather than a manually downloaded tarball. It is purpose-built for the Roots/Bedrock layout.
• For a Laravel codebase, fit is conditional, not native. The plugin solves file placement and version pinning only. It does not solve runtime integration: WordPress has its own bootstrap, routing, session model, and wp-content lifecycle. Embedding WP inside Laravel’s HTTP kernel is an anti-pattern; treating WP as a separate headless content service is the viable pattern.
• Strategic value is therefore low unless WordPress is already a required content platform. With 39 stars and 0 dependents, this is a narrow, ecosystem-specific utility—not a general Laravel integration layer.

Integration feasibility

• Mechanically simple: require the plugin, require a WordPress core package (e.g. roots/wordpress), set wordpress-install-dir and webroot-dir in composer.json extra config, and allow the plugin under Composer 2.2+ config.allow-plugins.
• Real effort sits outside Composer: web-server routing for /wp-admin, /wp-json, /wp-content; separation from Laravel’s public/index.php; environment/config duplication (Bedrock’s env-driven wp-config vs Laravel .env); CI artifacts and deploy permissions.
• Feasible in days for a Composer-literate team when WP runs as a sidecar/subdomain or headless backend. Not feasible as a drop-in for “WordPress inside Laravel.”

Technical risk

• Medium. Risks: Composer plugin API drift, WordPress core supply-chain (downloads from wordpress.org), GPL-2.0 copyleft obligations if distributing the combined work, and the operational burden of patching WP core through Composer updates.
• Low community validation (39 stars, 0 dependents) means few public failure reports; bus factor is effectively the Roots maintainers.
• Potential conflict with composer/installers or other custom installers if both claim wordpress-core; path collisions are a common failure mode.

Key questions

• Is WordPress a hard requirement, and is it headless-only or publicly exposed?
• Are we standardizing on Bedrock, or forcing Bedrock conventions into a Laravel-first repo?
• Who owns WordPress core and plugin patching, and what is the SLA?
• Does GPL-2.0 affect our distribution or SaaS posture?
• What Composer version and allow-plugins policy applies in CI and production?
• How is wp-content (themes/plugins/uploads) versioned and deployed?

Integration Approach

Stack fit

• Best fit: Roots Bedrock, or a monorepo with a dedicated WordPress deployable. Laravel remains the application/API layer; WordPress serves content via REST or WPGraphQL.
• Poor fit: bootstrapping WordPress inside Laravel’s request lifecycle, sharing sessions/auth, or serving WP and Laravel from the same front controller.
• Acceptable fit: a Laravel app that consumes WordPress as a headless CMS, where this installer standardizes WP core versioning in the same Composer workflow.

Migration path

• Existing WordPress site: stand up a Bedrock-style WP instance using this installer, migrate content and plugins, expose REST/GraphQL, then point Laravel at the WP API. Keep the legacy site live until parity is proven.
• Greenfield: add the plugin and a pinned WP core package, configure install paths, provision web-server rules, and build the content API contract before UI work.
• Incremental adoption: start headless with separate deployments; only consider colocation if latency or auth requirements force it—and expect significant custom glue.

Compatibility

• Composer 2.x with allow-plugins configured; PHP 8.x aligned with both Laravel and WordPress support matrices.
• WordPress 6.x core; verify the chosen core package tracks WP releases promptly.
• Web server: Nginx/Apache location blocks for WP endpoints separate from Laravel routes; avoid rewrite-rule collisions.
• CI/CD must permit the plugin and produce a reproducible artifact containing web/wp plus wp-content.

Sequencing

1. Decide architecture: headless WP service vs colocated subdirectory.
2. Provision the WP runtime and database independently of Laravel.
3. Add roots/wordpress-core-installer, configure allow-plugins, pin WP core in composer.lock.
4. Establish wp-content versioning and deployment strategy.
5. Configure web-server routing and TLS/domain boundaries.
6. Define and test the content API contract (REST/GraphQL) with Laravel.
7. Migrate content; run parallel until parity.
8. Institute a WP core/plugin patch cadence tied to Composer updates.

Operational Impact

Maintenance

• Small code surface, but you inherit the full WordPress maintenance lifecycle: core updates, plugin updates, security patches, PHP version compatibility, and database migrations. Composer becomes the patch channel; if the WP core package lags upstream releases, you carry exposure.
• GPL-2.0 compliance review is required if the combined product is distributed. Internal/SaaS use is generally lower risk but should be confirmed by legal.

Support

• Community-supported via Roots; no commercial SLA. With 39 stars and 0 dependents, external troubleshooting evidence is thin. Budget internal ownership and a documented runbook.
• Two ecosystems means two support paths: Laravel and WordPress. Escalation boundaries must be explicit.

Scaling

• The installer is deployment-time only; it does not affect runtime scaling. WordPress scaling remains a separate concern (database, object cache, page cache, media offload).
• Headless separation scales cleanly: Laravel and WP scale independently. Colocation couples PHP-FPM workers and risks noisy-neighbor effects, shared session confusion, and deploy coupling.

Failure modes

• Composer blocks the plugin (allow-plugins) and install fails or silently skips path customization.
• WP core lands in vendor/ or the wrong webroot, causing 404s and broken admin.
• Duplicate front controllers or rewrite rules route traffic to the wrong app.
• WordPress auto-updates overwrite Composer-managed core, causing lockfile drift.
• wp-content unversioned or undeployed, producing environment drift.
• GPL contamination or distribution obligations missed.
• Security vulnerability in WP core or a plugin without a tested patch/rollback path.

Ramp-up

• Low for engineers already fluent in Composer and Bedrock conventions.
• Medium for Laravel-only teams: they must learn WordPress bootstrap, plugin lifecycle, wp-config, and Bedrock env conventions.
• Recommend a short enablement track covering WP core patching via Composer, wp-content deployment, and rollback. Given the low opportunity score and narrow adoption, treat this as a tactical enabler only if WordPress is already mandated—not as a strategic Laravel integration bet.