Currently each edited field is saved individually, causing a revision of a node to be created. Revisions should be created at a more macro level i.e. incorporate numerous field changes to an entity.

Proposed resolution

From #1824500-74: In-place editing for Fields

But we need [revisioning] to work in tandem with the rest of the experience, and not work against it. The only way we could see that work, is by not burdening every field that can be edited with revision metadata. I.e. while the user is happily editing in-place, save all changes that are being made by the user either into a new revision (or even create a new "temporary" revision for each changed field individually, then clean up the revisions once the user is ready with editing — this is similar to what Wordpress does), or into the TempStore. Once the user is ready with the editing, we could then ask the user to say whether (s)he wants to A) overwrite the latest published revision, B) save it into a new revision, though we could just not ask that question and default to B if "Create new revision" is enabled. -- Wim Leers

Remaining tasks


User interface changes


API changes

TBD. Probably none.


Wim Leers’s picture

Title:Introduce a tempstore layer to in-line editing, similar to Views, that allows for atomic revisions of multiple page edits» Introduce a tempstore layer to in-place editing, similar to Views, that allows for atomic revisions of multiple page edits
tim.plunkett’s picture

Issue tags:+VDC

This has nothing directly to do with Views, but tagging so the other TempStore experts also see this :)

I'd be glad to help out with this.

Wim Leers’s picture

Issue tags:+in-place editing, +Spark
Gábor Hojtsy’s picture

Status:Active» Closed (duplicate)
Wim Leers’s picture

Component:other» edit.module