Always set posts to draft status when untrashing

[harrym]

In some situations it is bad when trashed posts immediately go live after being untrashed. Such as:

• A published post is found to have libellous/wrong/other_bad content in it
• Admin trashes the post
• Admin wants to edit the post and republish it without the bad things
• Admin cannot do this without republishing the bad things, which they cannot do.

I appreciate that the user should have unpublished the post rather than trashing it but people don't always think clearly in these situations, and once you're in it, you can't get out -- your options are to republish, permanently delete, or leave the post in limbo.

I did wonder if it would be better to make trashed posts viewable/editable in the admin but that felt like a pretty big move, and one that would make the status of a trashed post much less clear and rather ambiguous.

So, the attached patch sets all untrashed posts to draft status, rather than restoring their original status, which was the only other thing I could think of.

(Definitely happy to debate alternative solutions)

[harrym]

Sets untrashed posts to draft status instead of their original status

[bananastalktome]

Should probably also stop adding _wp_trash_meta_status to a post as well, then (patch by @harrym updated to include this)

[harrym]

Is it possible to consider this for inclusion in 3.7?

[DrewAPicture]

Replying to harrym:

Is it possible to consider this for inclusion in 3.7?

It's too late for 3.7 as it's an enhancement and we're already in beta. 3.8 may be a possibility though.

[SergeyBiryukov]

Related: #15930, #22350.

[chriscct7]

What about adding the ability to "preview" the trashed post, in the admin, similar to the screen for editing the post minus the ability to change any of the content, but you'd still get the publish metabox where the restore, delete permenantly, and change status to dropdown could be. In a site with many trashed posts, particularly on sites with many posts of the same name, there's no way to tell which page you're actually restoring. In allowing for the ability to "preview" the post, we can easily offer the ability to set the status to something like draft or pending.

[melchoyce]

I like this idea — it's a good safety net for folks.

However, I'm a -1 for @chriscct7's idea, which sounds very complex. I think restoring as a draft is good enough, FWIW.

[johnbillion]

I think the preferred behaviour here would be to always restore trashed posts to draft status, along with a new filter so that the restored post status can be filtered.

The functionality of the _wp_trash_meta_status meta field should remain.

[jaredcobb]

When applied, this causes posts to be assigned a post_status of draft by default when they are untrashed (restored). Also adds a new filter for the post status called wp_untrash_post_status to allow customization of this post status.

[jaredcobb]

Note: In order to keep the previous behavior (where a restored post receives the post_status it had before it was trashed) use the wp_untrash_post_status filter like so:

<?php
add_filter( 'wp_untrash_post_status', function( $new_status, $post_id, $previous_status ) {
        return $previous_status;
}, 10, 3 );

[pankajmohale]

Replying to harrym:

In some situations it is bad when trashed posts immediately go live after being untrashed. Such as:

• A published post is found to have libellous/wrong/other_bad content in it
• Admin trashes the post
• Admin wants to edit the post and republish it without the bad things
• Admin cannot do this without republishing the bad things, which they cannot do.

I appreciate that the user should have unpublished the post rather than trashing it but people don't always think clearly in these situations, and once you're in it, you can't get out -- your options are to republish, permanently delete, or leave the post in limbo.

I did wonder if it would be better to make trashed posts viewable/editable in the admin but that felt like a pretty big move, and one that would make the status of a trashed post much less clear and rather ambiguous.

So, the attached patch sets all untrashed posts to draft status, rather than restoring their original status, which was the only other thing I could think of.

(Definitely happy to debate alternative solutions)

<?php
// define the untrash_post callback 
function action_untrash_post( $post_id ) { 
    
    $post_status = get_post_meta($post_id, '_wp_trash_meta_status', true);
 
    $post['post_status'] = $post_status;
 
    delete_post_meta($post_id, '_wp_trash_meta_status');
    delete_post_meta($post_id, '_wp_trash_meta_time');
 
    wp_insert_post( wp_slash( $post ) );
 
    wp_untrash_post_comments($post_id);

}; 
         
// add the action 
add_action( 'untrash_post', 'action_untrash_post', 10, 1 ); 

[DrewAPicture]

Assigning to mark the good-first-bug as "claimed".

[johnbillion]

23022.patch​ is a refreshed patch that includes unit tests.

Two scenarios that haven't yet been considered:

1. The Undo action that appears immediately after trashing a post. I think clicking the Undo button should restore the post to its original status. Only untrashing a post from the trash should restore it to draft. 23022.patch​ includes this functionality.
2. Untrashing a media file when MEDIA_TRASH is defined and true. Attachments can't be draft, so this needs testing.

[johnbillion]

#50618 was marked as a duplicate.

[johnbillion]

#37366 was marked as a duplicate.

[johnbillion]

I refreshed the most recent patch. As a reminder, this:

• Switches to always restoring posts from the trash as a draft
• Adds a wp_untrash_post_status filter to change this behaviour
• Restores a post to its original status when the user hits Undo after trashing a post
• Adds tests

Additionally in 23022.diff​:

• Adds the $previous_status parameter to the various hooks inside wp_untrash_post()
• Adds an Edit Post link to the confirmation message after restoring a single post from the trash (see #50618)
• Fixes an existing issue in wp_untrash_post() where $post_id might remain as 0 in the unlikely event the function is called without a $post_id parameter

To recap some reasons why making this change is a good idea:

• Restoring a previously published post causes it to be re-published
• Restoring a scheduled post can cause it to be published (#37366)

[johnbillion]

One item left to test: Behaviour when MEDIA_TRASH is defined and set to true. Might need a condition for the default value passed to the wp_untrash_post_status filter to account for this.

[johnbillion]

This change works fine when MEDIA_TRASH is in use because wp_insert_post() converts most post statuses to inherit when working with the attachment post type, but just for clarity I've added a line to explicitly use inherit for attachments.

[johnbillion]

In 49125:

Posts, Post Types: Switch to restoring posts to draft status by default when they are untrashed.

This allows for edits to be made to a restored post before it goes live again. This also prevents scheduled posts being published unexpectedly if they are untrashed after their originally scheduled date.

The old behaviour of restoring untrashed posts to their original status can be reinstated using the wp_untrash_post_set_previous_status() helper function.

Also fixes an issue where the incorrect post ID gets passed to hooks if no post ID is passed to the function.

Props harrym, bananastalktome, jaredcobb, chriscct7, melchoyce, johnbillion, pankajmohale

Fixes #23022

[johnjamesjacoby]

This broke bbPress, which relied pretty heavily on the previous behavior for topic and reply moderation.

​https://bbpress.trac.wordpress.org/ticket/3433

The new wp_untrash_post_status filter did not help existing plugins maintain their status quo's.

Why was there was no developer note for this breakage?

In my opinion, the committed solution here is suboptimal. The wp_untrash_post_set_previous_status() implementation should have been the first clue this was not a great idea.

A new property could have been added to WP_Post_Type to define the untrash status/behavior – core post types could have updated themselves (to default to draft per this issue) and the world of a thousand registered custom post types could migrate at their convenience, and no new single-use filter or function shim would have been necessary.

[jaredcobb]

Replying to johnjamesjacoby:

This broke bbPress, which relied pretty heavily on the previous behavior for topic and reply moderation.

​https://bbpress.trac.wordpress.org/ticket/3433

The good news is that the patch in 3433 fixes the issue in bbPress.