Core Laravel Package

Technical Evaluation

Architecture fit — poor as a package, viable as a separate application. redaxo/core is not a Laravel package; it is a complete PHP CMS distribution. It assumes ownership of the front controller (index.php), the redaxo/ backend entrypoint, a writable data/ and redaxo/cache/ directory, its own autoloader, its own rex_* class namespace (global, not PSR-4 under a vendor prefix), its own SQL abstraction (rex_sql, rex_sql_table), its own permission and session model (rex_user, rex_user_session, rex_user_passkey), and its own template + "module" system where input/output is literally paired PHP. There is no service provider, no facade, no container binding, and no published contract intended for framework consumption. Treating it as a Composer dependency inside a Laravel app is an architectural anti-pattern; the realistic pattern is two co-deployed applications with a narrow, explicitly designed boundary.

Integration feasibility — low-to-moderate, with one acceptable shape. The defensible option is REDAXO as a separately deployed editorial backend (own vhost or path prefix) with Laravel as the delivery/API tier reading content out of REDAXO's tables (rex_article, rex_article_slice, rex_media, rex_category) via a read-only connection or a thin adapter. REDAXO has no first-class REST/GraphQL API in core, so the read layer is ours to build and own — that is real, unbudgeted engineering. Embedding Laravel inside a REDAXO addon, or REDAXO inside a Laravel route, is technically possible and operationally regrettable: two error handlers, two session handlers, two autoloaders, two config sources, and ambiguous request ownership.

Technical risk — concentrated in security surface and content model lock-in. The published changelogs (5.21.3 → 5.21.5) show a high cadence of security advisories, several severe: privilege checks missing in the package API, CSRF missing on safe-mode toggling, a frontend-preview path that could mint a backend session for arbitrary accounts including admins, stored XSS in media/link widgets, and an export permission gap exposing password hashes. Responsiveness is genuinely good (fast, well-described GHSAs), but this is a large attack surface that we must patch on a schedule. Second risk: the module system encodes business logic as PHP in the database, which is powerful for editors and hostile to code review, version control, and CI. Third: license metadata says NOASSERTION while the README claims MIT — permissive either way, but legal/SBOM sign-off is required before shipping.

Key questions for the spike.

1. Does Laravel or REDAXO own the content system of record? If Laravel, why is REDAXO in the stack at all?
2. Is an editorial UI actually a requirement, or is this a content-delivery need that a headless CMS or a Laravel admin panel already satisfies?
3. Who owns the monthly security-patch cadence for a second runtime, and does that person exist?
4. What is the English-language support story for an on-call rotation that cannot read German changelogs?
5. Is the release metadata trustworthy? Last release: 2026-10-25 and changelog dates in late 2026 need provenance verification against the actual tagged artifacts before anything enters a build pipeline.
6. What is the exit cost if we abandon REDAXO in 18 months — is the content extracted cleanly, or is it trapped in serialized slice data?

Integration Approach

Stack fit — runtime compatible, everything else divergent. PHP 8.3+ aligns cleanly with current Laravel, and the repo carries PHPStan, Psalm, Rector, php-cs-fixer and PHPUnit baselines, which signals real engineering discipline. Beyond the interpreter version, nothing aligns: separate routing, separate auth, separate templating (REDAXO templates vs. Blade), separate asset pipeline, separate caching. Plan for "shared nothing except the database and the CDN."

Recommended topology. Laravel serves the product at the primary domain; REDAXO runs at cms.<domain> (preferred over a subpath, which invites cookie-path and rewrite collisions). Content flows one direction: REDAXO writes → adapter reads → Laravel renders. Optionally place a CDN or a Laravel cache layer in front so REDAXO is never in the hot request path. Keep REDAXO's data/, media/ and cache directories off the public web root except for the media path, and treat the editorial backend as an internal, IP-restricted surface.

Migration path. There is no supported importer in core for WordPress/TYPO3/Drupal content. Each content type must be rebuilt as a REDAXO module — an input/output PHP pair — which is bespoke developer work per type, not a configuration exercise. Budget per-module effort explicitly and pilot on 2–3 representative content types before committing to a full inventory. Demo sites (demo_base is fully English and explains the core concepts) are the fastest way to get a PM and a developer to a shared mental model.

