Source Laravel Package

Technical Evaluation

What this package actually is. redaxo/source is not a Laravel package — it is the distribution payload for REDAXO, a standalone PHP CMS (v5.21.5) that ships its own application framework plus a set of system addons (structure, mediapool, media_manager, backup, cronjob, metainfo, be_style, install). It does not register a service provider, publish config, or expose facades. It owns the request lifecycle end to end.

Architecture fit.

• REDAXO replaces rather than complements the Laravel stack: rex_sql / rex_sql_table instead of Eloquent + migrations, fragments/templates/modules instead of Blade, rex_list for grids, rex_escape for output encoding, its own user/session tables (rex_user, rex_user_session, passkeys) and a category/language-scoped permission model.
• 354 stars and 0 Packagist dependents is the decisive signal: nobody consumes this as a library. Any plan that assumes "drop it in and use its content classes" is mis-scoped.
• Realistic fit is one of three: (a) adopt REDAXO as the full application, (b) run it as a separate, self-contained content service and integrate over HTTP/JSON, or (c) selectively reuse MIT-licensed patterns (e.g. rex_sql_table's idempotent ensure semantics as a migration reference).
• The costly seam is identity. Bridging Laravel auth into REDAXO means a custom addon sitting directly on the surface that keeps changing (session-ID and remember-key rotation on password change, passkey table, admin-right revocation semantics).

Technical risk.

• Security cadence is high and occasionally urgent. 5.21.4 was an emergency release: the structure/history plugin allowed an unauthenticated attacker to obtain a backend session for any account, including administrators. 5.21.5 fixed a package-API privilege escalation (revoked admins could still install/uninstall addons), CSRF on safe-mode toggling, plus stored XSS and permission-scope fixes across mediapool, metainfo, structure.
• Read positively, this is a responsive maintainer with coordinated disclosures and GHSAs. Read operationally, it means frequent patch cycles and at least one addon-level kill switch you may need to flip before you can patch.
• Engineering discipline is above average for a CMS of this vintage: Psalm including taint analysis, PHPStan, PHPUnit, Rector, php-cs-fixer, all wired into composer check, with regenerable baselines. PHP 8.3+ baseline, with forward-compat work already landed for PHP 8.5/8.6 deprecations.
• License ambiguity must be closed: Packagist reports NOASSERTION while LICENSE.md and the README badge say MIT. Get this recorded in writing before any legal sign-off.
• Release dates in the supplied material (2026) should be reconciled against the actual release feed as a data-hygiene check before they enter a roadmap.

Key questions for the requester.

1. Is the requirement "we need a CMS" or "we need content inside our Laravel monolith"? Only the first is a fit.
2. Who is the named internal owner who can read PHP and REDAXO addon idioms, and do they read German?
3. What is the patch SLA — can we deploy a core + addon security update within 72 hours of a GHSA?
4. Do we need SSO against our existing identity provider, or are standalone REDAXO accounts acceptable?
5. Does content portability matter at exit, or is lock-in to MySQL structure tables acceptable?
6. Is there any vendor support requirement, or is community/Slack support acceptable?

Integration Approach

Stack fit. PHP 8.3+, MySQL or MariaDB (note rex_sql_table now normalizes column types and defaults across both so ensure stops churning schema), Apache/nginx with the directory-protection mechanic in play. It suits an editorial/content-heavy requirement on commodity LAMP infrastructure. It does not suit a team that wants a Laravel-native content module.

Decision gate before any code. Run a two-week spike: one throwaway instance from the release tarball, install demo_base (the only demo fully translated to English and explicitly designed to explain the major concepts), and prototype one vertical slice — a template, a module with custom input/output, and a media-manager variant. Kill or continue on the evidence from that spike, not on the README.

Migration path.

• Do not composer require this as a library. Deploy the release artifact and treat the instance as an application.
• Model content in REDAXO's own idioms (modules, templates, fragments, categories) rather than importing an MVC mental model. The module system is genuinely the product's strength: full control of any input and output.
• If Laravel must front the site, expose a narrow read API from a small custom addon — or emit static JSON at publish time — and keep the databases separate. Do not dual-write into REDAXO tables. The 5.21.5 note about the structure history table getting its status column appended out of position after the fact is exactly why schema is addon-owned and versioned by addon install/update routines.
• Inventory at addon granularity, not core granularity: core 5.21.5, backup 2.10.4, structure 2.20.5, mediapool 2.18.5, media_manager 2.18.4, cronjob 2.12.2, install 2.14.3. Your bill of materials and patch tracking must operate at that level.

Compatibility and sequencing.

1. Spike instance + demo_base; document the addon/permission model.
2. Threat-model auth: standalone accounts vs. custom SSO addon, plus the category/language permission matrix.
3. Build one production-shaped slice; measure developer velocity against a Laravel baseline.
4. Stand up staging, a patch runbook (core + addons as one coordinated change), and a rollback path.
5. Only then commit to a build; resolve the license question in parallel from day one.

Operational Impact

Maintenance and support. There is no vendor and no SLA. Support is the community Slack and FriendsOfREDAXO, German-first, with English, Spanish, Italian, Swedish and Portuguese localization in progress. Budget a named internal owner plus a documented "how we patch this" runbook; the changelogs are German, so either translate them in-process or accept that the on-call engineer needs to read them.

Patch cadence. Assume multiple security releases per year, sometimes clustered. The October 2026 set alone carried three core GHSAs plus fixes in five bundled addons. Your SLA should be explicit ("security patch deployed within X business days"), and the runbook must include disabling an addon as an interim mitigation — the project itself recommended disabling structure/history when immediate upgrade isn't possible.

Scaling. Conventional PHP CMS scaling: opcache, full-page or static export, read replicas, offloaded media. Two specifics matter: the nightly directory-protection check has been reduced to one directory per day and is now disable-able via use_directory_protection_check, because the request volume was tripping fail2ban and locking backend users out — expect to touch this in hardened environments. Cache invalidation across concurrent requests has produced sporadic "No clang found" errors, so cache coherency under load deserves a test.

Failure modes to design around.

• Unauthenticated backend session acquisition via an addon (structure/history, 5.21.4) — the highest-severity class here; enforce network-level restrictions on the admin area.
• Privilege retention: users whose admin rights were revoked mid-session could still install/delete addons (5.21.5). Design permission changes to force session invalidation.
• Stored XSS via SVG upload (sanitized only after the file reached the public media directory) and via media/media-list/link widgets. Put upload sanitization and a strict CSP in front of the CMS rather than relying on it alone.
• Missing CSRF checks on metainfo fields and be_style customizer settings — audit any custom addon forms to the same standard.
• Data exposure via the backup addon: users with backup[export] but no admin rights could previously export all tables, including password hashes and remember-me keys. Re-verify export scoping post-5.21.4.

Ramp-up. Editors: low — the module model makes content entry genuinely simple, which is the product's core promise. Developers: moderate — fragments, templates, modules, plugins, package.yml metadata and the rex_* API are learnable in a few weeks for a competent PHP developer. TPM/architecture: higher, because making it behave like a component in a larger platform requires custom addon work and ongoing cross-release maintenance.

Exit cost. Content lives in MySQL with REDAXO-specific structure tables plus files on disk. Extraction is scriptable but not trivial. Decide up front whether content portability is a hard requirement, because retrofitting a clean export later is materially more expensive.

Overall TPM read. A 50.99 composite with opportunity at 28.61 and zero dependents matches the reality: this is a mature, competently maintained, self-hosted CMS with a loyal regional community, not a platform component for a Laravel-centric organization. It is the right call when the requirement is "capable, cheap, self-hosted PHP CMS with fine-grained editorial control" and the org accepts self-support and a fast patch discipline. It is the wrong call when the requirement is "embed content management into our existing Laravel application." Make that distinction the gate on the decision.