Headless Bundle Laravel Package

Product Decisions This Supports

• Decoupled delivery architecture: This bundle is the official bridge that turns Sulu CMS content into JSON responses. Adopting it is the enabling decision for serving the same content to a Next.js/Nuxt SPA, a mobile app, or multiple channels without each team re-implementing content serialization.
• Build vs. buy on the content API layer: Release 3.0.2 is almost entirely maintenance of the response contract ("expected responses") as the CMS data model evolves. That is the recurring cost you would absorb if you built a bespoke content API — a concrete argument for buying/using the official bundle rather than owning that mapping yourself.
• Media handling strategy: The addition of Sulu 3.0.9 media properties to expected responses confirms media metadata is part of the delivered payload. This supports the product decision of whether image variants, focal points, and media metadata are resolved frontend-side (flexible, more client logic) versus pre-baked server-side (simpler clients, less flexible).
• Platform upgrade roadmap: Symfony 8 support removes the framework as an upgrade blocker. If Symfony 8 is on your technology roadmap, this release lets the content layer move in step rather than lagging behind.
• Release and pinning sequencing: The response changes are tied to a Sulu minimum version (3.0.9). That introduces a coupled upgrade constraint — CMS version, bundle version, and client contract versions must be planned together, which affects sprint/release planning.

When to Consider This Package

Consider adopting when:

• You run Sulu CMS 3.x and want a headless/API-first content delivery model rather than Twig-rendered pages.
• You want the official, vendor-maintained serialization layer instead of a custom controller/serializer stack — lower long-term maintenance and better alignment with CMS upgrades.
• Symfony 8 compatibility is a requirement in your platform standards, or you want to avoid being pinned to an older framework by the CMS layer.
• You need multi-channel or multi-frontend delivery from a single content source, and REST/JSON is an acceptable contract.
• Your team already has Symfony/PHP operational competency and can own a self-hosted CMS.

Look elsewhere when:

• You are not on Sulu. Despite being a PHP package, this is a Symfony bundle for Sulu specifically — it is not a Laravel package. A Laravel application would consume Sulu's HTTP API as a client, not install this bundle. Laravel-native alternatives (API resources over your own models, or a Laravel-friendly CMS) are the better comparison.
• You need GraphQL-first delivery — this is a REST/JSON layer; confirm the Sulu GraphQL story separately if that is a hard requirement.
• You are on Sulu 2.x — this is the 3.x line and will not apply.
• You want a managed/SaaS CMS with no self-hosting or PHP upgrade obligation (Contentful, Storyblok, Sanity, etc.).
• You need a formal commercial SLA/LTS commitment — this is community-maintained open source; factor in your own support and upgrade capacity.
• Your contract surface is large and strictly versioned — every "expected responses" change is a potential client-breaking delta you must test for.

How to Pitch It (Stakeholders)

To executives: This is a routine, low-risk maintenance release of the official Sulu headless bundle. It adds two things: coverage for new media fields introduced in the CMS, and support for the newest Symfony version. There are no breaking changes, nothing is deprecated, and no immediate migration work is required. The strategic value is that it keeps our content platform on a supported framework and keeps the API in sync with the CMS data model — which is precisely the upkeep we would otherwise be paying for with custom code.

To engineering: 3.0.2 is additive. Media properties from Sulu 3.0.9 are now included in expected responses, so any consumer with strict response validation or typed frontend models should update fixtures and confirm contract tests pass. Symfony 8 support is present but should be validated in a branch before we commit to a framework upgrade, since it implies movement across the whole Sulu/Symfony dependency set. Pin the bundle and the Sulu core together — the response contract is now explicitly version-coupled.

Recommendation: Adopt the patch, run contract tests against the media response delta, and treat Symfony 8 as a separate, planned upgrade workstream rather than an incidental bump.