Evolution Laravel Package

Technical Evaluation

Architecture fit. The first thing to correct in the framing: evolution-cms/evolution is not a Laravel package — it is a complete, standalone CMS and application framework that happens to be assembled from Laravel 13 components (per the repo's own agent guide). It ships its own bootstrap, router, manager backend, document tree, template engine (chunks/snippets/TVs), plugin event model, and file/image managers. You do not composer require this into an existing Laravel application; you deploy it as the application. That makes it a fit only for greenfield sites where Evo is the docroot and content model, or for content-first sites with a thin integration surface. It is a poor fit for teams expecting to extend an existing Laravel codebase with CMS capabilities — the two bootstraps cannot coexist in one process, and attempting to merge them means owning a fork.

Integration feasibility. Realistic integration paths, in descending order of practicality:

1. Reverse-proxy/segment split — Laravel app owns /app and APIs, Evo owns /content and the manager; shared session or OIDC bridge for auth. Lowest coupling, but two deployments, two auth systems, two upgrade cadences.
2. Headless read path — expose content by querying Evo's tables from the Laravel side (read replica) or by writing a snippet/plugin that emits JSON on a dedicated route. Feasible, but there is no first-class REST/GraphQL API in evidence; you would be building and supporting that contract yourself, against an internal schema that changes with core releases.
3. Full migration onto Evo — treat Evo as the platform and move off Laravel. Only sane if the Laravel surface is small.
4. Embed Evo inside Laravel — not recommended; no evidence anyone does this, and 0 Packagist dependents means no reference implementations to lean on.

Technical risk.

• Licensing is the largest single risk. GPL-3.0-or-later is copyleft. Any proprietary product that links to or derives from this code carries a distribution obligation to release source. This must be cleared by legal before any engineering spend — for internal-only deployments it is usually fine; for a commercial SaaS with distributed components it may be disqualifying.
• Bus factor. Contribution is concentrated in a handful of recurring names across release notes; 257 stars and 0 dependents is a weak adoption signal. This is a community-maintained MODX Evolution fork, not a vendor-backed platform.
• Active legacy debt. 3.5.5 finalized the MODX_* → EVO_* constant transition and added a deprecated:list command to find code slated for removal by semver; $modx is now marked deprecated. That is healthy engineering, but it means a breaking removal is scheduled, and the plugin/snippet API surface most third-party code touches is exactly what is being renamed.
• Composer root is owned by the updater. Legacy guidance (1.4.13, never rescinded in the notes) says put your composer.json in assets/, not root, because root changes are lost on update. Root is managed via a merge plugin. Any dependency the team adds outside that convention survives only until the next manager-driven update.
• Updater is the fragile seam. 3.5.7 is a large stabilization release specifically for the update flow — Composer binary resolution, preserving custom packages, DB backup before update, CLI/manager/installer consistency. That density of fixes tells you the path was recently unreliable. Upgrade notes still say: full DB and filesystem backup before every production upgrade.
• Published credentials in the nightly SQLite build (admin / Passw0rd123) are explicitly "not for production" — worth stating in any internal doc so nobody unpacks it into a shared environment.

Key questions for the team.

1. Does GPL-3.0 survive legal review for the intended distribution model?
2. Is the requirement "a CMS" or "CMS features inside our existing Laravel app"? Only the former is a fit.
3. Who owns upgrades? The manager self-updater is capable but needs a human who reads changelogs and takes backups.
4. What is the content volume and query shape? If the answer is heavy read traffic with a separate front-end, the headless path needs a contract we must own.
5. Which PHP version is the floor — README says ≥8.3, the agent guide says ≥8.4.1. Confirm against the target host's runtime.
6. Do we need editors (TinyMCE4 legacy API, MCPUK/KCFinder file browsers) as-shipped, or will we replace them? Replacement is re-integration work.

Integration Approach

Stack fit. Evo assumes Apache/nginx + PHP-FPM + MySQL/MariaDB or PostgreSQL, with SQLite supported and now well-tested enough to ship nightly builds on it. PHP 8.3 minimum, 8.4 recommended, 8.5 supported, 8.6 RC tested — a modern runtime floor, which is a genuine positive. Front it with a CDN or reverse cache and it behaves like any other PHP CMS. Do not expect it to slot into a container-per-service architecture without work: it writes to the filesystem (manager, cache, assets) and assumes a writable docroot.

Migration path.

• From legacy MODX Evolution / Evo 1.4.x: the intended path is 1.4.x → 3.1.x → 3.5.x, using the manager update flow with a database backup taken first. Constants were renamed but compatibility shims existed until 3.5.5; any custom snippets referencing MODX_* or $modx should be audited with deprecated:list and rewritten before the next major.
• From another CMS: content migration means mapping documents to the resource tree, fields to TVs, and templates to chunks. There is no standard importer; budget for a one-off script and for editor retraining.
• From a Laravel app: not a migration, a decision. Either extract content to Evo behind a proxy, or keep Laravel and skip this dependency.

Compatibility.

• Pin the exact patch (3.5.7 at time of writing) in a lockfile and treat upgrades as planned change windows, not background noise.
• Never edit root composer.json; use the assets/ convention or a documented override that survives the updater. Verify after each upgrade that custom packages and vendor symlinks are intact — 3.5.7's fixes exist precisely because they previously were not.
• If Evo shares a host with Laravel, keep them in separate runtimes. Conflicting illuminate/* major versions in one Composer root is a guaranteed resolution fight.
• The MODX_* → EVO_* removal will land at some future major; treat the deprecated list as a standing backlog item, not a one-time cleanup.

Sequencing. Recommend a four-gate plan:

1. Gate 1 — legal + product fit (1 week). License clearance and a written answer to "CMS vs. CMS features." If either fails, stop; no engineering spend.
2. Gate 2 — isolated proof of concept (2–3 weeks). Deploy 3.5.7 in a container with a production-shaped content model: nested resources, 10–15 TVs, 3–4 templates built from chunks and snippets, two editor roles with differing resource-group ACLs. Success criterion is an editor completing a realistic publishing task unassisted.
3. Gate 3 — integration spike (2–3 weeks). Build the actual boundary: proxy + SSO, or the headless JSON endpoint plus a consumer in the existing app. This is where you learn whether the chosen path is cheap or expensive.
4. Gate 4 — upgrade rehearsal (1 week). Run the manager update flow against a copy, including your custom packages and a restore-from-backup drill. If this is painful at PoC scale, it will be painful forever — that is the go/no-go signal.

Operational Impact

Maintenance. Cadence is frequent and patch-heavy: 3.5.4 through 3.5.7 in short succession, with a mix of security-adjacent fixes, PHP 8.4 deprecation cleanups, manager UX polish, and updater hardening. Budget roughly one planned upgrade cycle per quarter plus emergency patches. Each cycle: full DB backup, filesystem snapshot, changelog review against your custom snippets, staging rehearsal, post-upgrade check that custom Composer packages survived. That is a real recurring cost — call it 1–2 engineer-days per cycle at small scale, more if you carry custom modules.

Support. Community-only by evidence: forums (forum.evo.im), a Telegram group, and docs at docs.evo.im. No commercial SLA, no vendor escalation path, no evidence of paid support tiers. That is acceptable for internal or low-revenue sites; it is a material gap for anything customer-facing with uptime commitments. Internally, that means you need at least one engineer who can read the core well enough to patch a snippet or a plugin without upstream help.

Scaling. Standard PHP-FPM horizontal scaling applies: stateless web nodes behind a load balancer, shared MySQL/Postgres, shared or object-backed storage for uploads and cache. Session affinity or a shared session store is required for the manager. The "world's fastest" claim in the README should be treated as marketing; the engineering reality is OPcache plus JIT status visibility (added in 3.5.7) and per-element caching for chunks/snippets/plugins, which you can disable selectively when debugging — useful, but not a substitute for a page cache. For read-heavy public traffic, put a full-page cache or CDN in front; content freshness is then bounded by your cache invalidation policy, which you own.

Failure modes to plan for.

• Updater failure — Composer binary not found, custom package dropped, or update half-applied. Mitigation: never update without a tested restore, and keep a known-good container image from before the update.
• Post-restore data integrity — SQLite serialized settings and SQL string delimiters have both had restore bugs fixed recently. If SQLite is in play, rehearse restores explicitly.
• Legacy API breakage — plugin/snippet code using MODX_*, $modx, or TinyMCE4 legacy calls will break at some future major. Mitigation: run deprecated:list on every upgrade and keep the list empty.
• Auth regressions — login behavior around NO_SESSION has flip-flopped across patches (fixed, reverted, re-fixed in 3.5.4). Session-adjacent configuration changes deserve their own test case.
• Stale resource locks and ACL gaps in the file/image managers have been recurring; validate editor permissions after each upgrade rather than assuming they held.
• Accidental production use of the nightly build — the SQLite nightly ships with published admin credentials. Explicitly blacklist it in any environment provisioning.

Ramp-up. Expect 1–2 weeks before a competent PHP developer is productive and 4–6 weeks before they are genuinely fluent in the resource tree, TV binding syntax, chunk/snippet composition, and plugin event model. The mental model is idiosyncratic and pre-dates modern PHP framework conventions — a Laravel developer will find artisan commands present and be misled into expecting Laravel conventions everywhere else. Editor-side training is lighter, half a day, but the manager's legacy editors and file browsers will feel dated next to modern SaaS CMS tooling and may generate complaints.

Bottom line. Technically credible, actively maintained, modern runtime floor, and honest about its own legacy debt. But it is a whole platform, not a package, it carries copyleft obligations, and its adoption signal (257 stars, 0 dependents) means you are largely on your own. Recommend it only where the site is the product, the license is cleared, and one engineer can own the upgrade treadmill. Do not recommend it as a CMS layer bolted onto an existing Laravel application.