Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Avoid saving metaboxes before a preview #14877
This PR proposes to remove the saving of metaboxes when previewing a post, which resolves the issue described at #12617. A number of other solutions have been proposed for the bug, but generally all have a shortcoming of some kind—it seems like we're stuck with a process of choosing the best from a bad bunch.
In discussion with @pento, @draganescu and @azaozz it was mentioned that the classic editor didn't (doesn't) save metaboxes during a preview, so while this PR is removing a feature from Gutenberg, it is also reintroducing behaviour that users are used to, and at the same time resolving a bug affecting many.
How has this been tested?
An end-to-end test has been added to catch regressions.
Types of changes
Bug fix (non-breaking change which fixes an issue)
requested review from
Apr 9, 2019
youknowriad left a comment
So, it seems that the classic editor does save the meta-boxes on preview to ensure they are shown properly (as these don't support revisions).
Gutenberg at the moment tries to mimic this behavior by triggering the save (previous to this PR) but it seems like the two saves are causing previews to break (not show the last changes) regardless.
I feel like reverting the metabox save is preview is a good tradeoff that:
The downside is that some changes (the ones coming from the metaboxes) will not be shown in the preview if unsaved.
I think it's the best trade-off we can have for now.
Apr 9, 2019
1 check passed
As the person that raised #12617 - can I ask - has this been tested with edits to existing pages created prior to WP5 and the appearance of Gutenberg which seemed to more regularly trigger this issue compared to content created since then using the steps on your end to end test?
@davidAIS The reason you saw it more with pre WP5.0 content is because it would only occur on published pages. Drafts would do a regular save when clicking preview, published posts would do an autosave. The issue was that the content changes were saved in an autosave, which was then getting deleted when the meta boxes would save.
There were a few people who suggested previews were not working even when they did not have meta boxes, so we have #13232 to try to validate that, but I haven't been able to recreate that issue. I think we'll know more there with this PR merged, as that will eliminate the meta box problem.
@youknowriad I think that e2e test should be testing this against published content. Was the test run with and without this change?
As discussed yesterday the underlying problem here is that two separate requests are fired at about the same time: one to do the autosave necessary for the preview, the other to save metaboxes data. This only happens when previewing changes to published posts that have metaboxes.
Ideally all data that needs to be saved would be combined in one request. If that's not possible, one request has to be "dependent" on the other, i.e. we will need to wait for metabox save to finish before firing the autosave (that means it would be slower, two trips to the server, etc.).
However, another problem is that previewing a published post should not save/update the content for the post, including the post meta. In that case saving of metabox data for published posts should only happen when the post is updated, not on autosaves. This will change when the (long-standing) enhancement for saving revisions of post meta gets done, see https://core.trac.wordpress.org/ticket/20564. Then autosaves for published posts will be able to include post meta data that will be saved in a revision.
This was referenced
Apr 10, 2019
@eanjam -- Actually, I'm the person that opened #13232 and made that suggestion, but as I have worked on things since I have discovered that at least one of the sites that was giving me problems had hidden custom fields-- put in by a plugin that had since been removed. So I now think that the metabox problem is the cause. Part of the problem is that Gutenberg defaults to hiding custom fields on the edit screen, so it was a while before I figured out the extra steps I needed to take in order to display them.
I did test my sites with a function to disable the metabox autosave, and it fully resolved the preview issue on the sites that I tested with. So I'd anticipate that this should resolve the problem. (Although of course that will be inconvenient for sites that do rely on metabox information -- but I actually think that premature saving of custom fields ahead of publication can be causing its own set of problems, so not such a good idea in any event).