Ezautosave Bundle Laravel Package

Getting Started

Minimal Setup

1. Installation

   composer require code-rhapsodie/ezautosave-bundle
   

   Register the bundle in config/bundles.php before EzSystems\EzPlatformAdminUiBundle:

   CodeRhapsodie\EzAutosaveBundle\CodeRhapsodieEzAutosaveBundle::class => ['all' => true],
   

2. First Use Case

   • Edit/create content in the Ibexa DXP admin UI.
   • The bundle automatically saves drafts to localStorage (client-side only).
   • Reopen the same content type or edit the same content → a prompt appears to restore autosaved data.

Implementation Patterns

Workflow Integration

1. Content Creation/Editing

   • No JS required: The bundle hooks into Ibexa’s admin UI via Symfony events.
   • Autosave Interval: Defaults to periodic saves (configurable via bundle settings).
   • Conflict Handling: If the user discards autosaved data, the bundle clears localStorage for that content.

2. Customization Points

   • Exclude Content Types: Override config/packages/ez_autosave.yaml to exclude specific content types:

     code_rhapsodie_ez_autosave:
         excluded_content_types: ['blog:post', 'custom:form']
     

   • Storage Backend: Extend CodeRhapsodie\EzAutosaveBundle\Storage\StorageInterface for server-side persistence (e.g., database).

3. Event Listeners

   • ez_autosave.save: Trigger custom logic when autosaving (e.g., log drafts).

     // services.yaml
     App\EventListener\AutosaveListener:
         tags:
             - { name: kernel.event_listener, event: ez_autosave.save, method: onAutosave }
     

   • ez_autosave.restore: Validate/restructure restored data before applying it.

4. Testing

   • Mock localStorage in PHPUnit:

     $this->getContainer()->get('ez_autosave.storage')->setData('key', $data);
     

Gotchas and Tips

Pitfalls

1. Browser-Specific Behavior

   • localStorage is not shared across tabs/browsers. Warn users to use the same browser for autosave consistency.
   • Private/Incognito Mode: Autosaves are lost when closing these modes.

2. Content Type Mismatches

   • Autosaved data is tied to content type + language. Editing a translation of a content type won’t restore drafts unless explicitly configured.

3. Performance

   • Heavy content (e.g., large WYSIWYG fields) may bloat localStorage. Monitor size with:

     console.log(localStorage.getItem('ez_autosave_<content_id>')?.length);
     

4. Debugging

   • Clear Autosaves: Override the storage service to purge data:

     $this->get('ez_autosave.storage')->clear();
     

   • Check Events: Enable Symfony’s event dispatcher debug:

     bin/console debug:event-dispatcher | grep ez_autosave
     

Pro Tips

1. Visual Feedback

   • Add a badge to the admin UI showing autosave status (e.g., "Draft saved 2m ago").
   • Use the ez_autosave.save event to trigger a toast notification via JavaScript:

     document.addEventListener('ezAutosaveSaved', (e) => {
         alert('Draft saved!');
     });
     

2. Server-Side Fallback

   • Extend the storage interface to sync localStorage to a database on form submission:

     // src/Storage/DatabaseStorage.php
     class DatabaseStorage implements StorageInterface {
         public function save($key, $data) {
             // Save to DB + localStorage
             parent::save($key, $data);
             $this->db->saveDraft($key, $data);
         }
     }
     

3. Multi-User Environments

   • Warning: Autosaves are user-specific. If multiple users edit the same content, conflicts may arise. Document this in your admin UI.

4. Configuration Quirks

   • Disable for Specific Users: Use a voter to skip autosave for non-editors:

     # config/packages/security.yaml
     access_control:
         - { path: ^/admin/content/edit, roles: ROLE_EDITOR }