GrapesJS Storage Manager: reopen the editable project from your server response

A fictional community-center page has separate welcome and accessibility pages. The exported welcome page can look correct even when reopening the editor loses the second page. Test the editable project and its published output separately.

Inspect the storage strategy before changing the canvas

The documented default storage is local browser storage. A project surviving reload in one browser does not prove that the server has it. Inspect storageManager.type, its options, and the actual network requests.

In an existing GrapesJS application, merge a deliberate remote configuration into initialization:

const projectID = 42;

const storageManager = {
  type: 'remote',
  autosave: false,
  autoload: false,
  options: {
    remote: {
      urlStore: `/api/page-projects/${projectID}`,
      urlLoad: `/api/page-projects/${projectID}`,
      onStore: data => ({ id: projectID, data }),
      onLoad: result => result.data
    }
  }
};

These routes describe an illustrative server contract; they are not an available service. The application must implement the store/load routes, authorize access to project 42, handle its authentication and CSRF policy, and return the documented successful response. Do not copy this fixed ID across all projects.

onStore shapes the outgoing body. onLoad extracts the project from the response. If your endpoint returns project JSON directly, the wrapper-specific extraction is wrong and should be removed or changed. Inspect the real response before adding another mapping layer.

Load before the author starts editing

This example disables automatic loading so the application controls when to make the editor available. After initialization and after its authenticated editing context is ready:

await editor.load();

Handle failure in the application and keep authoring unavailable until the intended project is loaded or a deliberate new-project decision is made. An empty canvas after a failed load must not silently overwrite an existing server project.

For the first integration check, explicit save is easier to follow:

await editor.store();

Show success after that operation resolves. The Storage Manager API documents storage events, including store errors, for application status handling. Preserve edited project data when a save fails.

Understand the autosave threshold

If you enable autosave later, stepsBeforeSave counts changes; it is not a delay in seconds. GrapesJS compares the dirty count with this threshold and clears that count after a successful store.

Keep the chosen project identity stable for each editor instance. Switching a mutable global ID while an older instance remains active risks sending its project to another record. Resolve pending work and initialize the next record with its own storage context.

Check the two-page project after a real reopen

On a development deployment, edit the fictional accessibility page to say “Use the ramp beside the north entrance.” Save, inspect the outgoing project JSON, and close that editor. Open the same server project in a fresh instance and check:

• Both welcome and accessibility pages are still available.
• The ramp instruction is on the accessibility page.
• Editable components and their styles remain available rather than appearing only as flattened output.
• A different project does not receive this center's content.

Export and inspect the reader's page afterward. Project JSON preserves editor information; exporting is a separate result. Media files also need their own durable location and reader permissions. The GrapesJS image-editing guide follows that separate asset boundary.

Keep the original project until a fresh server load preserves both pages and the north-entrance instruction. A successful export alone cannot establish that the next author can continue editing.