Framework Laravel Package

Product Decisions This Supports

• Hybrid CMS/Headless Architecture: Enables seamless integration of Laravel’s backend capabilities (e.g., APIs, business logic) with WordPress’s frontend (e.g., Gutenberg, themes, plugins) without full migration. Ideal for teams needing WordPress’s ease of use but requiring Laravel’s scalability for custom logic, payments, or complex workflows.
• Incremental Modernization: Roadmap item for gradually replacing legacy WordPress plugins with Laravel microservices (e.g., user auth, e-commerce) while retaining WordPress for content management. Reduces risk by phasing out monolithic WordPress plugins.
• Build vs. Buy: Avoids reinventing the wheel for WordPress-Laravel integration (e.g., shared sessions, database sync, REST API bridges). Justifies internal dev effort by leveraging this framework to accelerate feature delivery (e.g., headless WordPress + Laravel admin panels).
• Platform Baseline Decisions (New in v2.0.0): The package now targets Laravel 12 as its framework baseline. This makes v2.0.0 a forcing function for a stack-alignment decision: plan the Laravel 12 upgrade (PHP 8.2+ runtime, dependency audit, test suite re-run) as a prerequisite to adopting or continuing on this package, rather than discovering it mid-sprint. Treat the major version bump as a scheduled roadmap item, not an incidental dependency refresh.
• Use Cases:
  • Enterprise Sites: High-traffic sites needing Laravel’s performance (e.g., caching, queues) but WordPress’s editor for non-technical users.
  • Agencies: Rapid prototyping of client sites with WordPress frontend + Laravel backend (e.g., custom CRMs, membership systems).
  • E-commerce: Combining WooCommerce (WordPress) with Laravel’s advanced features (e.g., subscription logic, multi-vendor marketplaces).
  • Multilingual Sites: Leveraging Laravel’s localization packages alongside WordPress plugins like WPML/Polylang.

When to Consider This Package

• Adopt When:
  • Your team is comfortable with Laravel/PHP but needs WordPress’s frontend flexibility.
  • You are on Laravel 12 (or committed to upgrading) — v2.0.0 is built on Laravel 12, and the prior major line is the supported path for older Laravel versions. Confirm which line your application should pin before scoping work.
  • You’re migrating from WordPress plugins to custom Laravel services and want a scaffolded approach.
  • You need shared authentication/sessions between WordPress and Laravel (e.g., user logins, roles).
  • Your roadmap includes headless WordPress but requires a gradual transition (not a full rewrite).
  • You’re building a composite application where WordPress handles content and Laravel handles business logic (e.g., SaaS with WordPress as a portal).
• Look Elsewhere If:
  • You are pinned to Laravel 10/11 or older and cannot absorb a framework upgrade in the current cycle — stay on the previous major line or defer adoption. Do not assume a backport.
  • You need full headless WordPress without a Laravel backend (consider Strapi, Directus, or WordPress REST API + frontend framework).
  • Your team lacks Laravel/PHP expertise (steep learning curve for integration).
  • You’re locked into WordPress-only plugins with no Laravel alternatives (e.g., niche plugins like Advanced Custom Fields).
  • Performance is critical for high-load APIs (Laravel may add overhead; consider native PHP or Go services).
  • You’re building a static site (use Next.js + WordPress as a headless CMS instead).
• Upgrade Risk Note (v2.0.0): The published notes state only that v2.0.0 is based on Laravel 12 — no migration guide, deprecation list, or changed-surface detail was included. Before committing an upgrade, run a spike on a branch to catalogue breaking changes across your integration points (shared auth hooks, database sync, REST bridges) and budget upgrade + regression testing accordingly.

How to Pitch It (Stakeholders)

For Executives: "This framework lets us combine the best of both worlds: WordPress’s intuitive content management for editors and Laravel’s scalability for custom business logic—without a costly full rewrite. For example, we could modernize our e-commerce site by moving payment processing to Laravel while keeping the WordPress storefront. This reduces technical debt, speeds up feature delivery, and future-proofs our stack for headless architectures. The new v2.0.0 release rebases the package on Laravel 12, which keeps us on a currently supported PHP/Laravel foundation and avoids accumulating framework debt—at the cost of a one-time upgrade effort we should schedule deliberately rather than absorb accidentally. The MIT license and active maintenance make it a low-risk bet."

For Engineering: *"wpstarter/framework gives us a battle-tested scaffold to integrate WordPress and Laravel cleanly—handling shared sessions, database sync, and REST API bridges out of the box. Key benefits:

• Shared Auth: One login system for WordPress and Laravel (uses Laravel’s auth + WordPress hooks).
• Database Flexibility: Choose to sync WordPress tables with Laravel’s Eloquent or keep them separate.
• Plugin Replacement: Replace bloated WordPress plugins with Laravel services (e.g., turn a custom user roles plugin into a Laravel microservice).
• Headless-Ready: WordPress as a CMS + Laravel APIs for any frontend (React, Vue, etc.).
• Current Framework Baseline: v2.0.0 targets Laravel 12, so we inherit upstream security and dependency support rather than sitting on an EOL line.

What changed in v2.0.0: the package is rebased on Laravel 12. The release notes contain no migration guide or breaking-change list, so treat this as a major-version upgrade with unknown blast radius:

• Version pinning: Lock the major version explicitly in composer.json; do not float across the v1→v2 boundary. Projects still on Laravel 10/11 should remain on the prior major line until the framework upgrade lands.
• Pre-upgrade spike: Branch-upgrade and exercise every integration seam we rely on — auth/session sharing, DB sync, REST bridges, queue/cache config — and capture a diff of published config and service providers.
• Regression budget: Reserve QA time proportional to integration depth; auth and data-sync paths are the highest-risk surfaces.
• Runtime prerequisite: Confirm PHP 8.2+ across dev, CI, and production before scheduling the upgrade.

Tradeoff: Adds ~20% initial setup time vs. rolling your own integration, but saves months on maintenance. Ideal for projects where WordPress is the frontend and Laravel is the backend brain — provided the team can absorb a framework-major upgrade on a planned schedule."*