Compatibility. Do not composer require redaxo/core into a Laravel application. REDAXO ships a bundled vendor tree and global rex_* classes; autoloading both in one process invites version conflicts on shared transitive dependencies with no clean resolution mechanism. If a read adapter is needed, define it as a small, versioned Laravel-side package that talks to the database or an HTTP endpoint, with the schema contract pinned and tested.

Authentication bridging. REDAXO's users live in rex_user with its own hashing, session table and passkey support. If editorial access must be governed by corporate SSO, expect custom addon work; nothing in core provides SAML/OIDC.

Sequencing.

1. Timeboxed spike (2–3 weeks): Docker-based REDAXO install, build three real modules, have an actual editor attempt a real publishing task. Exit criterion: editorial workflow is measurably better than the Laravel-admin alternative.
2. Decision gate on content ownership and topology; document the adapter contract.
3. Build the read layer and a cache invalidation trigger (REDAXO article save → Laravel cache purge).
4. Stand up hosting, CI/CD and a patch pipeline for both runtimes.
5. Only then migrate content type by type, with a parallel-run period.

Operational Impact

Maintenance — the dominant cost. Two runtimes, two release trains, two backup/restore procedures, two dependency trees. REDAXO's patch cadence is frequent and security-driven; a monthly maintenance window plus an out-of-band emergency path for advisories is mandatory, not optional. The backup addon covers database and file snapshots, but note its own recent advisory (export permissions could reach rex_user and session tables) — restrict that permission to admins only and verify against your install.

Support. Community-driven, German-first, with channels in Slack, FriendsOfREDAXO docs, API docs, and a "Tricks" site. Changelogs and issue triage are in German. There is no vendor SLA implied by the core repo; if enterprise support is a requirement, source it through a REDAXO partner and get it in writing before committing. Practically: your team writes its own runbooks, and your on-call rotation needs at least one person who can read German release notes or a standing translation step.

Scaling. Traditional PHP request/response with a filesystem cache under redaxo/cache. Horizontal scaling requires shared storage for cache and media and works best with a read replica for the Laravel read layer. REDAXO itself will not handle high-traffic personalized delivery — that is Laravel's job, with REDAXO behind a cache. Size expectations off "editorial traffic" (low concurrency, bursty) rather than public traffic.

Failure modes to design for.

• Cache contention: 5.21.5 fixed a "No clang found" error when the cache was cleared concurrently — indicative of filesystem-cache fragility under parallel requests. Mount cache on a single fast local volume; do not share it across autoscaled nodes.
• Directory-protection check: the daily check has triggered fail2ban and locked backend users out; the mitigation is the new use_directory_protection_check config flag. Decide this consciously at install time and document it.
• Safe mode and package operations: recent privilege bugs mean session-demoted admins could still install/uninstall addons. Audit admin group membership and treat addon operations as privileged changes requiring a change ticket.
• Upload handling: SVG and animated WebP/AVIF have produced stored-XSS and TypeError paths. Restrict upload MIME types, keep sanitization enabled, and patch proactively.
• Session coupling: password changes now invalidate session IDs and remember-keys — correct behavior, but it will surface as "unexpected logout" tickets after patching.
• Lock-in: content stored as PHP-in-database slices. Export and archive tooling is on you; test a full extraction before year one ends.

Ramp-up. Estimate 2–4 weeks for a competent Laravel developer to become productive in rex_* APIs, module authoring, and the addon model, plus meaningful extra time to build operational muscle. The static-analysis baselines and clean contribution guide shorten this; the German documentation and the absence of Laravel-style conventions lengthen it.

TPM recommendation. The scoring is directionally right: 0 dependents and an opportunity score near 30 reflect a mature, self-contained CMS with essentially no library-consumption ecosystem. Reject it as a Laravel package. Approve only a timeboxed spike for the "separate bilingual CMS backend alongside Laravel" pattern, gated on an editor-workflow win, a named owner for the security-patch cadence, and legal sign-off on the license. Without those three, the operational cost of a second runtime outweighs the editorial benefit.