Evo Ui Laravel Package

Technical Evaluation

Architecture fit

evo-ui is not an application package — it is a platform layer for one specific host (Evolution CMS manager) and one specific rendering stack (Livewire 4 + DaisyUI inside an iframe). For a Laravel/PHP team already shipping Evolution CMS modules, the value proposition is real and narrow: it removes the legacy manager bundle (main.js, jQuery, Bootstrap, TabPane, CDN assets, Roboto) from module screens and gives a shared, config-driven UI contract for tables, forms, modals and tabs. That is a genuine deduplication play. sArticles, dIssues, sSeo, sLang and sSettings reportedly share it, which means the abstraction has already survived contact with several real screens rather than being speculative.

The architectural seam worth endorsing is the consumer-facing runtime boundary introduced in 1.1.0: EvoUI::registerComponent() and EvoUI\Components\Component let consumer modules avoid importing Livewire\Component directly. That is the difference between "we depend on this package" and "we depend on this package and its transitive Livewire version" — it materially reduces blast radius for framework upgrades. The iframe shell is also a defensible choice: it isolates the modern stack from the legacy manager document, avoids CSS/JS collisions with the host, and gives a clean document per module. The cost is the usual iframe tax (session, CSRF, routing, deep-linking, scroll, a11y), which the release notes show they are paying for incrementally (1.0.5 wheel-scroll fix, 1.0.6 manager-prefixed route support and tab refresh without reloading the frame).

Integration feasibility

Moderate, with clear preconditions. Requirements are PHP ^8.3 at 1.0.x rising to PHP 8.4+ at 1.1.0, Evolution CMS ^3.5.7, and Livewire ^4.0. The PHP floor moving up in a minor release is the single most consequential integration fact here. Any environment pinned to 8.3 (shared hosting, older containers, distro PHP) cannot take 1.1.x. That turns a routine composer update into a platform migration and needs to be planned as infrastructure work, not package work.

Asset handling is the second feasibility item. The package publishes to assets/modules/evo-ui preferring symlinks and falling back to copies, and 1.0.4 shows what happens when this goes wrong: HTML/404 served in place of CSS/JS, surfacing as Unexpected token '<' and EvoUI.multiFilter is not a function. The provider now self-heals assets at boot. That is a pragmatic fix, but "provider writes into the public webroot at boot" is a deployment-time behaviour that must be validated on every hosting target, including ones where the docroot is read-only or symlinks are disallowed.

Technical risk

• Single-host lock-in. Everything here is Evolution CMS manager-specific: four named themes (evolight, evolightness, evodark, evodarkness), manager route prefixes, manager sessions. Portability is effectively zero. That is acceptable only if the Evolution investment is strategic.
• Thin ecosystem signal. 2 stars, 0 external dependents, a dependency set that is essentially the same organisation's own modules. There is no external canary population — every breaking change is discovered by the maintainers' own consumers.
• Contract churn under a stable-looking version number. 1.0.3 "tightened table/list DnD contracts", stabilised form save feedback and modal handling. Contract tightening in patch releases on a config-driven DSL means consumer presets can break in ways that unit tests inside the package will not catch.
• Framework shims. The package ships a Livewire/Foundation Response shim and "tightened auth/gate compatibility", plus "minimal Laravel-style services" — i.e. it emulates framework surfaces that Evolution CMS does not fully provide. Every shim is a place where behaviour can silently diverge from whatever the CMS itself does (notably permission checks).
• Release metadata hygiene. The listed last release date (2026-10-12) is in the future, and version requirements changed materially in a minor bump. Small things, but they are the kind of signals that justify treating the package as internal infrastructure rather than a vendor product.

Key questions

