Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Editing a post in Gutenberg generates too many revisions #3656

Closed
afercia opened this Issue Nov 26, 2017 · 26 comments

Comments

Projects
None yet
8 participants
@afercia
Copy link
Contributor

afercia commented Nov 26, 2017

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:

screen shot 2017-11-26 at 12 17 14

screen shot 2017-11-26 at 12 19 10

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

This comment has been minimized.

Copy link
Contributor Author

afercia commented Nov 26, 2017

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

This comment has been minimized.

Copy link
Contributor Author

afercia commented Nov 28, 2017

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

@aduth

This comment has been minimized.

Copy link
Member

aduth commented Nov 29, 2017

Related: #1773 (comment)

@aduth

This comment has been minimized.

Copy link
Member

aduth commented Nov 29, 2017

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

This comment has been minimized.

Copy link
Contributor

adamsilverstein commented Dec 11, 2017

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.

@adamsilverstein adamsilverstein self-assigned this Dec 11, 2017

@aduth

This comment has been minimized.

Copy link
Member

aduth commented Dec 11, 2017

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

This comment has been minimized.

Copy link
Contributor

lancewillett commented Dec 13, 2017

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

This comment has been minimized.

Copy link
Contributor

adamsilverstein commented Dec 15, 2017

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

This comment has been minimized.

Copy link
Member

aduth commented Dec 15, 2017

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

This comment has been minimized.

Copy link
Contributor

adamsilverstein commented Dec 18, 2017

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

This comment has been minimized.

Copy link
Contributor

adamsilverstein commented Dec 18, 2017

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

This comment has been minimized.

Copy link
Member

aduth commented Dec 18, 2017

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

This comment has been minimized.

Copy link
Contributor

adamsilverstein commented Dec 19, 2017

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 adamsilverstein referenced this issue Dec 20, 2017

Closed

Published posts should autosave #4112

0 of 2 tasks complete
@adamsilverstein

This comment has been minimized.

Copy link
Contributor

adamsilverstein commented Feb 2, 2018

This should be resolved by #4218

@DrewAPicture

This comment has been minimized.

Copy link
Member

DrewAPicture commented Mar 5, 2018

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

This comment has been minimized.

Copy link
Contributor

adamsilverstein commented Mar 7, 2018

@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

This comment has been minimized.

Copy link
Member

DrewAPicture commented Mar 7, 2018

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

Currently a draft on make/docs.

@mtias mtias added this to the Core API milestone Mar 8, 2018

@mtias mtias added the Priority High label Mar 8, 2018

@ocean90 ocean90 referenced this issue Mar 25, 2018

Closed

Gutenberg saves a huge number of revisions #5781

0 of 2 tasks complete
@mhsabbagh

This comment has been minimized.

Copy link

mhsabbagh commented Mar 25, 2018

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

@danielbachhuber danielbachhuber changed the title Too many revisions Editing a post in Gutenberg generates too many revisions Apr 4, 2018

@danielbachhuber

This comment has been minimized.

Copy link
Member

danielbachhuber commented Apr 9, 2018

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

@adamsilverstein

This comment has been minimized.

Copy link
Contributor

adamsilverstein commented Apr 9, 2018

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

This comment has been minimized.

Copy link
Member

aduth commented May 31, 2018

Can this be considered closed by #6257 ?

@danielbachhuber

This comment has been minimized.

Copy link
Member

danielbachhuber commented May 31, 2018

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

@danielbachhuber

This comment has been minimized.

Copy link
Member

danielbachhuber commented Jun 4, 2018

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

@danielbachhuber

This comment has been minimized.

Copy link
Member

danielbachhuber commented Jun 4, 2018

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:

image

Here's a GIF of the revision history:

travelpost

It seems like revisions are being created when autosave fires.

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

@danielbachhuber

This comment has been minimized.

Copy link
Member

danielbachhuber commented Jun 5, 2018

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:

toomanyautosaves

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

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

@danielbachhuber

This comment has been minimized.

Copy link
Member

danielbachhuber commented Jun 5, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.