Auto-save not triggered when editing Portable Text block fields

[adentdk]

Description

When editing fields inside a Portable Text block (e.g., changing a headline in a Hero block, updating an image in a CTA block), the auto-save mechanism does not fire. The editor does not detect the change as dirty.

However, if you then make any edit to the surrounding Portable Text content (e.g., add a <p> tag, type a space in a text block), auto-save fires and persists both the text change and the previously-undetected block field changes.

This suggests that block field edits don't propagate as TipTap document changes, so onUpdate never fires and isDirty remains false.

Steps to reproduce

1. Open a content item that has a portableText field with custom blocks (e.g., a page with Hero, Feature, or CTA blocks)
2. Click into a block and edit one of its fields (change a title, swap an image, toggle a setting)
3. Wait for auto-save (2+ seconds of inactivity)
4. Expected: Auto-save fires, "Saved" indicator appears
5. Actual: Nothing happens. The editor does not detect the change. No save request is sent.

Workaround: Make any edit to the portable text content outside the block (add/remove a character in a paragraph). This triggers TipTap's onUpdate, which serializes the entire document including the modified block data, and auto-save fires normally.

Analysis

Based on reading ContentEditor.tsx:

• Auto-save uses serializeEditorState() to compare currentData vs lastSavedData
• isDirty only becomes true when the serialized form state changes
• For portableText fields, changes propagate via TipTap's onUpdate → onChange → handleFieldChange → setFormData
• Block fields are rendered as custom TipTap node views. When their internal data (stored as node attributes) changes, TipTap may not consider this a document-level change — the node type, position, and structure haven't changed, only its attributes
• Without onUpdate firing, the PortableTextEditor's onChange callback never executes, so formData never updates, isDirty stays false, and auto-save never triggers

Suggested fix

The block node view (or the field widget renderer inside it) should call editor.commands.updateAttributes() or dispatch a TipTap transaction when block field values change. This would make TipTap recognize the attribute change as a document update, triggering onUpdate → onChange → auto-save.

Alternatively, block field changes could bypass TipTap entirely and directly call the parent handleFieldChange to update formData for the portable text field with the new serialized document.

Environment

• EmDash version: 0.13.0
• Astro adapter: @emdash-cms/cloudflare
• Platform: Cloudflare Workers (local dev via wrangler/miniflare)
• Browser: Chromium-based (reproducible across browsers)

Related issues

• fix: Prevent draft autosave state loss and editor overwriting #283 — autosave state loss (different: stale response, not missing detection)
• Custom Portable Text block types silently dropped on saves (double-save race) #727 — custom PT blocks dropped on double-save (different: race condition, not missing trigger)
• fix(admin): prevent autosave from overwriting in-progress edits #272 / Fix autosave form reset bug #302 — autosave overwriting edits (different: form reset loop)

[jbstewart]

Hit this too — same symptom, same workaround. We instrumented it (on emdash/@emdash-cms/admin 0.14.0 — this issue is 0.13.0, so worth confirming the code matches) and the root cause turned out to be different from the analysis above.

Editing a block via its modal does fire onUpdate → onChange → handleFieldChange("content", …) → setFormData — we logged the serialized Portable Text and it carried the edited value. The change is detected; the form does go dirty.

The data loss comes from PluginBlockModal (packages/admin/src/components/PortableTextEditor.tsx). It renders its own

, and that modal is rendered inside ContentEditor's page-level . The modal's handleSubmit calls e.preventDefault() but not e.stopPropagation(). Clicking the modal's Save bubbles the submit event up the React tree to ContentEditor's onSubmit → a page save fires synchronously with stale formData (captured before React commits the block edit's setFormData). That stale save persists the pre-edit content and clobbers the draft. From the user's side it looks like "nothing saved" — but a save did fire, with the wrong content.

Fix that worked for us — add e.stopPropagation() to the modal's handleSubmit:

const handleSubmit = (e) => {
e.preventDefault();
e.stopPropagation(); // don't let the modal submit bubble to the page
...
};
More robustly: don't render a nested at all (nested s are invalid HTML) — a

+ type="button" Save avoids the whole class of problem. With this change, a block edit correctly marks the page dirty and the normal 2s autosave persists it. Verified end-to-end against the DB draft.

Secondary: handlePluginBlockInsert's "edit existing block" branch uses a raw editor.view.dispatch(tr) while the "insert" branch uses editor.chain()…run(). We routed the edit branch through the command chain for consistency. We did not isolate whether the raw dispatch alone fails to fire onUpdate, so the onUpdate angle above may still be worth a look — but the nested- submit was the decisive bug in our repro.