Before you start
Bring the facts, not more tabs.
- A cloud project open in the Naratake editor.
- A save-conflict prompt reporting that another session changed the project.
- Enough time to review both your browser work and the latest server version before publishing.
You will learn to
- Understand why Naratake pauses autosave instead of overwriting the server.
- Download an exact emergency copy before choosing a destructive recovery path.
- Choose between the authoritative server version and a new safe duplicate.
- Confirm the recovered project is saved before leaving, exporting, or publishing.
Stop editing when Save conflict appears
A conflict means the server has a newer project revision than the one your browser started from. Naratake pauses autosave so neither version is silently destroyed.
- Leave the Save conflict prompt open while you read its server version and request details.
- Do not keep making changes in the conflicted project. Autosave is paused and the additional work would exist only in this browser session.
- Do not close the tab, refresh the browser, or assume another Save attempt will merge the two versions.
- If you dismissed the prompt, press Command-S on macOS or Ctrl-S on Windows to reopen the recovery choices.
Done when: The prompt is available, the tab remains open, and you understand that your browser copy and the server copy are now different.
Download the exact recovery file first
Download recovery .lsproj preserves the browser snapshot held at conflict time. It is a non-destructive safety step and does not choose which version becomes authoritative.
- Choose Download recovery .lsproj, then choose Continue.
- Wait for the file download and confirm that its name ends in .lsproj and the file is not empty.
- Store the file somewhere you can identify later; it contains the held browser project, not the newer server version.
- Expect the recovery prompt to remain open. Downloading protects the bytes but intentionally leaves autosave paused.
Done when: You have a non-empty .lsproj recovery file and the editor still asks which authoritative editing path to use.
Reload when the server version should win
Choose the server version when another editor’s newer changes are authoritative and your browser-only changes can be reviewed later from the recovery file.
- Confirm with the collaborator or project owner that the latest server revision is the intended base.
- Verify that your downloaded recovery file exists before discarding the browser-only state.
- Choose Reload server version, then Continue.
- After the project reloads, inspect the changed pages and reapply only the browser edits that are still needed.
Done when: The editor reports that the latest server version was loaded and the canvas shows the collaborator’s authoritative changes.
Use a safe duplicate when both versions matter
A recovery duplicate preserves the current browser work as a new cloud project. The original server project and its newer revision remain unchanged.
- Choose Keep editing as a safe duplicate, then Continue.
- Wait until the editor opens the newly created project with “(Recovery copy)” in its name.
- Confirm that the save status reaches Saved before leaving the editor.
- Compare the recovery copy with the original project and decide which changes to merge through normal editing and review.
Done when: A separate cloud project exists with its own first revision, the browser work is saved there, and the original project was not modified.
Do not bypass the blocked delivery actions
Back, Export, and Go live are intentionally unavailable while the conflict is unresolved because each could leave or deliver an uncommitted version.
- If Back reports that the project is not safely stored, stay in the editor and reopen the conflict choices.
- If Export or Go live reopens Save conflict, resolve the conflict instead of trying the action again.
- Never treat the downloaded .lsproj alone as proof that the cloud project is safe to publish.
- After reloading or duplicating, review the recovered project before restarting Export or Go live.
Done when: The recovery state is resolved, the chosen project is Saved, and delivery actions no longer need to block on the old conflict.
Close the loop with the other editor
A technical recovery prevents data loss, but collaborators still need one agreed project and revision before the next review or launch.
- Tell the other editor which project now contains your recovered work and whether you reloaded or created a safe duplicate.
- Compare the affected pages, Theme, modules, and Site settings instead of merging by memory.
- Wait for Saved, then run Preview on the merged result before requesting Review or Go live.
- Keep the downloaded recovery file until the owner approves the final project; archive or remove it according to the workspace’s data policy afterward.
Done when: The team has one approved project, its saved revision contains the intended changes, and the next review starts from that shared state.
Final check
Do not call it done until these are true.
- The editor’s Save conflict prompt was resolved intentionally.
- An exact .lsproj recovery file was downloaded before discarding browser-only work.
- The latest server version was reloaded or a new safe duplicate was created and acknowledged.
- The chosen project reached Saved before leaving, exporting, or publishing.
- Collaborators reviewed the recovered result and agreed which project continues.