Wordpress Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for the content layer. The core decision this enables is: do we rebuild editorial tooling inside Symfony, or reuse WordPress's mature authoring/admin experience and keep our differentiated product logic in Symfony? This bundle is the "reuse" option — it lets WordPress serve as the CMS while Symfony owns routing, services, and application behavior.
• Architecture selection: hybrid monolith vs. headless vs. replatform. It makes a third path viable — server-rendered Symfony pages hydrated with WordPress content — instead of a headless WP + JS frontend or a full CMS migration. That changes cost, timeline, and team shape.
• Roadmap sequencing for content-heavy products. Ship SEO-critical pages, editorial workflows, and media management early via WordPress, then layer authenticated/product features (billing, accounts, workflows, integrations) in Symfony without a second platform.
• Incremental migration off WordPress. If WordPress is a legacy liability but a big-bang replatform is too risky, this supports a strangler-style path: keep WP for content, move surfaces to Symony one at a time.
• Feature scoping by surface. Forces an explicit decision on which capabilities are WP-driven (posts, pages, media, SEO/marketing plugins) vs. Symfony-driven (auth, commerce, business rules) — useful for scoping and ownership.
• Editorial control over block-level authoring. The new blog.registered_blocks Twig accessor lets templates filter and re-expose WordPress's registered block list to <InnerBlocks>, so product/marketing can constrain which blocks editors get in a given template without a plugin fork. Small, but it moves "restrict the editor UI" from a WordPress-plugin decision into a Symfony-template decision — useful for governance and brand-consistency scoping.
• Use cases to evaluate: marketing site + gated app, editorial/content businesses, member portals, internal tools, catalog/brochure content in front of a transactional Symfony app, and teams preserving existing editor workflows during a framework modernization.

When to Consider This Package

Consider it when:

• You have real WordPress content/editorial investment you must preserve, and an engineering team that is Symfony-centric.
• You need SEO-friendly server-rendered pages and custom application logic in one deployable, without standing up a separate JS/headless stack.
• You want WordPress plugins (SEO, forms, media) to keep working while Symfony owns the request lifecycle.
• You are small-to-mid scale, single-team ownership, and can tolerate coupling between two frameworks.
• You need a pragmatic migration bridge rather than a full replatform.
• You are on a supported Symfony version. Release 3.0.2 dropped Symfony 4 support. Confirm the floor against your composer.json before assuming this is a drop-in — teams on Symfony 4 face a forced Symfony upgrade first, or must pin to an older bundle line and own an unsupported dependency.
• You need current WordPress compatibility. 3.0.2 adds WordPress 7 support, which matters if your content team plans to be on current WP within the next upgrade window.

Look elsewhere when:

• Ecosystem risk is unacceptable. 75 stars and 0 dependents is thin validation; there is no crowd to inherit bug fixes or patterns from. Require a code review, issue-tracker responsiveness check, and maintainer commitment assessment. The 3.0.2 release is a positive maintenance signal — it ships a real correctness fix, tracks a new WordPress major, and makes a clear (if breaking) compatibility call rather than letting dead version support linger — but a recent release is evidence of activity, not a guarantee of longevity.
• You can decouple instead. Headless WordPress + Next.js/Remix, or a Symfony-native CMS (Sulu, Sylius, Craft/Statamic as applicable) may be cleaner if you don't need WP's admin specifically.
• Scale, uptime, or security posture is demanding. Booting two frameworks, WordPress's global state, and the WP plugin surface add operational and security overhead. Multi-tenant, high-traffic, or regulated contexts deserve extra scrutiny.
• The team lacks dual expertise. You inherit two upgrade cadences (WordPress core, Symfony, plus this bundle) and two debugging models — and 3.0.2 is a live example of that: a Symfony floor change and a WP major adoption landing in the same patch release.
• Licensing/distribution matters. MIT for the bundle is friendly, but embedding WordPress raises GPL and derivative-work questions if you distribute the product. Get legal input early.
• Your content model is simple (WordPress is overkill) or highly structured (WordPress will fight you; a structured CMS or custom Symfony entities will be better).

How to Pitch It (Stakeholders)

For executives: This lets us keep the WordPress investment our editors already know and avoid a six-figure CMS rebuild, while our engineering team builds the differentiated product in Symfony. It compresses time-to-market for content-heavy launches and preserves an incremental migration path if we later move off WordPress. MIT licensing keeps costs low. The trade-off is a smaller open-source community and a dual-stack operating model, so we should fund a timeboxed proof-of-concept with explicit exit criteria before committing it to the roadmap. Two things from the latest release belong in that decision: the package now requires a modern Symfony (Symfony 4 is no longer supported), so if we are behind on Symfony that upgrade cost lands on us first; and it added WordPress 7 support, which means we are not adopting something that will be stranded on an EOL CMS.

For engineering: The bundle bridges the two request lifecycles so WordPress APIs and content are available inside a Symfony application, letting Symfony own routing, DI, Twig rendering, and testing while WordPress handles authoring. Release 3.0.2 requires attention in three areas. First, it drops Symfony 4 — treat this as the compatibility floor: verify our Symfony version in the spike's first hour, and if we cannot move off 4.x, we are pinning to an unsupported branch and should say so explicitly in the ADR. Second, it fixes weak cache key generation, which is a correctness and potential cross-content-leak class of bug; upgrade rather than backport, and audit any cache layer or reverse proxy we built against the previous key scheme, since key shapes may have changed and stale entries could serve wrong content after deploy. Third, blog.registered_blocks is a small, low-risk convenience — it exposes WP's registered block registry to Twig, but note the documented pattern is client-visible JSON in an <InnerBlocks> attribute, so treat it as editorial UI configuration, not a security boundary; block restrictions must still be enforced server-side. Adopt behind an adapter boundary, pin WP/Symfony/bundle versions, and plan for global-state and boot-order quirks plus plugin upgrade hygiene. Success criteria for the spike: authenticated Symfony route rendering WP content, editor workflow intact, measurable performance overhead, and a documented upgrade/rollback procedure that includes the Symfony floor and the cache-key migration.