Extensibility: Add a way for third parties to perform additional save validation

[noisysocks]

Is your feature request related to a problem? Please describe.

Plugins like Advanced Custom Fields require a way to perform additional validation when a post is published or updated. This validation can be asynchronous.

Describe the solution you'd like

I'm thinking that the most flexible solution here would be to wrap the call to apiFetch() made by requestPostUpdate() with a filter. This will let third parties perform as much additional asynchronous validation as they would like, or even replace the entire API call with their own.

Example:

wp.hooks.addFilter( 'editor.updatePost', async ( options ) => {
	if ( ! performPreSaveValidation() ) {
		throw 'The post is invalid! A pre-save check failed.';
	}
	const response = await wp.apiFetch( options );
	if ( ! performPostSaveValidation() ) {
		throw 'The post is invalid! A post-save check failed.';
	}
	return response;
} );

Describe alternatives you've considered

I considered an alternative approach using PluginPrePublishPanel but this does not handle the case where validation needs to happen on an update to an already published post.

[noisysocks]

@gziolo @youknowriad: Any thoughts or ideas for alternative approaches?

[youknowriad]

Adding @aduth and @adamsilverstein as they may have thoughts on async filters.

[gziolo]

I'm not that familiar with all the parties involved in the post save flow. I know that we use all those effects for actions which operate on the store:
https://github.com/WordPress/gutenberg/blob/master/packages/editor/src/store/effects/posts.js

I think @aduth had some thoughts about how to deal with extensibility in that area.

[aduth]

Previously: #7020

[aduth]

In what way is lockPostSaving insufficient for achieving this?

[noisysocks]

In what way is lockPostSaving insufficient for achieving this?

Calling lockPostSaving() from a component within PluginPrePublishPanel is insufficient because the pre-publish panel does not appear when an already published post is being updated.

There's no other good opportunity to call lockPostSaving(). ACF needs to do additional server-side validation when the post is being published or updated. This means we'd have to call lockPostSaving() when the Publish or Update button is clicked, by which time it's obviously too late to lock post saving.

[noisysocks]

Have a look at AdvancedCustomFields/acf#113 for some context on the requirements here.

[gziolo]

It took me some time to find a very related issue #4674 where TLDR; is

There are times when on pre or post publishing there are additional custom steps we want to run.

The proposed solution by @adamsilverstein was sufficient for the author:

@IeuanCaseyNewton I started working on a PR to add an action, then realized I think you can detect the post status change to published using the existing wp.data api. Can you try this and see if it solves your use case:

const { subscribe } = wp.data;

const initialPostStatus = wp.data.select( 'core/editor' ).getEditedPostAttribute( 'status' );

if ( 'publish' !== initialPostStatus ) {
	// Watch for the publish event.
	const unssubscribe = subscribe( () => {
		const currentPostStatus = wp.data.select( 'core/editor' ).getEditedPostAttribute( 'status' );
		if ( 'publish' === currentPostStatus ) {
			// ...do something here - the post has been published
		}
	} );
}

lockPostSaving might still turn out to be useful in such approach. I also recommend reading comments from #4674 to check other ideas.

[noisysocks]

Such an approach won't work as it will be too late to lock post saving by time currentPostStatus is 'publish'. We want to prevent post saving after the Update or Publish button is clicked but before the request to PUT /wp/v2/posts/:id is made.