Wp-calypso: Block editor: Posts are permanently deleted instead of sent to trash

[KokkieH]

Steps to reproduce

1. Starting at URL:https://wordpress.com/block-editor/post/SITE_URL
2. Create a new draft post
3. Wait for the post to autosave, or save manually, but don't publish
4. Switch to Document tab and click Move to Trash
5. Try to undo via the banner message or from the Trash folder under Posts

What I expected

1. To see a confirmation message asking if I'm sure I want to move the draft to Trash, same as in the classic editor

2. To be able to restore the trashed post either via the Undo option in the banner that appears, or from the Trash folder itself

What happened instead

1. No confirmation appears

2. After clicking Move to Trash I'm taken to the Trash folder where the draft briefly appears, then disappears. Trying to restore it via the Undo option in the banner leads to an error, and the post does not appear in the Trash folder in either Calypso or WP-Admin to restore from there.

Additionally, in the site's activity log it shows that the draft has been deleted, even though I never took the additional step of deleting it from Trash.

Screenshot / Video

Additional details

Confirmed with the iframed block editor on both WordPress.com and Jetpack sites, and in different browsers.

Using the block editor in WP-Admin still no confirmation is shown when a post gets trashed, but the post is correctly sent to the Trash folder from where it can still be restored.

Trashing a post using the classic editor in Calypso correctly sends the post to the Trash folder from where it can be restored.

Context / Source

Reported in https://en.forums.wordpress.com/topic/fault-with-trash-function/

[gwwar]

This is default behavior in the Block Editor, @apeatling did you want a custom integration here?

[KokkieH]

This is default behavior in the Block Editor

As in the Core editor?

In that case, why is this exclusively happening in the iframed version on WordPress.com? Trashing a post in the block editor from WP-Admin, on both WordPress.com and self-hosted sites, correctly sends the post to the Trash folder for me. Only from Calypso is the post instantly deleted rather than trashed.

Or are you specifically speaking of the confirmation step?

[gwwar]

Or are you specifically speaking of the confirmation step?

@KokkieH Yup the lack of confirmation step! The final hard delete is unexpected though. Do you think a title like "Block Editor: Posts are permanently deleted instead of sent to trash" would help with scanning the issue?

If trash is enabled on a WordPress site (configurable for Jetpack sites), the first API delete call sends a post to trash and the second call hard deletes it. It's the same API signature.

[KokkieH]

I've updated the title. Thanks for the suggestion.

If trash is enabled on a WordPress site

afaik this is always true on a WordPress.com site. So based on what you're saying it sounds like the Send to Trash button in the iframed editor is sending two API calls at once, instead of just one?

[gwwar]

afaik this is always true on a WordPress.com site

Yes, for Simple Sites, but not necessarily for connected Jetpack/Atomic sites. We provide the block-editor integration for each site type on WordPress.com/block-editor

Send to Trash button in the iframed editor is sending two API calls at once, instead of just one?

Very likely, but we'll let folks investigate.

[gwwar]

Hmm, I'm having trouble reproducing this so far, but let's see if we can bulletproof this a bit more.

Edit: going to look into adding redux middleware to block the delete action from actually getting to store reducers.

This is currently backed by:

trashPost: dispatch( 'core/editor' ).trashPost

[KokkieH]

Works for me - trashed post goes to trash, and I can now properly restore it. Thanks!