Cms Core Laravel Package

Product Decisions This Supports

• Build vs. buy (CMS platform selection). typo3/cms-core is the foundation of the TYPO3 CMS — a full-stack, enterprise-grade content management system. It informs the decision to adopt a mature off-the-shelf platform rather than assemble one from Laravel/Symfony components, at the cost of accepting TYPO3's conventions, hosting model, and upgrade cadence.
• Multi-site and multi-brand consolidation. A core capability: one installation serving many sites, domains, languages, and permission boundaries. Relevant to roadmap decisions about consolidating fragmented web estates onto a single platform.
• Editorial governance and compliance roadmap. Workspaces (draft/staging/publish), granular role-based permissions, audit trails, and translation workflows ship in core. This supports go/no-go decisions in regulated or multi-stakeholder environments where "can editors publish without engineering?" is a hard requirement.
• Localization strategy. Built-in XLIFF-based translation handling and language overlays make "how many locales can we ship in year one?" a configuration decision rather than a re-architecture.
• Delivery architecture: hybrid vs. headless. The core provides the content backend plus PSR-15 middleware and event hooks, so the product decision is whether to render server-side (Fluid) or expose content to a decoupled frontend. This is a reversible decision if made early — worth flagging in architecture review.
• Licensing and distribution strategy. GPL-2.0 is a real product constraint, not a footnote: it shapes whether the platform can be embedded in a distributed commercial product, and it must be cleared before committing to a build.
• Total cost of ownership and staffing. The decision to adopt carries an implicit decision to hire or partner with TYPO3-competent PHP engineers. That should be a conscious, budgeted choice, not a discovery in sprint three.
• Extensibility vs. fork. The package is designed to be extended via dependency injection, PSR-14 events, middleware, and configuration overrides — so "we'll just fork the core" should be an explicit anti-decision documented in the architecture record.

What this package does not support: it is not a library to be dropped into an existing Laravel or Symfony application, and it is not a source of reusable components. If the product decision is "add CMS capabilities to our existing app," this is the wrong input — evaluate Symfony components, a headless SaaS CMS, or Laravel-native admin tooling instead.

When to Consider This Package

Consider adoption when:

• The product needs multi-site, multi-language, multi-domain content from day one, with per-site permissions.
• There is a non-trivial editorial organisation (dozens of editors, approval chains, scheduled publishing) and governance must be enforced by the tool, not by process documents.
• Content has a long lifespan (5–15 years) and the organisation values predictable LTS releases, deprecation tooling, and a documented upgrade path over bleeding-edge developer experience.
• Self-hosting or data residency is mandatory — the platform is yours to operate, with no vendor content store.
• An in-house PHP team or agency partner exists, or budget exists to acquire one.
• The delivery model may evolve from server-rendered to decoupled/headless, and you want the backend to survive that pivot.

Look elsewhere when:

• The scope is a marketing site, blog, or brochureware. WordPress, Statamic, Craft CMS, or a Laravel + Filament build will reach value faster and cheaper.
• The team is Laravel-first. TYPO3 is a separate framework with its own DI container, templating (Fluid), and persistence (Extbase/Doctrine). Adopting it means operating two ecosystems, not one.
• The requirement is embedding CMS features into an existing application. Take the Symfony components or a headless API instead.
• GPL-2.0 copyleft cannot be cleared — for example, a distributed commercial product that would be treated as a derivative work. Get legal input; do not assume.
• The organisation wants a fully managed SaaS with zero infrastructure ownership. Evaluate Contentful, Storyblok, Sanity, or DatoCMS.
• There is no appetite for operational ownership (PHP-FPM, database, Solr/Elasticsearch for search, caching, upgrade cycles).
• Fast iteration on a small surface matters more than breadth. TYPO3's breadth is its value; on small products it becomes overhead.

Two signals to interpret carefully: the ~1.2k GitHub stars reflect the read-only Gerrit mirror, not ecosystem adoption, and Dependents: 0 is expected because production installs pull the meta-package typo3/cms-base-distribution, which depends on typo3/cms-core transitively. Do not require typo3/cms-core directly in composer.json — that is a known path to version conflicts. Measure project vitality through Gerrit review activity, release cadence, and TYPO3 Association membership instead.

How to Pitch It (Stakeholders)

For executives — one paragraph: TYPO3 is a mature, self-hosted enterprise CMS with a 20-year track record, a GPL-2.0 licence (no per-seat fees), and a governance feature set — workspaces, approvals, granular permissions, multi-site, multi-language — that typically costs extra or requires custom build on lighter platforms. The trade is operational ownership and specialist staffing against licence fees and platform risk. Recommend it where content governance, multi-brand scale, and long-lived content are core; not for small sites.

Value framing to lead with:

• Risk reduction. Security-hardened core, defined LTS windows, and an extension scanner plus changelog tooling that makes upgrades a planned cost rather than an incident.
• Cost structure. Zero licence spend, but budget explicitly for hosting, an agency or in-house TYPO3 capability, and a major-upgrade cycle every few years. Present TCO, not licence price.
• Governance as a product feature. Editorial workflows and permissions reduce the compliance and brand-risk exposure of a large distributed editing population.
• No lock-in on delivery. Content can be rendered server-side today and exposed to a decoupled frontend later, protecting the frontend investment.

For engineering — what they are actually getting:

• PHP 8.2+ with strict typing; a compiled Symfony DI container; constructor injection as the standard, with GeneralUtility::makeInstance() treated as legacy.
• A PSR-15 middleware pipeline per request type (frontend/backend) for cross-cutting concerns, and PSR-14 events as the sanctioned extension mechanism — hooks are legacy and should not be used in new code.
• A package/extension system with per-extension Services.yaml, tagged services, and TCA/Extbase configuration overrides. Extend, never fork.
• Doctrine DBAL for persistence, Fluid for templating, and first-class functional/unit testing support via FunctionalTestCase.
• A single container-based test dispatcher (Build/Scripts/runTests.sh) covering unit, functional, static analysis, and Playwright end-to-end suites — so CI parity is credible from week one.

Objections to pre-empt:

• "The GitHub repo looks inactive." It is a read-only mirror; development happens on Gerrit. Show the review queue and release history.
• "Isn't this just for big government sites?" That is the sweet spot, but the same governance features pay off anywhere editorial scale or multi-brand complexity exists.
• "We're a Laravel shop." Be direct: this is a second framework. Either commit to the capability or choose a Laravel-native path — a half-committed adoption will underperform both options.