Evolution Laravel Package

Product Decisions This Supports

• Build vs. buy for content-managed surfaces. Evolution CMS is a full CMS application (a MODX Evolution fork rebuilt on Laravel 13 components), not a drop-in Composer library for an existing Laravel app. Choosing it is a platform decision, not a dependency decision — it replaces your admin/content layer rather than slotting into it.
• Roadmap scoping for resource-tree content models. Its differentiator is the document/resource tree plus template variables, chunks, snippets, and plugins. If your information architecture is hierarchical (sections → pages → localized variants) and editors think in trees, this maps to requirements with little custom modeling. If your content is flat, block-based, or API-first, the model fights you.
• Access-control requirement validation. Evolution ships registered web users and groups that are separate from manager (admin) users, with per-page grants and resource-group ACLs extended to file/image managers in 3.5.5. That is a real feature for extranets, member portals, gated documentation, and multi-tenant-ish content — often the single line item that justifies a CMS over a hand-rolled Laravel admin.
• Legacy estate triage. If you own MODX Evolution 0.7–1.0.8 or early Evo sites, this is the maintained continuation with PHP 8.3+ (recommended 8.4) support. The decision is "upgrade in place vs. replatform," and the package gives you the cheap path — with a defined cost, since 3.5.x is actively retiring $modx and MODX_* compatibility aliases.
• Go/no-go on distribution model — decide this first. GPL-3.0-or-later is copyleft. Self-hosted internal sites and SaaS (no distribution) are generally workable; shipping it inside a closed-source product, appliance, or client-delivered codebase is a legal review, not an engineering one. No amount of feature fit overrides this.
• Support and staffing planning. 257 stars, zero Packagist dependents, and an opportunity score of ~2/100 mean you are buying into a small, community-run ecosystem with Telegram/forum support and no commercial vendor. Budget for a named internal owner and the assumption that you cannot hire for it.
• Operational readiness. Release 3.5.7 added a manager-driven update flow with pre-update database backups and Composer handling; 3.5.5 added a deprecated:list command for semantic-version-driven removal tracking. That is credible maintenance hygiene for a project this size, and it materially lowers upgrade risk — but it also confirms ongoing breaking-change churn.
• Migration/exit-cost estimation. The single-click installer, SQLite nightly build, and update flow make POCs and staging cheap. Use a 2–3 day spike to price both adoption and escape, not just the happy path.

When to Consider This Package

Consider it when:

• You are maintaining or replacing an existing Evolution/MODX Evolution site and want supported PHP 8.3/8.4/8.5 runtime without a replatform.
• The product is a hierarchical, editor-maintained content site or extranet where per-resource and per-file access control is a first-class requirement.
• The deployment is self-hosted or internal, or SaaS without redistribution, and GPL-3.0 obligations are acceptable to legal.
• You value a small, auditable, low-magic codebase and template-level extensibility (snippets/chunks/plugins) over a rich app framework.
• You have — or will fund — a dedicated PHP owner who enjoys reading source, because documentation and community depth are thin.
• Cost sensitivity dominates: no license fees, no vendor contract, minimal infrastructure.

Look elsewhere when:

• You need a Laravel-native admin for an existing Laravel product. Use Filament, Nova, or Statamic; don't run a parallel application framework beside your app.
• You need headless/API-first delivery, a GraphQL/REST content API as the primary contract, or omnichannel publishing. This is a rendered-page CMS with a manager UI; API-first is an extras-and-glue exercise.
• You are shipping a closed-source or client-delivered product where GPL-3.0 is unacceptable.
• You require an SLA, vendor indemnity, security advisories with CVE SLAs, or a large hiring pool. Nothing here provides that.
• You need enterprise content operations: workflow/approval chains, editorial scheduling at scale, DAM, personalization, or a mature multisite story.
• Your stack of record is WordPress, Drupal, or a JS framework with a headless CMS — the ecosystem gravity is worth more than this package's feature fit.
• You are exposed to the manager's broad attack surface (file manager, KCFinder/TinyMCE, ZIP downloads) and cannot commit to prompt patching, WAF, and update discipline. And never treat the published-credential SQLite nightly build as anything but a sandbox.

How to Pitch It (Stakeholders)

To executives (one paragraph): Evolution CMS is an open-source, GPL-licensed PHP content management system — a maintained fork of MODX Evolution rebuilt on Laravel components. It is the low-cost option for content sites with hierarchical structure and per-page access control, and it is the cheapest credible path off a legacy MODX install to a supported PHP 8.4 runtime. The trade-off is ecosystem size and license shape, not features: the community is small (roughly 257 GitHub stars, no downstream dependents), there is no commercial vendor or SLA, and GPL-3.0 constrains how we can redistribute it. Recommendation: approve only as a scoped, self-hosted/internal deployment or a legacy-migration bridge, with a named internal owner and a documented exit path; reject for any closed-source distributed product or as the admin layer of an existing Laravel application.

To engineering (the ask): Treat this as adopting an application framework, not a package. Validate in a time-boxed spike: (1) confirm PHP 8.4+ and the update/backup flow works on our target infrastructure, including SQLite and MySQL/PostgreSQL paths; (2) inventory every $modx and MODX_* usage and run the deprecated:list command so the 3.5.x compatibility removals are a known cost, not a surprise; (3) prototype the resource-group ACL model against our real permission requirements; (4) assess the manager's attack surface — file/image managers, editors, ZIP downloads — and propose hardening (WAF, admin IP allowlisting, patch cadence, no published-credential builds anywhere near staging); (5) estimate integration cost honestly, since the Laravel components underneath do not make this a Laravel package. Report back with a build-vs-migrate-vs-replatform comparison and a three-year TCO including the owner headcount.

The framing to avoid: don't sell this as "the world's fastest, most customizable CMS." Sell it as a deliberate, bounded choice with a named owner and a known escape hatch — that is the pitch that survives a risk review.