Cms Frontend Laravel Package

Product Decisions This Supports

• Build vs. buy for the content layer. typo3/cms-frontend is not a Laravel package — it is the frontend subtree of the TYPO3 Core CMS (GPL-2.0, read-only mirror, zero dependents on this split package). The decision it actually informs is "do we adopt TYPO3 as our content platform instead of building editorial workflow, versioning, media management, and multilingual publishing ourselves?" It supports buy if the team needs enterprise editorial tooling and has or can hire TYPO3 capability; it does not support "add this to composer.json and get a frontend."
• Architecture direction: coupled CMS vs. headless content service. This package is the rendering half of TYPO3 (routing via page tree, TypoScript, Fluid templates). Choosing to consume TYPO3 only as an API and leave this package out of the request path is a distinct, usually better decision — it keeps the content backend while letting Laravel/React/Vue own the presentation layer. Treat "use the frontend package" and "run TYPO3 headless" as two different roadmap options, not one.
• Frontend modernization without content migration. If a legacy TYPO3 site exists, replacing Fluid templates with an API-driven frontend reduces template debt while preserving editorial workflows, URL/l10n history, and compliance posture. This is the highest-confidence use case for the package's ecosystem.
• Content consolidation across channels. One editorial system feeding web, app, and kiosk surfaces — a roadmap item this platform credibly supports, provided the delivery layer is an API, not this subtree.
• Licensing and distribution strategy. GPL-2.0 is a product-level constraint, not a detail: it's generally fine for internally operated or SaaS-hosted deployments (no distribution, no source-disclosure trigger), but it becomes a legal review item if you ship binaries/on-prem to customers alongside proprietary Laravel code. This should be settled before an architecture decision, not after.
• Explicit non-decision. The package's low opportunity score and zero dependents should be read as: it does not justify a greenfield investment, a framework migration, or a "replace Blade with Fluid" initiative. Do not let it anchor a roadmap.

When to Consider This Package

Consider the TYPO3 content platform (with this subtree as part of it) when:

• You already run TYPO3 and the goal is modernizing delivery, not replacing the CMS — the marginal cost is low and the editorial investment is preserved.
• Editorial requirements are genuinely enterprise-grade: page trees, workspaces/draft-preview, granular permissions, DAM, scheduled publishing, and mature i18n. Building these in Laravel is a multi-quarter effort with a permanent maintenance tail.
• You can deploy TYPO3 as an isolated service (separate container/subdomain/database) behind Laravel or a JS frontend — not co-mingled in one Laravel app.
• You have (or will fund) at least one person who can own TypoScript, Fluid, and Extbase; the Laravel team will not absorb this implicitly.
• Accessibility/GDPR compliance is a procurement gate and you want it covered by a platform rather than re-implemented per project.

Look elsewhere — or stop here — when:

• It's a greenfield Laravel product. This package conflicts with Laravel at every seam: page-tree routing vs. routes/web.php, Fluid vs. Blade, TYPO3 DBAL/Extbase vs. Eloquent, fe_users vs. Laravel auth, and Symfony-major version skew in Composer. Isolating it means you get little of the package's value.
• You want a headless CMS with a clean API contract. TYPO3's core does not ship a canonical REST/GraphQL content API — that requires extensions and custom endpoint work. Evaluate dedicated headless options (Strapi, Directus, Contentful, Sanity) against total cost first.
• The content model is simple (marketing pages, a blog) or the site is static/Jamstack-first — TYPO3's footprint (~50MB+ core and dependencies, its own caching layer, its own admin) is disproportionate.
• License compatibility with a proprietary distributed product is unresolved.
• The team is small and single-stack. Dual-stack maintenance (two CI/CD pipelines, coordinated PHP upgrades, split logging) is a standing tax that rarely shows up in the initial estimate.
• You need this specific split package as a standalone dependency — the subtree split is a convenience for Composer installs of the core; it is not a supported integration surface for Laravel.

Practical gate: before any commitment, run a time-boxed spike that proves (a) TYPO3 runs as an isolated service, (b) your chosen API path can serve real content types including media and translations, (c) auth between Laravel and TYPO3 is settled, and (d) cache invalidation works end to end. If any of those four fails cheaply, the answer is no.

How to Pitch It (Stakeholders)

For executives — one paragraph: "We evaluated TYPO3's frontend package as a way to get enterprise content management without building it. The honest finding is that it's not a drop-in for our Laravel stack — it's the rendering half of a separate CMS, and forcing it into our app would add cost and risk. Where it does pay off is if we already run TYPO3 and want to modernize the frontend: we keep the editorial workflows, media library, and multilingual publishing we'd otherwise spend quarters rebuilding, and we expose that content to new frontends through an API. Recommendation: no investment in the package itself; a scoped decision on whether TYPO3 becomes our content platform, with a four-week spike and a clear walk-away point before we commit budget."

For executives — the numbers to bring: engineering cost of building editorial workflow + DAM + i18n in-house (typically multiple quarters plus ongoing maintenance) versus the cost of one TYPO3-capable engineer and a second deployment pipeline; plus the licensing position (GPL-2.0 is workable for hosted/internal use, needs legal sign-off if we distribute to customers).

For engineering — the framing: "This is the TYPO3 frontend subtree, GPL-2.0, maintained as a read-only mirror of the core. It is not designed to coexist with Laravel's routing, Blade, Eloquent, or auth. If we adopt TYPO3, we adopt it as a separate service: TYPO3 owns content, editing, and asset management; Laravel owns business logic, auth, and the API surface; the two talk over HTTP with an explicit contract. That means a reverse proxy or API client, a defined content schema, a queue-based sync for anything we need locally, and centralized logging because stack traces will otherwise span two systems. The upside is real — mature content modeling we don't maintain — but the cost is a permanent dual-stack obligation: two CI pipelines, coordinated PHP upgrades, and at least one person fluent in TypoScript and Fluid. My recommendation is a spike on a non-critical content section, with the API contract and cache-invalidation behavior proven before we scale it."

The ask: approval for a bounded spike (one content type, one frontend surface, isolated deployment), an explicit owner for TYPO3 capability, and a legal read on GPL-2.0 against our distribution model — with a decision date and a pre-agreed fallback (headless CMS evaluation or Laravel-native content tooling) if the spike fails.