Editing a post in Gutenberg generates too many revisions

[afercia]

See also #3258 and #2385

Definitely not my area of expertise and I haven't followed the discussion about saving / autosave / revisions so I'm probably missing something. However, seems to me this is an issue of fundamental importance, as the amount of revisions that get saved is insanely big.

I've just created a new post, nothing special: just a title, couple paragraphs, a list, and an image. Then pressed "Publish" once. And I've got 9 revisions:

The amount of saved revisions can be way bigger with more complex post content and workflows. Even applying some basic formatting, for example making a word bold, puts Gutenberg in a "save draft" state, and then when the autosave triggers, a new revision gets created. This happens with any edit, also when changing a block position, or alignment, etc. Creating a post with some more blocks and formatting can easily generate dozens of revisions.

Seems to me every time Gutenberg auto-saves the post content, it creates a new revision. This can be easily observed also in the Gutenberg sidebar: while adding and editing content, the number of revisions increases. I'm not sure this is ideal, and seems to me it's a big change in how revisions and autosaves are handled in WordPress.

Creating a similar post in the Classic Editor typically saves just the post, one revision (which isn't even shown in the UI) and sometimes (depending on the workflow) the special "autosave" revision.

[afercia]

I guess this happens also with the Gutenberg plugin, so it's happening to everyone who's testing Gutenberg on their site. I'd recommend to clearly state to not test Gutenberg on productions sites, since at the moment it's adding lots of unnecessary stuff in the database.

[afercia]

Seems to me this is a blocker, I'd like to see some higher priority for this issue.

[aduth]

Related: #1773 (comment)

[aduth]

I think can tie into supporting autosave for published posts, which is effectively the need to add support for notion of autosave behavior to core API posts endpoints (doesn't currently exist).

[adamsilverstein]

The way autosaves work on core currently, a revision is created whenever the content has changed. In the classic editor, I believe we only perform autosaves in specific intervals, after x seconds, when the user is idle. It seems like Gutenberg currently autosaves too frequently, on every block blur maybe? For now, I think we can better match the timing of autosaves to get similar behavior to the classic editor.

[aduth]

As I understand the logic, it appears the main difference in the classic editor is not the timing of the saves, but that the automatic save assigns a constant which is checked against to abort creating a new revision:

https://github.com/WordPress/wordpress-develop/blob/1b5554e/src/wp-admin/includes/post.php#L1871-L1873
https://github.com/WordPress/wordpress-develop/blob/1b5554e/src/wp-includes/revision.php#L112-L114

[lancewillett]

Would be well worth looking at how this has already been solved in other top-of-class editors like Google Docs. The best user experience seems to be a combination of:

Automatic saves:

1. Time elapsed: don't wait too long, in case of a crash.
2. Create revisions with a meaningful enough chunk of text, but not every single character change if in rapid succession. Phrases or sentences.

Manual saves:
Creates a revision for each one. Consider the ability to name revisions.

[adamsilverstein]

it appears the main difference in the classic editor is not the timing of the saves, but that the automatic save assigns a constant which is checked against to abort creating a new revision:

The classic editor uses wp.autosave to save every 10 seconds at most, and only if the content has changed, is that logic in place in Gutenberg? https://github.com/WordPress/wordpress-develop/blob/1b5554e8188f24a0b522d82a2eccb7d098b878bb/src/wp-includes/js/autosave.js#L599

[aduth]

The classic editor uses wp.autosave to save every 10 seconds at most, and only if the content has changed, is that logic in place in Gutenberg?

Similar logic, yes:

https://github.com/WordPress/gutenberg/blob/master/editor/components/autosave-monitor/index.js

The "content has changed" behavior may not match what exists in core. Previously this was more accurate to performing a deep comparison on the current editor state against the last saved post (#1996), but was simplified recently to simply toggle into a changed state after any changes have been made (#3298).

[adamsilverstein]

Ok, i finally see what is happening here.

When creating new posts, Gutenberg is currently creating a new revision for each modification/autosave - instead of saving to a single draft post. regular revisions should only be created when the user explicitly clicks the publish or update button. In the classic editor no matter how many times you save a draft only a single draft revision (and single db row) is created.

When a post is published we create at most one autosave per user. regular revisions are only created when you actually update a post by saving a draft or updating a published post. autosaves are a special kind of revision and are created after 10 seconds when content changes. note that data is also stored in localStorage if available so if the save fails (offline) the autosave still works.

[adamsilverstein]

I took a pass at addressing this in #4062 - this change prevents saving of revisions when a draft is autosaved.

Along the way I noticed that Gutenberg currently does not autosave changes to published posts. The inline docs indicate this is due to lack of support from core, however we may be able to achieve the correct result with existing filters. Is there an issue open for this already?

[aduth]

Closest issue is #1773, which was closed when draft autosave support was added. There's a mention there of published posts autosave.

however we may be able to achieve the correct result with existing filters.

Could you elaborate on this?

[adamsilverstein]

Could you elaborate on this?

I was thinking we could hook in during the normal rest handler process (not certain which hook yet) and given a certain condition, call wp_create_post_autosave instead. This seems cleaner than the other option which would be a custom endpoint. I'll create a separate issue and see if I can get these working.

[adamsilverstein]

This should be resolved by #4218

[DrewAPicture]

Just following up here, @adamsilverstein does the resolution for #4218 cover the case where there's an unnaturally high number of revisions for the level of editing going on? I'm current writing a post in Gutenberg that's at ~220 revisions, whereas I'd expect more like 20 or 30 under the classic editing conditions.

[adamsilverstein]

@DrewAPicture thanks for checking in. No, unfortunately the scope for #4218 was narrowed to only showing the autosave notice - I was never able to get much traction on my heartbeat based approach to autosaving despite many passes at suggested corrections and rebases. I'll work on a newer, narrower pr soon that leverages the REST API instead, see https://core.trac.wordpress.org/ticket/43316.

Out of curiosity, is your post a draft or published?

[DrewAPicture]

Out of curiosity, is your post a draft or published?

Currently a draft on make/docs.

[mhsabbagh]

Same issue here, except that I get something like 225 revisions for a complete 700-word post.

[danielbachhuber]

I've opened a new wp-cli/ideas issue to assist with revision cleanup: wp-cli/ideas#94

[adamsilverstein]

We are working on adding autosave capabilities to the WP REST API which is required to solve the underlying issue here (without using heartbeat). See https://core.trac.wordpress.org/ticket/43316

[aduth]

Can this be considered closed by #6257 ?

[danielbachhuber]

Yep, I think so. We can open new issues for other items.

[danielbachhuber]

@adamsilverstein @aduth This is (somehow) still happening with 3.0

[danielbachhuber]

This is (somehow) still happening with 3.0

To clarify, I updated to Gutenberg 3.0 on my personal blog. I then published a blog post that was mostly a copy and paste from Simplenote. Somehow, I ended up with 11 revisions:

Here's a GIF of the revision history:

It seems like revisions are being created when autosave fires.

However, I can't reproduce against my local copy of Gutenberg.

[danielbachhuber]

Ah, I've figured it out: the presence of Yoast SEO (aka a classic metabox) is causing autosave to trigger a normal save (or something of that sort).

See this GIF:

Notably, see the "Autosaving..." animation, quickly followed by "Saving..."

I'm going to open a new separate issue for this.

[danielbachhuber]

#7135