Editor: Save post after deletion so that its status is refreshed and redirection happens.

[epiqueras]

Fixes #17426

Description

This PR fixes the issue described in #17426.

How has this been tested?

It was verified that moving a post to the trash works as expected.

Types of Changes

Bug Fix: Redirect users after moving a post to the trash.

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.

[mcsf]

What does it mean to save a deleted post? My first impression is that we're abusing action creators a little in order to get a result not intended from them.

My second note is that the outbound comment mentions that editPost isn't used because of its ties to change detection, while savePost itself dispatches editPost.

[epiqueras]

What does it mean to save a deleted post? My first impression is that we're abusing action creators a little in order to get a result not intended from them.

It saves and refetches the post, getting the new status.

My second note is that the outbound comment mentions that editPost isn't used because of its ties to change detection, while savePost itself dispatches editPost.

I can't think of any issues it could cause.

[aduth]

In my testing, "Move to Trash" still doesn't complete a redirect, at least not without first prompting the user there are unsaved changes. #18269 is partly related here, though it applies to non-metabox scenarios. I worry also that we try to save all changes, when it's the case that the REST API may reject some of those pending changes (evidenced by the error message in #18269 about editing trashed posts).

When I run wp.data.select( 'core/editor' ).getPostEdits() after seeing the prompt for redirecting, it always seems to return an object with the blocks value, regardless of whether I've made any changes to the post or its content. Could this stem from some of the recent refactoring? (#16932)

[epiqueras]

In my testing, "Move to Trash" still doesn't complete a redirect, at least not without first prompting the user there are unsaved changes. #18269 is partly related here, though it applies to non-metabox scenarios. I worry also that we try to save all changes, when it's the case that the REST API may reject some of those pending changes (evidenced by the error message in #18269 about editing trashed posts).

It was a nasty race condition. Fixed and explained here: #18275.

When I run wp.data.select( 'core/editor' ).getPostEdits() after seeing the prompt for redirecting, it always seems to return an object with the blocks value, regardless of whether I've made any changes to the post or its content. Could this stem from some of the recent refactoring? (#16932)

That's expected, blocks are a transient edit and are not part of change detection.