Live editing

Live editing lets a team work on the same record at the same time without overwriting each other. Changes autosave to a shared draft, everyone sees who is in which field, plain fields are edited by one person at a time, and rich text fields are typed in together.

Turn it onCopy Anchor Link

Add liveEditing: true next to editorial. Live editing needs editorial, because field locks and the shared draft are measured against the record version it adds. Without it, defineContentType throws liveEditing needs `editorial` , and TypeScript flags the option first:

export const articleContentType = defineContentType({
  id: "example.article",
  tableName: "example_articles",
  editorial: true,
  liveEditing: true, 
  fields: {
    title: field.text({ required: true, minLength: 3, maxLength: 200 }),
    excerpt: field.textarea({ maxLength: 500, nullable: true }),
  },
});

A live session starts when someone opens an existing record's edit form in the AdminCP. That needs three things:

• An AdminCP session, from signing in at /admin.
• The content type's can_edit permission. Someone who can only view the record does not join.
• A saved record. The create form is not live, because there is nothing to share yet.

Presence and rich text co-editing also need the API's WebSocket. Without it, autosave and field locks still work over HTTP, a little slower. Deployment requirements lists what each setup gets.

What editors seeCopy Anchor Link

PresenceCopy Anchor Link

The form header shows an avatar for everyone else in the record, up to five and then +N. Hover or focus an avatar to read where that person is, such as "editing Title". A ring in their color means they are in a field right now.

The field they are in gets an outline in their color with a name tag. When they move to another field, the outline glides after them, and nothing on the page shifts to make room. In a localized form, the language switcher marks the languages people are working in. You never see yourself, and one person in several tabs counts once.

Field locksCopy Anchor Link

Clicking into a plain field, such as a title, slug or category, takes a lock on that field in that language. Everyone else sees the field dimmed and read-only inside the editor's outline, and the value updates as they type. Screen readers announce "Anna Kowalska is editing".

A lock lasts 60 seconds and renews every 20 seconds while the editor stays in the field. Leaving the field releases it, and so does closing the record. A lock nobody renews, say because a laptop went to sleep, expires on its own.

Autosave and the shared draftCopy Anchor Link

About 1.5 seconds after you stop typing in a field you hold, the value is saved to the record's draft. The header shows Saving… and then Draft saved at 14:32, or Draft not saved when the write failed. Next to it, Unsaved changes stays until someone saves the draft into the record.

Changed your mind? Discard next to Unsaved changes throws the draft away after you confirm, and the form goes back to the last saved version. It is a team draft, so everyone editing the record goes back too, and they get a short note saying so.

There is one draft per record and language, shared by the whole team. When you open the record, you see the draft, not only what was last saved. Save commits it through the usual version check and creates one revision. Autosave itself never creates revisions, emits no events and leaves search and caches alone. Preview links also ignore the draft until someone saves.

Rich text co-editingCopy Anchor Link

Rich text fields are not locked and get no outline. Everyone in the same field and language types into one shared document and sees each other's caret with a name tag, plus a tint over the text they select. Undo only undoes your own changes. The example plugin's article has no rich text field, so this is the blog plugin's article editor:

Each language has its own shared document. The first person to open a field fills it from the record. If the connection drops, the editor keeps what you type and sends it when the connection comes back. The server stores the document about two seconds after the last change, and Save writes its current content, everyone's edits included, to the record.

Restores and deletesCopy Anchor Link

Restoring a revision or deleting the record throws away its drafts, locks and shared documents. Everyone in the session gets a notice, and the form reloads with the new state.

Check the resultCopy Anchor Link

1. Sign in at /admin as two staff members with can_edit, for example in two browser profiles.
2. Open the same record's edit form in both.
3. Click into Title in one window. The other window shows the outline and name tag, and the field turns read-only there.
4. Type a few words and wait two seconds. The other window shows the new value, and the header of the first says Draft saved at….

Building your own form layout, or calling the lock and draft routes yourself? See the live editing API.