Ezautosave Ls Laravel Package

Technical Evaluation

Architecture fit — poor, and the framing is misleading. Despite the vendor/package shape, ezsystems/ezautosave-ls is not a Laravel package and not a general-purpose PHP library. The -ls suffix denotes an eZ Publish legacy stack extension: it ships no composer.json autoload block targeting application code, no service provider, no facade, no PSR-4 namespace. It is installed by the ezsystems/ezpublish-legacy-installer Composer plugin (package type ezpublish-legacy-extension), which unpacks files into the legacy extension/ directory for the legacy kernel to discover via settings/override. A Laravel application has no legacy kernel, no ezpublish module/view routing, and no legacy content datamodel, so there is nothing for the package to attach to. It is effectively a jQuery-era JavaScript widget plus a legacy PHP module that persists editing drafts.

Integration feasibility — near zero as a dependency; moderate as source material. The realistic path is not composer require but port-and-reimplement: lift the autosave client behavior (interval, debounce, dirty-check, flush-on-navigate) and the draft payload shape, then rebuild the server side as a Laravel route, FormRequest, policy, and a dedicated drafts table. Expect 1–2 days of archaeology to read the JS and legacy module, then 1–2 weeks to build a tested equivalent.

Technical risk — high, concentrated in licensing and lifecycle.

• License is NOASSERTION. eZ Publish legacy was GPL-2.0; if this extension inherits that, any distributed derivative work carries copyleft obligations. This must be resolved by a human reading LICENSE/file headers before a single line is copied — copying code without clarity is the single largest risk here.
• Archived and abandoned. Last release 2019-02-18, zero dependents, no upstream issue triage. No security backports, ever.
• Host platform is EOL. The legacy kernel it targets does not support PHP 8.x; the bridge architecture (legacy + new stack) was retired in favor of Ibexa. Running it implies PHP 5.6/7.x, which is a compliance finding on its own.
• The 0.31 composite score and 0 dependents are consistent with this assessment — the 14.96 "opportunity" signal appears to reflect category interest (editor autosave is a real requirement) rather than this artifact's viability.

Key questions for the team:

1. What does the actual license file say, and has legal signed off on any code reuse?
2. Do we have any eZ/Ibexa estate at all, or is the "Laravel/PHP" classification simply wrong for this entry?
3. What is the real requirement — autosave UX, draft durability, or crash recovery? Each implies a different (and much smaller) build than porting this.
4. Do we already have platform primitives that subsume this (Livewire/Alpine dirty state, Laravel session drafts, updated_at optimistic locking)?
5. Is the autosave payload compatible with our content model, or does it assume ezcontentobject_attribute semantics we don't have?

Bottom line: do not adopt as a dependency. Treat it as a behavioral reference only, gated on license clearance.

Integration Approach

Stack fit — none. Target stack is assumed to be Laravel 10/11 on PHP 8.2+, Composer 2, PSR-4 autoloading, queue workers, and a relational draft store. This package requires the legacy installer plugin, a legacy extension/ layout, and a legacy kernel bootstrap. Installing it into a Laravel skeleton produces either a plugin error or orphaned files with no execution path.

Migration path — reimplement, don't port.

• Harvest the spec, not the code. Extract: autosave interval and backoff, debounce threshold, dirty-field detection, behavior on navigate-away and on explicit save, draft restore UX, and any conflict messaging.
• Server side in Laravel: POST /drafts/{draftable} → route-model binding, FormRequest validation, policy check on the underlying resource, write to a drafts table (id, draftable_type, draftable_id, user_id, payload JSON, version, created_at, updated_at). Use updated_at/version for optimistic concurrency.
• Client side: debounced fetch/Axios with X-CSRF-TOKEN, keepalive: true for unload flushes, and a visibility-change flush. Do not resurrect the jQuery transport.
• Pruning: scheduled command to expire drafts past a retention window (e.g., 14–30 days), mirroring the intent of the original module's cleanup without its write pattern.

Compatibility. Incompatible with PHP 8.1+ (legacy stack code relies on removed constructs), incompatible with Laravel's routing/kernel, and incompatible with modern autoloading. If any eZ legacy instance genuinely exists in the estate, the extension could be pinned there — but that instance is itself the problem to be retired, not extended.

Sequencing.

1. Legal/license review — hard gate, no engineering before this clears.
2. Classification check — confirm whether any eZ/Ibexa system is in scope; if not, close the ticket as misfiled.
3. Behavioral spike (1–2 days) — read the JS + legacy module, write a one-page spec of autosave semantics.
4. Design (2–3 days) — draft model, conflict policy, retention, permissions, audit.
5. Build + test (1–2 weeks) — happy path, concurrent-tab conflict, session expiry, network failure, restore-vs-discard.
6. Rollout behind a flag with telemetry on autosave success/failure and draft-restore rate.

Operational Impact

Maintenance. Zero upstream. Archived repository, no releases since February 2019, no maintainer obligation. Any fork becomes wholly ours — including the security surface of copied JS and PHP.

Support. No vendor support path; eZ Systems/Ibexa have moved on from the legacy kernel. No CVE monitoring, no advisory feed, no patch SLA. If we own a fork, we own the response plan for any vulnerability found in the copied code or its assumptions (session handling, unserialization, file paths).

Scaling. The original writes to the legacy content store on each autosave tick, which is write-amplification by design: N concurrent editors × 1 write per interval, all landing in the same tables that serve reads. A naive port reproduces that. Mitigations to specify up front: debounce plus dirty-field diffing (skip no-op saves), a dedicated drafts table isolated from primary content tables, JSON column rather than one row per attribute, and a queue for any post-processing. Budget for storage growth and prune aggressively.

Failure modes to design against.

• Silent draft loss on session/token expiry — surface a "draft not saved" state rather than failing quietly.
• Stale restore overwriting newer content — require version comparison and an explicit conflict prompt.
• Race between autosave and submit — cancel in-flight autosaves on submit; make submit idempotent.
• Unbounded draft growth — retention job plus per-user cap.
• CSRF/token mismatch in the new stack — the legacy module's session semantics do not translate; implement explicitly.
• Multi-tab divergence — last-write-wins is acceptable only if the UI says so.

Ramp-up. Code volume is small, but domain cost is not trivial: interpreting the legacy content model (ezcontentobject_attribute and friends) requires someone with eZ Publish background. Realistic onboarding: half a day to read the JS, 1–2 days to produce a trustworthy behavior spec, then standard Laravel velocity. Total cost of the "reimplement from spec" route is bounded and predictable; total cost of the "make the dependency work" route is unbounded and should be declined.