Content moderation

Frontend editing works with content moderation. A change made from the page never publishes moderated content on its own: it is saved as a pending draft, and the published revision stays live until someone publishes the draft.

This applies when the edited entity, or the host a paragraph belongs to, is under a content moderation workflow. Entities without moderation are saved as before.

What happens when an editor changes something

The entity is in	The change is saved as
A published state	A new revision in the workflow's draft state. The published revision stays the default revision.
An unpublished state, such as draft	A new revision in that same state
No moderation state, or not moderated	A normal revision, as before

The draft state is the workflow's default moderation state when that state is unpublished, and draft otherwise.

Consecutive changes build on the pending draft rather than on the published content, so two edits in a row do not overwrite each other.

New revisions carry the editor as the author, the current time, and the log message "Updated with frontend editing." The log message of the revision they were copied from is not reused. The save queue lets the editor type their own message.

Saving and publishing directly

Save always creates a draft. An editor who is allowed to can instead use Save and publish in the paragraph form of the sidebar, which saves the change straight to the published revision. The page then updates in place, with no draft and no redirect.

The button only appears when all of these hold:

• The content is moderated and its live revision is published.
• It has no pending draft. The form of a draft edits the draft, and publishing over a draft would leave it stale or overwrite it.
• The user has the frontend editing publish directly permission.
• The user may make the workflow transition from the published state into the published state, for example use editorial transition publish.

So that editors know what each button does, the paragraph form shows a note above the buttons whenever saving creates a draft, and each button has a tooltip:

• With both buttons: "Save" saves your changes as a draft. The published version stays unchanged until the draft is published. "Save and publish" publishes your changes immediately.
• With Save only: "Your changes are saved as a draft. The published version stays unchanged until the draft is published."

No note is shown for content that is not moderated, or when the form edits a draft.

Without the button the editor can still publish a draft from the node's own moderation controls. Move, delete, duplicate and the save queue always create drafts, because they have no form to hold the button. The button is available for paragraph forms only. Other entities are edited through their own form, which offers the workflow state itself.

Changing the live page

While a draft exists, the live page shows the published revision, which is not the latest one. The action links on it are not offered, because replacing a single field on the live page would mix draft content into published content. The draft page (/node/{id}/latest) offers them.

When an editor changes something on the live page of content that has no draft yet, the change is saved as a draft and the browser is sent to the draft page, with a warning:

Your change was saved as a draft. The live page stays unchanged until the draft is published.

The page scrolls to the paragraph that was moved or duplicated. On the draft page, later changes update the page in place as usual.

The redirect only happens when the editor is allowed to see the latest version of the content. Links carry a default_revision=1 query parameter to say that they were rendered on the live page; a link without it never causes a redirect. Pages cached before this feature existed have links without the parameter, so they update in place until they are rendered again.

Who may save a draft

Saving from the page skips the entity form, which is where content moderation normally validates the state transition. Frontend editing therefore checks the transition itself:

• The user needs the workflow transition into the draft state, for example use editorial transition create_new_draft.
• Without it, the action links and the paragraph edit link are not offered, and a request made by hand is refused with an access denied response before anything is saved.

See Permissions.

Limitations

• The log message is fixed. Besides the choice between Save and Save and publish, the editor cannot choose the target state. A site that needs something else can replace the frontend_editing.revision_helper service. See Services.
• Only paragraphs are followed up to their host. Other composite entity types need a sub-module that overrides getRevisionRoot().
• Previewing the draft before saving and choosing any other workflow state in the sidebar are not part of this feature.