Ezautosave Ls Laravel Package

Getting Started

This is not a Laravel package. ezsystems/ezautosave-ls is a legacy-stack extension for eZ Publish 4.x/5.x (the pre-Symfony, eZPersistentObject/site.ini world). There is no service provider, no Illuminate dependency, no PSR-4 autoloading, no config publish, no facade — composer require will at best drop files into vendor/ that nothing in your Laravel app can call. Score 0.31 and 0 dependents reflect that: it solves a problem inside a CMS you are not running.

If you are genuinely operating an eZ Publish legacy site next to Laravel, the minimal install is:

1. Copy the extension to extension/ezautosave in the eZ root (not your Laravel root).
2. Activate it in settings/override/site.ini.append.php under [ExtensionSettings] / ActiveExtensions[]=ezautosave.
3. Regenerate the legacy autoload array (bin/php/ezpgenerateautoloads.php) and clear caches (bin/php/ezcache.php --clear-all).
4. Log into the legacy admin, edit a piece of content, and wait out the interval configured in extension/ezautosave/settings/autosave.ini.append.php.

Look first at: extension/ezautosave/settings/ (interval, enabled classes, storage target) and the extension's design/standard/templates/ + javascript/ — that pair is the actual contract: a JS timer POSTing a draft payload to a legacy module view.

First real use case for a Laravel developer: read the JS and the ini as a behavioral spec for autosave (interval, dirty-check, draft storage, restore-on-reload), then implement it natively in Laravel in an afternoon. That is the only honest way this package delivers value to you — as a reference implementation, not as a dependency.

Implementation Patterns

Pattern A — Behavioral port (recommended). Treat the legacy extension as documentation and rebuild the workflow in your own stack:

// routes/web.php
Route::post('/posts/{post}/autosave', AutosaveController::class)
    ->middleware(['auth', 'throttle:30,1'])
    ->name('posts.autosave');

class AutosaveController extends Controller
{
    public function __invoke(Request $request, Post $post, SaveDraft $saveDraft)
    {
        $this->authorize('update', $post);

        $data = $request->validate([
            'title'   => ['nullable', 'string', 'max:255'],
            'body'    => ['nullable', 'string'],
            'version' => ['required', 'integer'],
        ]);

        return response()->json(
            $saveDraft->handle($post, $request->user(), $data)
        );
    }
}

Key porting decisions lifted straight from what the extension does:

• Interval + debounce in the browser, not the server. The legacy JS throttles saves; mirror that with a setInterval/debounce client-side and keep the route throttled server-side as a backstop.
• Drafts live beside content, not in it. Legacy writes a draft/session record; in Laravel use a separate post_drafts table keyed by (post_id, user_id) with upsert(), leaving the real posts row untouched until publish.
• Optimistic concurrency. The extension assumes a single editor; don't inherit that assumption. Carry a version or updated_at token and return 409 when it is stale.
• Restore-on-load. Expose GET /posts/{post}/draft so the editor can rehydrate after a crash — this is the feature users actually notice.
• Cleanup. Drafts are ephemeral: a scheduled command pruning rows older than N days replaces whatever the legacy extension never did.

Pattern B — Hybrid proxy (only if you truly run both). Keep eZ legacy on its own vhost and have Laravel call into it, never the reverse. Share nothing but the session cookie domain; authenticate against your Laravel guard and issue a short-lived signed token the legacy side accepts. Do not attempt to load eZ classes inside a Laravel request — the legacy autoloader and Composer's classmap will collide.

Pattern C — Queue the persistence. If autosave payloads are large (rich text, embedded media), push the write to a job and return 202 immediately. The legacy extension writes synchronously on the request thread, which is exactly the thing that makes autosave feel sluggish on big documents.

Gotchas and Tips

• Archived, unmaintained, 2019. No security patches, no PHP 8 support, and the license is NOASSERTION — treat it as legally unclear and do not vendor it into anything production-facing without a human reading the license file.
• Not eZ Platform. This is the legacy stack. It will not run on eZ Platform / Ibexa (Symfony-based) despite the shared vendor namespace.
• Autoloader conflicts. Adding this to a Composer-managed project with optimize-autoloader or classmap-authoritative can cause the legacy array-based autoloader to miss classes; never let Composer own the extension/ tree.
• No Laravel integration surface. No events, no contracts, no config. Do not expect config/autosave.php, a facade, or a publishable migration — those do not exist and searching for them is the most common time sink here.
• CSRF and auth mismatch. The legacy POST has no _token; if you proxy it through a Laravel route you must explicitly exclude it from VerifyCsrfToken and re-implement origin checking yourself.
• Debugging. Errors go to the legacy var/log/ezpublish.log, not storage/logs/laravel.log. Cache issues are almost always stale legacy caches — clear them with bin/php/ezcache.php --clear-all before assuming a code bug.
• Extension points are ini-based. The only real customization is autosave.ini.append.php overrides (interval, content classes) and template overrides placed in your own design extension — there is no event dispatcher to hook.
• Verdict for a Laravel team: budget it as zero lines of dependency and half a day of reading-and-reimplementing. Add post_drafts + an upsert endpoint + a debounced fetch, and you will have a better, testable, maintained version of what this package does.