TinyMCE autosave: recover a browser draft without confusing it with a server save

Suppose an author changes a fictional museum notice from “Meet at the east gate” to “Meet at the courtyard gate,” then accidentally leaves the editing page. The recovery question is whether that unfinished correction can be restored. The publishing question is whether visitors now see the courtyard instruction. Those need separate checks.

Expose the recovery action

In an existing, correctly licensed TinyMCE installation, merge these options into the editor's initialization:

tinymce.init({
  selector: '#museum-notice',
  plugins: 'autosave',
  toolbar: 'undo redo | restoredraft',
  autosave_interval: '20s',
  autosave_retention: '60m',
  autosave_restore_when_empty: false,
  autosave_prefix: 'museum-notice-42-user-17-{id}-'
});

The selector requires an existing editor element. Preserve the other plugins, toolbar controls, deployment configuration, and license settings your application needs. Here 20s is the recovery interval and 60m is the period during which a stored draft remains eligible for recovery. A character typed just before a crash may not have reached that interval.

The example prefix identifies one fictional record and author. Generate the corresponding prefix from your actual editing context; do not reuse these fixed identifiers for every document. TinyMCE's default prefix includes the page path, query, and editor ID. If an application opens different records at the same route and reuses the same editor ID, inspect whether those defaults distinguish the records.

Decide what an empty editor means

autosave_restore_when_empty: true permits automatic restoration when the editor is empty at initialization. That can be useful on a genuinely blank recovery page. It needs more care when a page initializes empty and loads its server content afterward.

In that second flow, an old local draft and a late server response can compete for the document. Prefer deliberate restoration until the application has established which record is open, what its current server content is, and whether the author wants the local draft. Keep an unsaved document visible when the load fails instead of treating an empty field as permission to replace it.

Local storage belongs to the browser's origin and profile. A recovery draft is not a cross-device backup, and the prefix is a naming convention rather than an access-control boundary. Shared-device sessions need an explicit policy for retaining and clearing local drafts.

Check recovery with two different notices

Use a development copy of the real authoring page:

1. Open notice 42 and change “east gate” to “courtyard gate.” Wait beyond the configured interval.
2. Leave without invoking the application's Save action, return to the same editing context, and use Restore last draft if available.
3. Confirm the recovered words, then open a separate notice 43. Its editor must not receive notice 42's gate instruction.
4. Save through the real application and reopen the saved record. Verify the server copy independently of the recovery copy.

Also check expiration: after the retention window, TinyMCE documents older recovery content as ignored. Do not promise recovery indefinitely.

Make the status describe what succeeded

“Recovery draft stored in this browser” and “Notice saved” describe different results. The latter should follow a successful application save. The TinyMCE HTML extraction guide explains reading the current editor value and synchronizing a backing form field; neither operation alone confirms server persistence. TinyMCE Editor API

For the museum notice, finish by reading the saved courtyard instruction in the visitor-facing view. Keep the recovered wording available until the author has confirmed that the correct record was saved.