Cms Workspaces Laravel Package

Technical Evaluation

Bottom line: despite the Packagist framing, this is not a Laravel package. typo3/cms-workspaces is a TYPO3 Core system extension ("sysext") — a Composer package split out of the TYPO3 monorepo, hard-coupled to typo3/cms-core. The "Dependents: 0" figure reflects split-package metadata, not a lack of adoption; 1,219 stars are the monorepo mirror's, not this component's. The low opportunity score (27.21) is consistent with "not designed for reuse outside its host application."

Architecture fit — none for Laravel. Workspaces implements editorial staging: records are versioned in place (t3ver_* fields), edited against a sys_workspace with configurable stages, previewed, and published through DataHandler — TYPO3's central write path. It leans on TCA/TcaSchemaFactory, the Symfony DI container and failsafe container, PSR-15 backend middleware, PSR-14 events, and TYPO3 backend modules with Fluid templates. None of these primitives exist in a Laravel application: no service provider, no Eloquent models, no Blade views, no Laravel events, no queue jobs. There is no seam at which it can be dropped into composer require of a Laravel project.

Integration feasibility — three real options, one of which is "don't."

1. Adopt TYPO3 wholesale for the content domain, run it as a separate application, and expose content to the Laravel app via TYPO3's frontend/JSON output or a headless API. Feasible; it is a second platform, not an integration.
2. Treat it as a reference architecture for a Laravel-native draft/publish capability (version table + staging state + publish job + dependency check). Reasonable, zero code reuse, no license exposure.
3. Port or link the PHP directly — not viable. The code assumes TYPO3 bootstrap, $GLOBALS['TCA'], and DataHandler.

Technical risk — high.

• License: GPL-2.0. Distributing a derivative work linked into a proprietary Laravel product is a copyleft exposure. This alone should stop option 3 and force legal review on any "we'll just call into it" design.
• Coupling: upgrades are gated on TYPO3 major versions and core deprecation cycles (deprecate in one major, remove in the next), not on our release cadence.
• Contribution path: the GitHub repo is a read-only mirror of Gerrit; PRs are not accepted there. Any bug we hit must be reproduced as a test, fixed upstream through Gerrit review, and released on TYPO3's schedule. We cannot patch-and-ship.
• Publish semantics: publishing runs as a transactional DataHandler operation with dependency resolution across versioned relations; partial failures and large publish sets are the known sharp edges.

Key questions for the requesting team:

• Is the actual requirement CMS editorial workflow (stages, preview, scheduled publish, cross-record dependency checks) or generic draft/publish on domain models? The latter is a 1–2 sprint Laravel feature, not a platform decision.
• Is GPL-2.0 acceptable in the deployment/distribution model? If the product is closed-source SaaS plus on-prem, no.
• Is TYPO3 already in the estate, or would this introduce a new CMS? Who operates it?
• Who owns the content model — Laravel developers or a TYPO3 integrator?
• What is the real driver: editorial governance, audit trail, or scheduled publishing? Each maps to cheaper Laravel-native options.

Integration Approach

Stack fit. Zero fit with Laravel's container, ORM, routing, or view layer. Fit with TYPO3 v13 LTS/v14 is native by definition — it is a core sysext, installed as part of the TYPO3 package set, not as an independent library. Treat "integration" as federation between two applications, or reject it.

Migration path. There is no migration from a Laravel codebase to this package. Migration only exists in the reverse direction: if we adopt TYPO3 for content, it is a greenfield TYPO3 install (base distribution, site configuration, TCA-defined content model, backend users assigned to workspaces, stages configured per workspace), with the Laravel application retaining its own domain data and consuming published content over an API boundary. Nothing is shared at the database or session level — do not attempt a shared MySQL schema.

If we instead build the capability natively (recommended for a Laravel shop), the path is: version table keyed on model + version, draft state machine (draft → in review → published → archived), publish action dispatching a queued job that resolves relation dependencies, preview route behind policy gates, and an audit log. Existing Laravel versioning/audit packages cover roughly half of this.

Compatibility. Runs on current PHP 8.x with MySQL/MariaDB/PostgreSQL/SQLite and TYPO3's supported web servers. Incompatible with Laravel's service container, Eloquent, Blade, Horizon, and Laravel's event dispatcher — by construction, not by version drift. No compatibility matrix to negotiate; there is simply no intersection.

Sequencing (if leadership still wants it):

1. License and distribution-model review — hard gate, week 1.
2. Requirements decomposition: editorial workflow vs. generic versioning. Decision memo.
3. If TYPO3: stand up a TYPO3 instance in a non-production environment, model content in TCA, configure workspace stages, prove one end-to-end edit → review → publish → API delivery flow with a real editor.
4. Define the Laravel↔TYPO3 contract (content API shape, caching, auth, publish webhook), and assign platform ownership.
5. Only then estimate. Do not size the TYPO3 instance before step 3 proves the content model.

Operational Impact

Maintenance. Two release trains to track if both platforms are retained. This sysext moves with TYPO3 majors; skipping a major is expensive, and the deprecation policy removes APIs one major after marking them. Upstream fixes require Gerrit review, so we carry any local divergence as a fork — a fork of a GPL core package we then must maintain ourselves.

Support. Community-only: TYPO3 Slack, Forge (Redmine) issues, Stack Overflow, and docs.typo3.org. Commercial SLAs exist only through TYPO3 GmbH or a partner agency, and only for TYPO3. Our Laravel team gets nothing — no vendor, no mutual escalation path, and a bug in publish semantics is a bug in someone else's core.

Scaling. Workspaces is write-amplifying: version rows, sys_history, and sys_log growth on every editorial action, plus publish operations that run as heavy transactional writes. Editorial concurrency is fine at dozens of editors; publish throughput is the ceiling, and large publishes are the operation that times out. Preview rendering adds load to the frontend tier. If content volume is high, plan for archive/pruning of history and publish batching. None of this scales horizontally the way Laravel + queue workers does; it is a monolith with a backend module.

Failure modes to design for.

• Partial publish leaving mixed live/draft state on related records.
• Versioned relations pointing at moved or deleted pages — publish fails late with an opaque error.
• Cache invalidation not covering the live page after publish, so editors "publish" into a stale cache.
• Preview URLs leaking draft content past access controls — a real information-disclosure risk if route/policy config drifts.
• Schema/version drift between TYPO3 majors breaking a custom extension we wrote against it.
• License contamination discovered post-launch, forcing a rewrite under pressure.

Ramp-up. A Laravel developer needs roughly 2–4 weeks to be useful in TYPO3 core patterns (TCA, DataHandler, DI/ServiceProvider split, PSR-14, Fluid) and longer to be safe around workspaces publish semantics. That knowledge is largely non-transferable back to the Laravel codebase. Budget a TYPO3 integrator, not a reassigned Laravel engineer.

Recommendation. Do not adopt this package into a Laravel product. Approve a 2-week spike to (a) confirm whether the underlying need is editorial workflow or generic draft/publish, and (b) produce a Laravel-native design if it is the latter. Revisit TYPO3 only if the organisation has already decided to introduce TYPO3 as a CMS for editorial reasons — in which case workspaces is a free, first-class feature of that decision, not an integration project.