Cms Workspaces Laravel Package

Product Decisions This Supports

• Build vs. buy for editorial governance. Workspaces is the draft → review → publish layer of TYPO3 (versioned records, per-stage permissions, side-by-side diff of changes before publishing). If the roadmap contains “approval workflow,” “staged publishing,” or “content audit trail,” this capability already exists in the platform rather than being a custom build.
• Roadmap scoping for editorial workflow features. Anything you would spec as “draft/preview/publish/schedule” is largely covered; net-new scope is narrower — e.g. external review links, Slack/Teams notifications, or multi-tenant stage policies.
• Compliance and risk decisions. Versioned content plus stage-based permissions gives an auditable answer to “who changed what, who approved it, when did it go live” — a common requirement in regulated, public-sector, and multi-brand environments.
• Segmentation and pricing/packaging. Workspaces is a strong differentiator for “editorial team” or “enterprise” tiers versus single-author brochure sites; it can justify tier gating without new engineering.
• Release and upgrade planning. Because it ships with the TYPO3 core (a typo3/cms-* system extension in the monorepo), its version is bound to the TYPO3 major. Every TYPO3 major upgrade is implicitly a workspaces upgrade, and deprecations follow a documented one-major notice policy.
• Platform-choice decisions. Note the framing risk: this is not a Laravel/Symfony-standalone package. It is a TYPO3 system extension, only meaningful inside a TYPO3 installation (it depends on TCA, DataHandler, the backend module stack, and PSR-15 middleware). The 1,219 stars and 0 Packagist dependents reflect that it is installed via typo3/cms-core rather than required directly — do not read the dependent count as an adoption signal.

When to Consider This Package

Consider it when:

• You are already on (or committed to) TYPO3 v12/v13/v14+ and need staged publishing — the marginal cost is configuration, not integration.
• Editors and approvers work in the TYPO3 backend UI and you want preview-before-publish with visual diffing out of the box.
• You need stage-scoped permissions (editor vs. reviewer vs. publisher) without building an authorization layer.
• You want governance without a vendor contract or per-seat workflow licence — it is GPL-2.0 and core-maintained.
• You can absorb TYPO3 major-upgrade cadence, since feature availability and API surface move with the core.

Look elsewhere when:

• You are on Laravel, Symfony standalone, Drupal, or a headless CMS — nothing here is portable; the equivalent would be a custom versioning + workflow layer (or a dedicated workflow engine).
• You need API-first or headless editorial workflows; workspaces is backend-UI-centric, and exposing draft state through APIs is bespoke work.
• You need real-time collaborative editing (Google-Docs style). Workspaces is record-locking/version-based, not concurrent co-editing.
• You need git-like branching, merging, and long-lived divergent content lines across many parallel campaigns — workspaces is linear-per-record, not a branching model.
• You require vendor SLAs, indemnification, or a non-copyleft licence. GPL-2.0 is a hard constraint for some legal teams, particularly where TYPO3 is embedded in proprietary distributions.
• Your content workflow must span systems outside TYPO3 (DAM, PIM, translation vendors) as first-class steps; that is orchestration you would build or buy separately.

How to Pitch It (Stakeholders)

For executives: We get enterprise-grade editorial governance — drafts, review stages, approval permissions, and a full publish history — at zero licence cost, because it is part of the CMS we already run. It de-risks “who published this and when” questions and lets us gate publishing behind named approvers without a new procurement cycle. The cost is not a contract; it is our TYPO3 upgrade cadence, which we already carry.

For engineering: It is a core-maintained system extension inside the TYPO3 monorepo — same CI, same PHPStan/functional/e2e gates, no third-party maintenance burden. It integrates through the standard extension points we already use: PSR-14 events (not legacy hooks), DI via Services.yaml, TcaSchemaFactory for schema reads, and DataHandler as the write path. Expect it to move with TYPO3 majors, with one-major deprecation notices, so budget upgrade effort rather than integration effort. It is GPL-2.0 — confirm that is compatible with how we distribute.

Honest caveats to state up front: backend-UI-centric rather than API-first; no real-time co-editing; linear versioning rather than branching/merging; and it is not reusable outside TYPO3, so it is a commitment to the platform, not just to a feature.