Meta box back-compat concurrency.

[peterwilsoncc]

Describe the bug
This is related to WP#45114, in which the REST API published posts before post meta and terms are saved.

In Gutenberg a concurrency issue exists when the back-compat meta boxes are available. The post content and blocks with meta data save via the REST API (hitting the issue above) while the compatibility meta boxes save via POST request, saving the meta data via wp_insert_post().

Presuming a patch for the REST API ticket above is committed, the concurrency issue will still exist as the hooks within wp_insert_post() will be fired twice.

If the back-compat meta box is in use in Gutenberg, even presuming the patch is applied, it would be handy to publish posts and fire the related hooks on the second of the two requests completed. Be that the form POST or the REST request.

This of course causes some race conditions that need to be worked around as the nature of HTTP is that there is no way of determining which request will complete first if they are fired in parallel. A Promise could be used to ensure the order but this would slow down the saving process.

To Reproduce
Steps to reproduce the behavior:

1. Create an old school custom meta box.
2. In the save function, include sleep( 5 ) before saving
3. As with the WP ticket above, the post will published before the meta data is saved. This will continue to happen if the REST API enhancement is made.

Expected behavior
Publishing post occurs once, only after terms and all meta data has been saved.

[danielbachhuber]

Also related: https://core.trac.wordpress.org/ticket/44886

Honestly, I'm not sure this is possible to solve without some major architectural changes.

[danielbachhuber]

@peterwilsoncc Do you have any suggestions on how we should address this, or should we document it as an implementation detail to be aware of?

[peterwilsoncc]

@danielbachhuber I've been turning over a few ideas but haven't got anything that would work without the need for major changes. This is what I have:

1. When the author hits publish, the REST request is submitted
2. Rather than updating the existing post object, create a temporary copy (via the autosave endpoint or as a draft 🤷🏻‍♂️)
3. Once the REST request completes, submit the meta box POST request that includes the ID of the temporary copy
4. At the end of the meta box POST, the post object is replaced with the temporary copy.

What's holding me back on this is that it defeats the purpose of making asycronous updates via the REST API. To an extent, using old school meta boxes already does this so it may be the most pragmatic approach.

On the related WP Core ticket I've created a very rough POC. It introduces an undocumented, private argument to wp_insert_post() to delay firing of hooks that could be used in this situation too.

[peterwilsoncc]

If that idea is too dreadful to contemplate, then I'm happy enough for it to be documented as an implementation warning :)

[danielbachhuber]

f that idea is too dreadful to contemplate

I'm pretty horrified at this point, to be honest :)

I think we should wait on action until the future indicates whether this is a critical problem to solve or not.

[danielbachhuber]

Moving to WP 5.1 Onwards because this issue doesn't seem critical to solve in 5.0 at this point.

[peterwilsoncc]

Is this a wont fix? I think the wp_after_insert_post hook introduced in WP 5.6 can be used to make it even more of an edge case https://make.wordpress.org/core/2020/11/20/new-action-wp_after_insert_post-in-wordpress-5-6/

[jordesign]

Just looping back to this - with no further discussion in 2 years - I'd say this can be closed as wontfix too...

[peterwilsoncc]

@jordesign Yep, let's close it off without a fix.