1. Who owns evo-ui, and is there anything resembling a support commitment? No vendor, no stated SLA, MIT on a public repo.
2. Is the PHP 8.4 floor a deliberate platform decision with a sunset plan for 8.3 hosts, or an incidental consequence of Livewire 4?
3. Which modules are in scope, in what order, and is the whole manager UI target state EvoUI — or is there an accepted hybrid (sLang's resource edit tab bridge suggests there is)?
4. Does EvoUI's auth/gate shim produce the same effective permissions as the CMS's native manager ACLs? Has anyone tested permission parity, not just "it renders"?
5. What is the fallback if evo-ui stalls? Each consumer module currently inherits the same single point of failure.
6. Is Livewire 4 mature enough to be a load-bearing dependency for admin tooling, and what does an upstream Livewire 4.x minor cost us?

Integration Approach

Stack fit

Good fit only inside the stated envelope: Evolution CMS 3.5.7+, PHP 8.4, Livewire 4, and modules that are permitted to own their entire manager document in an iframe. Poor fit for anything that must embed into an existing legacy manager screen (TabPane, TinyMCE/CodeMirror resource tabs), which the project itself treats as an explicit compatibility boundary rather than a supported case. Practically: EvoUI is the right choice for greenfield module screens and full-page module rewrites; it is the wrong choice for incremental in-place UI tweaks.

Migration path

Rewriting a module is a screen-by-screen migration, not a dependency swap. The documented path is: depend on the package → wrap the page in x-evo::layout → drop in x-evo::module-tabs → replace hand-built tables with livewire:evo-ui.module-table driven by a named preset + context array → replace settings screens with config-driven forms → publish assets and delete the module's own legacy CSS/JS. That last step is where the benefit lands and also where the risk concentrates: removing legacy bundles while any screen still relies on them produces broken pages with no shared fallback.

Compatibility

• Hosting: confirm PHP 8.4 everywhere before taking 1.1.x; confirm symlink capability or accept copy-mode asset drift.
• Manager routing: validate both /evo-ui and manager-prefixed (/manager/evo-ui, renamed manager directories) endpoints in your actual deployment, since 1.0.6 was specifically about this.
• Permissions: run a permission-parity test per module against the native manager ACLs.
• No mixing: treat "an EvoUI screen must not load legacy manager bundles" as a hard review gate (the release checklist already says this — make it a CI check, not a convention).
• Consumers: pin evolution-cms/evo-ui to a caret range and a tested minor; watch 1.0.x contract-tightening releases for preset breakage.

Sequencing

1. Infrastructure readiness: PHP 8.4, vendor:publish --tag=evo-ui --force, verify asset MIME types and symlink/copy behaviour on staging and production-like hosting.
2. Read-only pilot: one low-risk, low-traffic screen (a dashboard or list view) to prove shell, theme sync, session persistence and CSRF inside the iframe.
3. One table-heavy screen with provider-backed data, including DnD reorder and modal edit, to shake out the table contract.
4. One form/settings screen with dirty-state Save/Discard behaviour.
5. Only then batch-migrate remaining modules, publishing assets together with docs and translations per the release checklist.
6. Retire legacy assets per module as each screen lands, never globally.

Operational Impact

Maintenance

The package is on a fast, fix-heavy cadence — 1.0.0 through 1.1.0 within a short window, with multiple releases whose entire content is "assets weren't served" / "routes broke" / "scroll broke". That is healthy responsiveness for a young foundation, but it means upgrade work is a recurring line item, not a one-off. Budget an owner on your side who tracks releases, re-runs vendor:publish, and revalidates each consumer module. The package cannot be installed and forgotten.

Support

Community-only, MIT, org-backed (evolution-cms) but with no commercial support and no external adopter base to lean on. Internal consumers absorb their own triage. This is acceptable for tooling where a broken screen is an inconvenience; it is not acceptable if manager modules are on a customer-facing SLA. Note the docs are unusually mature for the adoption level — six localised doc trees, a consumer audit, a release checklist and a primitive coverage matrix — which partly offsets the support gap by making behaviour discoverable.

Scaling

Throughput is not the concern: this is admin UI, low concurrency, few simultaneous editors. The scaling risk is in the data path — provider-backed tables issuing per-row or per-filter queries, and Livewire round-trips adding latency on every sort, filter, paginate and inline edit, compounded by iframe overhead. Watch query counts on the largest tables before declaring a screen done. Session/state persistence for filters and views is per-session cookie-backed, which is fine at admin scale but should be sanity-checked on shared accounts.

Failure modes

• Asset failure (highest probability): symlinks unavailable or publish skipped → CSS/JS 404s → Unexpected token '<', missing JS globals. Mitigation: publish step in the deploy pipeline, plus an assertion that the published assets return text/css / application/javascript.
• Stale copies: copy-mode fallback drifts silently after a package upgrade. Mitigation: always --force, and verify a version marker.
• Route collision: renamed or non-standard manager directories breaking the Livewire endpoint. Mitigation: smoke-test the manager-prefixed route on every environment.
• Silent contract drift: a patch release tightens a table/form contract and a consumer preset degrades without a hard error. Mitigation: contract smoke tests per consumer, not just inside the package.
• PHP floor mismatch: an environment stuck on 8.3 takes a dependency resolution that breaks at runtime rather than at install.
• Theme drift: a new or renamed Evolution manager theme falls outside the four synced themes and the shell looks wrong rather than failing loudly.
• Mixed legacy/modern screen: a partially migrated module loading both bundles — the exact class of bug the package exists to eliminate.

Ramp-up

Two distinct skill sets are required and they do not overlap much: Livewire 4 + Alpine + DaisyUI + Blade components (typically 1–2 weeks for an experienced Laravel/Livewire developer to be productive on presets and forms), and Evolution CMS manager internals — iframe lifecycle, manager sessions/routing, ACLs, theme sync — which is where most of the debugging time will actually go. Developers coming from the legacy jQuery/Bootstrap manager world will take considerably longer, because almost nothing transfers and the failure modes are unfamiliar. The localised documentation shortens onboarding meaningfully; the config-driven table/form DSL means most module work is declaration rather than component authoring, which lowers the per-screen cost for repeat work considerably once the first two screens are done. Plan for one experienced owner and treat the first migrated module as a learning module with deliberately generous scope.