"Trash" status for comments and posts

[markjaquith]

Lets channel some Robert Hoekman Jr. and get rid of all modal AYS dialogs. Recommended alternative is "N nouns were verbed. Undo?"

This would require some place to store deleted items temporarily. We'd need to store one item (or batch of items... the result of a single operation) per user... so the usermeta table seems a good place. I don't think we necessarily need a new table just for this purpose.

This would be a fairly massive undertaking, but it'd make WP more fun to use.

[filosofo]

Wouldn't this undercut the protection from CSRF-type attacks offered by the AYS dialogs?

For example, say I visit a hostile site that uses Javascript in an iframe or whatever to attempt to delete one of my posts. As I understand the current system, I might not see the AYS dialog that would appear upon receiving such a non-nonced command, but my failure to approve it would stop the deletion from occurring. It seems like under your scenario the deletion would occur and I would be none the wiser.

[markjaquith]

You're confusing the CSRF-preventing HTML form AYS screens (which have to stay) with modal JS AYS dialogs (which are JS popup windows that you have to deal with before you can do anything else in your browser window). The modal JS windows are to prevent accidental actions because of errant mouse clicks, not to prevent CSRF. They are layered on top of the CSRF protection (that is, they ask you if you're sure, and then go to the nonce'd URL, which, with an incorrect nonce, would trigger the CSRF AYS HTML form).

Bottom line: no, this won't make WordPress any less secure from CSRF attacks.

[darkdragon]

I don't think it is likely that this will get in to 2.4 without a patch. Sending to the next version, because of the lack of a patch and being close to the release.

[MattyRob]

I don't think it is likely that this will get in to 2.6 without a patch. Sending to the next version, because of the lack of a patch and being close to the release.

[caesarsgrunt]

+1

I occasionally delete the wrong comments by mistake. Once I've clicked delete I just click OK automatically before realising - too late - that it's the wrong one.

How about adding a 'deleted' status value for posts and comments, in addition the the existing 'draft', 'published', 'moderated', etc. This would IMO be an easy, simple, and intuitive method of going about this. Then a 'Trash' page can be added for seeing deleted posts/comments/etc, from which they can be permanently destroyed, and a cron/whatever script can destroy items which were deleted more than a certain time ago.

Maybe the priority/severity should be raised? I don't know how many people are bothered by this or regularly loose things...

[caesarsgrunt]

Temporary deletion of comments, first attempt.

[caesarsgrunt]

Here's a first try at enabling 'temporary' deletion of comments - OS X 'Trash' / Windows 'Recycle Bin' style - allowing them to later be either restored or permanently deleted.

This patch doesn't automatically destroy comments which were deleted x days ago, yet, though this will be a necessity.

I hope I included all of the changed files I changed in the patch...

Please have a look and let me know what you think of it.

[caesarsgrunt]

Some feedback on the temporary deletion of comments would be nice, so I know if there's any point in me carrying on enhancing it...
I'd very much like to see this feature get into trunk!

[caesarsgrunt]

Temporary deletion of comments, with auto-destruction

[caesarsgrunt]

This second patch automatically destroys (ie. permanently) comments 30 days after they were deleted (ie. temporarily). (Maybe this should be an option?)

Next I might add a note at the top of the page after comments are deleted, Gmail style. "X posts were deleted. Undo?"

Note that at present if you 'reply' to a comment using the new ajax reply form, and then delete the second comment on the page, the delete function is called twice for that comment. Due to the nature of my 'patch' this causes that comment to be permanently deleted immediately, like it currently is anyway without the 'patch', whilst temporarily incrementing the deleted comment count by two.
I think this is a bug with the reply feature, but I'm not sure.

Feedback please!
If popular I'll do the same for posts; should be just as easy.
If unpopular I'll try making it into a plugin, at least for myself. Might be harder...

[caesarsgrunt]

Updated patch, due to major changes in the WP core...

[caesarsgrunt]

Just uploaded an updated patch, taking account of major changes which have been made to the WP core since I originally created this patch.
I hope I've included all the files I changed...

Since no-one is giving their opinions on this, perhaps it could be committed?

[ShaneF]

This is a first time I am looking at this. +1 to this idea. Having a 'deleted' comments area is different than 'spam' and it allow for us to historically (if we wanted) regular user comments that we removed for any particular reason.

Changing this back to 'normal' priority.

[mrmist]

Needs tweaking against a new build again. Nice idea though.

[Denis-de-Bernardy]

+1 to the idea as well. but it would be sweet if interesting patches like this got committed on the spot, too, so that they don't rot for years and become stale. :-|

[caesarsgrunt]

I am happy to do some more work on this if it is likely to get in - I am assuming that being "blessed" means it will?

[Denis-de-Bernardy]

It mostly means it was discussed during the meet-up yesterday, as a nice to have feature for 2.9. Marked it as task/blessed so we can quickly find such nice to haves in trac.

[caesarsgrunt]

Not sure whether that means it's any more likely to get in or not... but I have updated my patch, which now works perfectly on trunk (and without the bugs which were present in my earlier patch).
I believe the new patch works perfectly, and would like to see it committed before it gets out of date again... what needs to be done?

[caesarsgrunt]

Sorry, I've just realised I didn't compress edit-comments.js. I'm not actually sure what method you use for this - perhaps someone could let me know, and I'll do it.

[Denis-de-Bernardy]

It's usually better to leave the compressed js alone, since it'll invariably make the patch corrupt when applied after anything else gets committed. (in case you're not familiar with it, use the SCRIPT_DEBUG define to use the dev versions.)

[caesarsgrunt]

Patch against 11707

[caesarsgrunt]

Thanks Denis, I have re-uploaded my latest patch without the compressed js.
I've just realised it doesn't yet handle the automatic destruction of deleted comments after 30 days; I'll add that later.

[caesarsgrunt]

With automatic permanent deletion after 30 days

[caesarsgrunt]

I'm happy to work on the same feature for posts, pages, media, links, and perhaps even users - but I'd like to see this patch for comments committed first, so I know it's actually going to happen...

[westi]

I think we need more discussion on the user-experience expected here to ensure we do the right thing before we commit any code.

Your patch takes one approach (the auto-emptying Trash bin) but I have also heard mooted the idea of undo rather than trash as a more user-friendly experience.

It depends on what we are trying to achieve.

With regard to the patch itself if we do go down this route I think it would be better to have a daily/weekly/... scheduled event that empties old trash rather than a cron hook per comment.

[caesarsgrunt]

I agree that an undo feature should be added, but I think that this trash status is needed as well.
For a start, the concept of something which is deleted going to a trash bin and being recoverable is familiar to most people as this is how many other computer interfaces work.
But also, for an "undo" feature to work, the deleted comment has to be kept at least until the next page load. My patch therefore provides a large part of the backend for the undo feature.
I will add the undo feature to my patch later - this will be fairly easy.

Regarding the exact system for deleting comments after a specified time, I suppose we could do it that way, but it would require a new column in the comments database table, which would be more complex, and it would require a script to check every comment every day to find out whether it should be deleted, rather than just scheduling deletion for individual comments.
Alternatively we could use a new row in the options table and just list each deleted comment and the date when it was deleted, but this would still require that a script be run every day even when there are no comments to be deleted.

I might also make it so that when spam comments are deleted they skip the trash altogether - this is how most email clients work, and additionally it avoids the scheduling of a lot of deletions.

[caesarsgrunt]

Another thing about the undo feature - if we're going to have a notice above the comments list saying "1 comment was deleted (Undo)", then we will presumably do the same for other statuses? Eg "1 comment was marked as spam (Undo)", and "1 comment was approved (Undo)". In which case the undo feature should probably be another ticket. But in that case this would have to be committed first, since it will provide the backend for the undo feature for deleted comments.

[azaozz]

Don't think we need Undo for approved, unapproved, spam, etc. They all can be reversed easily. Instead of Undo we can have "One comment moved to the trash", would be clearer. Then the same for posts, pages, etc.

[caesarsgrunt]

Hmm... but with this, delete can also be undone just as easily. There is really no difference in terms of ease of undoing between deleted and spam, for example. Or are you saying we should have undo instead of a deleted status?

[caesarsgrunt]

I propose that this be committed without the undo feature, and I will then work on the undo feature afterwards, either with or without the ability to also undo other status changes. I think that would be simplest. Do you agree, or do you want me to add undo first?

[Denis-de-Bernardy]

Tried the patch. I like the approach in it, and I really fail to see the point in any kind of undo on top -- it seems it would only add clutter to the UI.

One small change I'd suggest, though: remove the confirmation js over in the drop down when doing a bulk delete, except when a permanent delete is happening. And change the text accordingly (i.e. You're about to permanently delete ...).

[caesarsgrunt]

Oh yes, I hadn't noticed that. I'll change it. Thanks for the input.

[caesarsgrunt]

Changes suggested by Denis, and a few others

[caesarsgrunt]

Right, I've fixed the things you mentioned, Denis.

I've also made it so that when spam comments are deleted they are permanently deleted, as mentioned above. Previously the "delete all" button did this, but the other delete options didn't. Now they all do.
I've also added a "permanently delete all" button for destroying all deleted comments, like the existing one for spam comments.

[caesarsgrunt]

Prompt when clicking "Permanently Delete All"

[azaozz]

The latest patch looks better but I think Westi has a very good point. The user experience and expectations have to be clarified first.

If we do follow the analogy with the Trash can in the OS, we don't need approve|edit|quick edit|spam on the deleted comments. They are deleted, no other actions apart from Delete Permanently and Empty Trash should be there.

Also imagine a blog with 200-300 users that delete 10-20 comments per week on average. Would make a huge number of cron tasks to go through... Having another date/time field in the db and one cron job per day sounds like a better option. The same job can do the delete for posts, pages, attachments, etc. too.

[caesarsgrunt]

If we remove "approve", there's no way to get them back out of the trash! That particular link needs to stay.
I sortof agree about about edit, and quick edit, but you could make the same arguments about comments in spam. Should these links be removed for them too?
As for spam, again, I sortof agree, and I did actually remove it at one stage... but email clients allow you to mark deleted comments as spam, so I put it back in to keep a similar interface.

I'll change the system for scheduling deletions, as you and Westi suggested.

[caesarsgrunt]

Alternatively, we could have "undelete" instead of "approve" - but then we should change the "approve" on spam comments to "not spam" as well.

[mrmist]

I have a couple of issues with patch version 7.

First thing, when I click on "Delete" (in the approve view for example) I am seeing the exact same warning dialogue as when I click "Delete permanently" (in the deleted view). I would not expect to see this dialogue unless I actually am about to delete the comment permanently.

Second thing, when I delete comments from the Pending view, the Pending count is going down, but the Deleted count does not go up. (In the headings.) Either both counts should change, or neither should.

[caesarsgrunt]

I don't get either of those problems.
Have you set SCRIPT_DEBUG? The patch won't work otherwise, since only the .dev.js versions of the js are modified (I presume the compressed versions will be modified when the patch is committed).

I am currently working on the changes to the scheduling system, and will upload a new patch shortly.

[mrmist]

Replying to caesarsgrunt:

I don't get either of those problems.
Have you set SCRIPT_DEBUG?

D'Oh.

Never mind. :)

[caesarsgrunt]

Ok, I've got a problem.

I've basically completed the system for scheduled deletions, and comments are scheduled and unscheduled for deletion correctly. It will be very simple to extend the system to work with posts, pages, etc.

But... I can't work out what file to put the actual function which is called by the wp-cron into. The code in need of a home is the following :

/**
 * Destroys comments which have previously been scheduled for destruction.
 * 
 * @access private
 * @since 2.9.0
 *
 * @return void
 */
function _scheduled_comment_destruction() {
	$to_destroy = get_option('to_destroy');
	if (!is_array($to_destroy))
		return;
	
	foreach ($to_destroy['comments'] as $comment_id => $timestamp) {
		if ($timestamp < time()) {
			wp_delete_comment($comment_id);
			unset($to_destroy['comments'][$comment_id]);
		}
	}
	
	update_option('to_destroy', $to_destroy);
}
add_action( '_scheduled_comment_destruction', '_scheduled_comment_destruction' );
if ( !wp_next_scheduled('_scheduled_comment_destruction') && !defined('WP_INSTALLING') )
	wp_schedule_event(time(), 'daily', '_scheduled_comment_destruction');

And I can't find a file in which the function is actually called by wp-cron (ie the file must be loaded whenever wp-cron runs) and has the ability to run the functions wp_next_scheduled() and wp_schedule_event() (ie wp-includes/cron.php must be loaded whenever the file in question is loaded).

Can anyone help me? Thanks...

[caesarsgrunt]

Ok, I've put it in wp-includes/pluggable.php for now. Don't think it's the ideal place, but it works and isn't comment-specific.
Patch coming soon.

[caesarsgrunt]

Better scheduled deletion

[caesarsgrunt]

Correctly unscedule deletion when using "Permanently Delete All" button

[caesarsgrunt]

What else needs to be done before this can be committed? Does anyone else have any issues with the interface or anything else?

I haven't added the undo feature, since there seemed to be no consensus on whether we should have it or not, but it will be very easy to add later. Likewise, I haven't removed the links which Azaozz mentioned, since there is disagreement about exactly what links are needed, but these can also be added later.

I am eager for this to be committed as soon as possible so that I can start working on extending this functionality to posts, pages, etc.

[Denis-de-Bernardy]

Replying to caesarsgrunt:

What else needs to be done before this can be committed?

In short, some level of consensus needs to be reached on the pending issues. I suggest you add this to the agenda for next week's meet-up:

​http://wpdevel.wordpress.com/2009/07/08/post-items-as-replies-to-suggest-agenda/

and that you hop onto the IRC chat: channel wordpress-dev on irc.freenode.com @ 9pm GMT next wednesday.

[westi]

Replying to caesarsgrunt:

What else needs to be done before this can be committed? Does anyone else have any issues with the interface or anything else?

As I said before we need to think about what user-experience we want before cutting/committing code.

I have added it to the agenda suggestions list for this week - ​http://wpdevel.wordpress.com/2009/07/08/post-items-as-replies-to-suggest-agenda/#comment-2868

[caesarsgrunt]

Hmm... not sure what "the pending issues" are, or what other issues there could be with the user experience - I guess I'll just have to wait and see what happens.

[caesarsgrunt]

slight change to enable an option for the length of time deleted comments should be kept to be added in the future

[Denis-de-Bernardy]

Key points of the discussion on IRC:

• default should be to autoclear trash, but with hooks available
• auto-delete needs to be based on how old and how big

[caesarsgrunt]

Sorry I wasn't around for the discussion.

• Hooks to do what exactly? Change the time before deletion? Why not just have an option in the discussion preferences?

• What is meant by "needs to be based on how old and how big"? It is already based on how old in my patch, but where does size come into it? Delete longer comments sooner? Why?

[caesarsgrunt]

Oh, I think I see (looking at the logs) - you mean delete after X (configurable) days and delete the oldest item in the trash when there are X (configurable) items in it?

[junsuijin]

Replying to caesarsgrunt:

Oh, I think I see (looking at the logs) - you mean delete after X (configurable) days and delete the oldest item in the trash when there are X (configurable) items in it?

That's the idea. X is only configurable by hooks, so as not to clutter the backend with extra options most won't need.

[azaozz]

Looking at delete-comment.10.diff:

• As "deleted" is a new comment_status we will need separate Trash Can for comments, posts, pages, etc. which differs from the OS Trash Can functionality (but may be acceptable).

• Currently the Undelete action is not very clear. For comments we have "Approve | Spam | Delete Permanently" and for posts, pages, attachments will probably have "Undelete (or Restore) | Delete Permanently".

• Don't think we need Edit and Quick Edit for deleted items. That's consistent with the OS Trash Can.

[junsuijin]

Replying to azaozz:

Looking at delete-comment.10.diff:

• As "deleted" is a new comment_status we will need separate Trash Can for comments, posts, pages, etc. which differs from the OS Trash Can functionality (but may be acceptable).

• Currently the Undelete action is not very clear. For comments we have "Approve | Spam | Delete Permanently" and for posts, pages, attachments will probably have "Undelete (or Restore) | Delete Permanently".

• Don't think we need Edit and Quick Edit for deleted items. That's consistent with the OS Trash Can.

From a UI perspective, multiple trash cans make sense for WP's different kinds of objects; however, there should only be a single top-level trash can menu (preferably below all the other top level menus), and clicking on the icon/menu name, would open up whatever item's trash is likely to be filled most often (e.g. comments), and/or the 'empty all trash cans' dialogue (in that case it might be most clear to users if tabs for each type of trash appear above the list of trashed items, similar to the plugin viewing options for recently active, etc.). All types of trash cans should be submenus of the main trash menu. In this case, the max-fill counts should apply to each can separately to avoid confusion.

When anything like a post is trashed, its comments need to also go into trash (not sure what the WP standard is for deletion of parent pages and how that affects child pages/attachments, etc. but those things need consideration as well). As azaozz mentioned, there is no need for quick edit, but perhaps it would be useful to have some sort of reassignment function for the orphans (otherwise where would undeleted comments go when their parent remains deleted). Such a reassignment feature might quickly become unwieldy with larger blogs, but perhaps by combining the post-slug guessing functions with some ajax auto-listing (like google search), it could be doable to have a field where the user can type the post slug to reassign 1 or multiple comment(s).

Otherwise, I think the other option is to disallow undeletion of deleted comments whose parents are still deleted, and then make a default behavior (or option) when undeleting posts that have comments, such that the post's comments are also restored. In that case, there needs to be some sort of indication that the user cannot undelete a given comment because they need to first undelete its parent post (a link to the parent post's trash location).

Lastly, if the ability to empty trash is going to remain (rather than just emptying by time/amount and allowing those values to be filtered), then there needs to be an 'empty all trashes' button, as well as 'empty this trash' buttons.

If all trash is to be combined into a single bin (which seems more confusing and messy than what I just described, even though what I just described seems somewhat confusing as well), then there obviously needs to be some way to distinguish the type of objects in trash (via labels / icons).

[caesarsgrunt]

I don't like the concept of a separate "trash" top level menu. I prefer the UI I have implemented in my patches, where "deleted" is just another status - that seems to make most sense to me. Anything else would seem odd and be hard to use, in my opinion.

I don't see the need for an "empty all trashes" button either - comments and posts (for example) are separate in almost all respects, and I don't see why they should be bunched together in this one respect.

I hadn't thought about deleting comments on posts which are deleted, but of course you are right that it would have to be done.
I think the best thing here would be simply to not show comments on deleted posts in the comments admin panel, and then when the post is actually destroyed, destroy the comments too.

[janeforshort]

Talked to Andrew about UI. I recommended changing "Deleted" to "Trash" b/c if it's still accessible to user, it is not really deleted. What we are doing is more in line with Trash in OS and Gmail. Also, when on the Trash screen, change action links to only have "Return to Pending | Delete Permanently" so user forced to move item out of trash before acting on it (approve, spam, edit, quick edit), again in line with existing Trash metaphor. Super excited about having this feature!

[azaozz]

(In [11731]) "Trash" status for comments, first run, props caesarsgrunt, see #4529

[azaozz]

Added the changes as recommended by Jane to delete-comment.10.diff. Perhaps we can also replace the "Permanently Delete All" button with "Empty Trash" primary button.

[caesarsgrunt]

Thanks Jane and Andrew. I'm really pleased to finally see this feature get into trunk.

I originally used the word to avoid the American-specific word Trash - but I agree that it ended up being confusing. But shouldn't we also change "delete" to "move top trash", to more accurately represent the action?

Also, there are a couple of inconsistencies now... firstly, why can I edit Spam but not Trash? Would it be better to remove the edit links from the spam too?
Secondly, Spam has an "Approve" link, while Trash has a "return to Pending" link. These should be consistent one way or the other - or perhaps both. Personally I'd go for "Not Spam" and "Undelete", both changing the status to Approved.

[azaozz]

Yes action "move to trash" together with Empty Trash button on that screen seem consistent.

The spam status is close to unapproved/pending and is usually set by a plugin. It's there so the user can "un-spam" false positives and it needs all default actions available. The trash status is a result from an used action after the user has decided what to do with that comment.

More importantly we have to decide what to do with the comments when a post is deleted. Perhaps can show them in the comments trash with greyed out "Return to Pending" action and add an explanation at the top that some comments cannot be recovered as the post they belong to is in the trash.

[caesarsgrunt]

I still think that the "undelete" or equivalent button should change the status to approved rather than pending.

I think when a post is moved to the trash its comments should be hidden altogether - so far as the user is concerned the post is gone, and the comments are now irrelevant. Then, when the post is permanently deleted, the comments should be too.

[caesarsgrunt]

Terminology changes

[caesarsgrunt]

Trash status for posts, first attempt...

[caesarsgrunt]

Here's a first attempt at extending the Trash feature to Posts and Pages. I think it works fine, though it has a few rough edges.

I haven't done anything about Comments on deleted Posts yet.

See also my previous patch (delete-comment.11.diff) for some changes to the terminology used for comments, as discussed.

[azaozz]

(In [11741]) "Trash" status for comments updates, props caesarsgrunt, see #4529

[azaozz]

Changed couple of names to make them a bit more semantic and moved the scheduled delete function to functions.php.

[caesarsgrunt]

Trash for posts and pages, revision 2

[caesarsgrunt]

Hides comments on posts which are in the trash.

[caesarsgrunt]

Comments on posts in the Trash are now hidden. This concept seems to me to work well.

We could make it so that they are shown on the list of comments specific to the deleted post (when you click the comment bubble next to a post) but not on the main comments list, but that would be more complex and possibly confusing.
It might be a good idea to add a note somewhere - eg above the comments trash - to the effect that comments are not shown on trashed posts, or that might not be necessary.

Unless there are any issues with the interface I think this is basically done now for posts and pages.

Should I extend it to media? And what about links? Personally I don't think trash for links is needed. It might be nice for media though.

[azaozz]

Looking at delete-post.3.diff:

• There's no "Quarantine" for comments, they are either pending, spam or deleted. Think that's confusing. The button text should probably be "Delete all spam" or possibly "Permanently delete all".

• Think it's acceptable to hide all comments on posts that are in the Trash but perhaps the user should be made aware that the comments will be deleted together with the post (currently that's not clear either).

• We probably can delete attachments the same way like posts but it would need a warning that if a post has direct link to this attachment, the link will break.

• There's a problem with parent/child settings: moving a post to the Trash could still keep it as parent for any attachments; deleting it would set them with parent = 0. The same won't work for pages. Moving a page to the Trash should probably reassign any children to the parent's parent if any or make them top level (or they will be inaccessible). Currently that's the case when permanently deleting a page. However if we do that when moving to Trash, restoring a parent will be problematic as it won't go back to the same place in the hierarchy.

There's also the question about not breaking plugins that add different post statuses.

[janeforshort]

For the action links in each row, let's use "Trash" vs "Move to Trash" (thinking about length and translation, and fact that we use "spam" instead of "mark as spam").

It would be nice if we could add a visual cue when something is trashed or deleted permanently, like the row being replaced with a colored row saying '# comments/posts/etc deleted. Click to restore/undo' or something. I think in the dev chat the consensus was that it wasn't a must-have as long as trash was accessible, but it would be a nice plus if it could be added.

This part about spam screen, not sure which part is patch and which part is akismet as dropping this comment in quickly rather than removing patch to check:
Am super confused by the "empty quarantine" button on spam screen. Does this just mean move to trash? Also, there's a "permanently delete all" button up next to the filter button, which a) makes it confuses which one to use to delete things, especially since we already have a bulk delete action (seriously, how many deletes do there need to be?) and b)if it's going to exist, needs to move away from the filter button, as it looks like an alternate button to act on the comments/pings dropdown.

If we're talking about moving to trash vs. skipping the trash step for spam, would rather add a move to trash option in the bulk menu (or just 'trash'), so the fact that it's different than directly deleting permanently is more clear.

[janeforshort]

Also, when I click delete permanently, it's still popping up the dialogue box to confirm. This should go away, the whole point of this feature is to get rid of that dialogue box.

[caesarsgrunt]

We could change "Empty Quarantine" to "Empty Spam" to go with "Empty Trash" - might be better than "Delete all Spam". Or "Delete all Spam" might be ok...
Regarding changing "Move to Trash" to "Trash", there is also an issue with "Return to Pending" and "Return to Drafts" - should they have the verb if the others don't, or is there a sensible way to shorten them too?

@janeforshort - the buttons are a bit confusing in the current trunk, partly because azaozz changed some of the ones at the top and not the ones at the bottom partly because I used the word Quarantine to refer to the Spam status when I shouldn't have done so. I'll clean it up a bit and remove the word "quarantine".
The button to empty the spam was already there so I just added a similar one to empty the trash. I agree that they should be further from the filter form. I'll move them both over slightly to make the gap the same each side.
Also, Akismet does add some buttons of its own and remove others, but I'm not sure exactly what it does. I'll try it with my latest patch. The Akismet plugin may end up needing a few tweaks too, though I don't know what the procedure for that is.

At present spam comments skip the trash when they are deleted, like Gmail and (I think) most email clients. This seems to me to make most sense. Hence the action link "Delete Permanently" rather than just "Delete". I don't think spam needs to be able to be moved to the trash, but am open to discussion on the issue.

I'll work on adding a notice with undo etc when the rest of this feature is completed and committed, since that part is non-essential.

Regarding removing the prompt on permanent deletion - do you mean that there should be no confirmation of permanent deletion at all?

@azaozz - I don't think this will break plugins which add different post statuses, but I suppose it could affect those which modify the interface significantly.

[caesarsgrunt]

I actually think the nicest way to separate the filter form from the delete and bulk actions would be to put it at the right hand side whilst keeping the rest at the left.

[caesarsgrunt]

Adds trash for Media and fixes/tweaks many other things...

[caesarsgrunt]

The latest patch adds trash for attachments and makes many if not all of the interface changes discussed above, including removing the javascript prompts and moving the Empty Spam and Empty Trash buttons away from the filter form a little, making the gap the same as between the bulk actions and the filter form. It would be quite nice to move the Empty buttons to the left of the filters, and put them together with the bulk actions, but that doesn't look good with Akismet (which adds another button next to Empty Spam, which would be separated from it if Empty Spam were moved).

What I haven't done in this patch is sort out the issue with deleting media which are used in posts, though of course nothing is done about that at the moment for deleted media anyway. Also, media which is in the trash will still show up in posts which it has already been added to (not sure what can be done about that, if anything).

I'm not exactly sure what the solution is to the thing about changing a page's hierachy when it is deleted and restoring it if it is undeleted... I haven't done anything about it.

[caesarsgrunt]

Many tweaks and refinements to all parts of the trash system, including remembering previous status and better separation of trash from ordinary deletion.

[azaozz]

In [11749] Fixed couple of small bugs on the attachments trash page. All seems to be working well, now bugs/regressions hunting begins. Still needs some visual refinement like the red background when moving comments to the trash should probably be replaced with fade-out, etc.

The idea to replace the deleted row with a message letting the user to restore it and fading out after 15 sec. can be done with a hidden div.

Also replaced "Remove from Trash" with "Restore". This seems better as now we restore all to the previous status.

[azaozz]

(In [11750]) Trash status update, see #4529

[mrmist]

Currently the trash view and the "Empty Trash" button are visible for contributors and authors for both posts and comments.

There's a few issues. Firsly, I don't think the button should appear for contributors at all, because there's no purpose to it.

Secondly, if it does appear for some reason, the behaviour should be consistent. Currently for comments it just refreshes the view, and for posts it gives a wp_die "you can't delete this post" message, which is fairly harsh.

Lastly, for authors, if they "Empty Trash" when posts other than their own are in the list, they also get the wp_die error *and* their post is not deleted.

So the attached patch (emptytrash.patch) assumes that we don't show the Empty Trash button unless the viewer has the capability to manage the entire section.

It checks against edit_others_posts for posts and moderate_comments for comments.

[mrmist]

Show emtpy trash button only when people can do so.

[mrmist]

Fix for notices in edit-pages

[mrmist]

Attached edit-pages.diff which fixes a few notices.

[azaozz]

(In [11778]) Show Empty Trash button only when the user has cap. props mrmist, see #4529

[azaozz]

(In [11779]) Notice fixes, props mrmist, see #4529

[Viper007Bond]

Fix a notice on the edit comment screen

[westi]

Fixed a Notice in [11793].

Still get this when trying to trash a comment from the idividual comment view.

Notice: Undefined index: dt in /Applications/MAMP/htdocs/wordpress-trunk/wp-admin/comment.php on line 154

[automattor]

(In [11807]) Fix bulk edit, some cleanup and message fixes for moving in/out of the trash, see #4529

[caesarsgrunt]

Mostly permissions fixes, and fix for bug mentioned by Westi.

[caesarsgrunt]

Sorry to have been out of touch for so long... trash-fixes.diff contains some more permissions fixes, a fix for Westi's error, and a few other slight tweaks and fixes made over the last few days. Diff is against 11807.

[caesarsgrunt]

Any chance of committing the fixes in trash-fixes.diff?

[azaozz]

Not sure we need the capabilities changes in the last patch. When a post has 'trash' status, it's not published any more and it doesn't make a difference if it used to be published or not.

The 'trash' status seems close to the 'draft' status (post is not displayed on the front-end, etc.) and should have the same cap checks as when deleting a post. Once a post is in the trash it is 'unpublished' and the cap check can be the same as when deleting a draft (i.e. no changes are needed in capabilities.php).

[azaozz]

(In [11841]) "Trash" updates, props caesarsgrunt, see #4529

[caesarsgrunt]

Without those fixes it is possible for a post by a contributor to be re-published by that contributor (ie moved from 'trash' to 'published'), when a contributor would not normally be able to publish a post.

[azaozz]

(In [11873]) Don't let contributors to re-publish their trashed posts, props caesarsgrunt, see #4529

[westi]

Can we please find a better place to store the things being stored in the big wp_trash_meta option.

That is a nasty race condition waiting too happen once you introduce a high volume multi user site with an object cache into the mix.

I guess this hi-lights the need for a generic meta storage mechanism.

[westi]

(In [11878]) Move the storage of the metadata for trashed posts into the post meta table rather than storing it in an option. See #4529.

[westi]

That handles posts/pages moving the metadata somewhere better.

Still need to do the same for comments.

[azaozz]

(In [11880]) Fix returning to the previous post_status when restoring posts from the trash, see #4529

[westi]

Once #2659 is done we will move the comment stuff into comment meta

[caesarsgrunt]

Replying to westi:

Once #2659 is done we will move the comment stuff into comment meta

Yeah; I also thought that would be best. But that ticket is three years old... is it going to be done soon?

[dd32]

Yeah; I also thought that would be best. But that ticket is three years old... is it going to be done soon?

Yes. As mentioned in the last comment on that ticket, it'll happen for 2.9

[westi]

(In [11945]) Move the storage of the metadata for trashed comments into the comment meta table rather than storing it in an option. See #4529.

[westi]

(In [11947]) Remove temporary transition code from the trash_meta option to postmeta transition See #4529.

[mrmist]

There is a small issue with the bulk edits (which applies to more views than just trash but is applicable here) in that whenever you perform a bulk activity within edit posts, you are returned to the All view afterwards, even if posts remain in the view you were watching before. It'd be better if you were left on, say, the Trash view after doing a bulk option on some posts.

[pavelevap]

Hello, is it possible to move post to trash and then post will not be visible on homepage, but URL of this post will work (for example for people which have this post in their bookmarks, etc)?

[dd32]

but URL of this post will work (for example for people which have this post in their bookmarks, etc)?

No, Once its trashed, Its gone from public view. The trash system just gives you a place for content to go after its been deleted.

[caesarsgrunt]

Undo for trashing of comments.

[caesarsgrunt]

Latest patch contains the undo feature discussed previously, as well as a few minor fixes.

[caesarsgrunt]

Perhaps someone could have a look at the latest patch and give feedback - in particular, UI feedback from Jane would be useful.

Also, there is currently a bug where restoring one comment deletes the trash meta for all other comments. This prevents automatic permanent deletion and means that any other restores comments will be moderated.
I think this is probably a bug with the comment meta mechanism.

[westi]

(In [11992]) Delete the trash metadata when untrashing a comment. See #4529 props caesarsgrunt.

[westi]

Have committed part of the patch for now so we actually delete the trash meta data for comments when they are untrashed.

Rest of the patch needs reviewing still.

[azaozz]

(In [11997]) Add conditional to handle get_comment_meta() return value, make #comment_id required arg for wp_trash_comment() and wp_untrash_comment(), see #4529

[azaozz]

(In [12008]) Add Undo when moving comments to the trash, remove unneeded nonces, see #4529

[caesarsgrunt]

Well, I haven't looked at the code yet so I don't know how much of my code was used, but in terms of the interface I infinitely preferred my version to what you've done...

[caesarsgrunt]

Alright, I'll be more specific...

Your transitions don't work... it looks clumsy the way everything jumps around, wheras mine just faded the comment out and the notice in with no jumping.

My fade through red when trashing and green when untrashing reinforced the action, whereas the current colouring is a bit weird.

The idea of putting the gravatar in is interesting, but it doesn't work where you've put it.

I do like the way it now shows the comment author.

I think that's it...

[azaozz]

Most differences are in "handling" the process. For example we don't need to generate and check 6 different nonces for each comment, no extra code in wp-lists.js as it's loaded in many places, multiple Undo notices can be shown simultaneously, keyboard shortcuts work, etc.

Tried putting the gravatar on the left in the Undo notice but that made it look almost like another comment. It can easily be moved if needed. The first animation can be jumpy in some browsers, need to queue it properly.

[caesarsgrunt]

The main problem with the animation is that the notice is shown before the comment is faded out, resulting in everything jumpin down and then up again when the comment has faded out.

With mine, the comment faded to red, then was replaced by the notice which faded from red. The only jump was the change in height when the comment became the notice, which wasn't really noticeable.

[azaozz]

Replying to caesarsgrunt:

The main problem with the animation is that the notice is shown before the comment is faded out...

Exactly, needs to be queued to start after the "fade to red" one ends. I'll do this a bit later if you don't beat me to it :-)

[caesarsgrunt]

Great. I'm afraid I won't be able to beat you to it; I'm going offline now for the next few days...

[automattor]

(In [12050]) Smoooth animations for comment move to trash and undo, see #4529

[caesarsgrunt]

Various small nonce fixes, for things broken by azaozz's nonce merge.

[caesarsgrunt]

Any chance of committing my fixes in the patch of last week? Then I'll get on with implementing undo in other areas.

[azaozz]

(In [12113]) Fix trashing/untrashing comments when no JS, props caesarsgrunt, see #4529

[ryan]

(In [12116]) Remove slow left join pending better solution. see #4529

[ryan]

(In [12120]) Schedule trash collection from admin page loads. see #4529

[caesarsgrunt]

Undo for trashing of posts, pages, and media.

[caesarsgrunt]

Latest patch contains Undo for posts, pages, and media. When it has been committed I'll see if I can sort out undo for trashing from the upload dialogue, which would be one of the most useful places for undo.

[aaroncampbell]

In [12116] shouldn't $where = ''; still be $where = 'WHERE ';? It looks like right now the query would be invalid.

[azaozz]

(In [12121]) Undo for posts, pages and media, props caesarsgrunt, see #4529

[aaroncampbell]

Fix possible bad query introduced in r12116

[azaozz]

(In [12122]) Fix possible bad query, props aaroncampbell, see #4529

[caesarsgrunt]

Undo in the upload and gallery dialogs.

[caesarsgrunt]

Latest patch fully implements undo for the media upload and gallery pages.

[azaozz]

(In [12130]) Trash undo for the uploader, props caesarsgrunt, see #4529

[caesarsgrunt]

I think it would be better if the undo notice - particularly in the upload page, but also everywhere else - also gave the option to permanently delete the item.

So the message would read something like
N nouns moved to the trash. Undo / Delete Permanently

What does anyone else think of this idea? Any arguments against it?
Otherwise I'll implement it when I get time.

[azaozz]

(In [12154]) Fix Undo row timeout on Edit Comments screen, props caesarsgrunt, see #4529

[caesarsgrunt]

Remove all instances of "Trash" from the interface when Trash is disabled.

[caesarsgrunt]

Latest patch fixes interface when Trash is disabled, removing all confusing Trash references and replacing the "Trash" action links with "Delete Permanently".

[azaozz]

(In [12162]) Remove all instances of "Trash" from the UI when Trash is disabled, replace trash actions with "Delete permanently", props caesarsgrunt, see #4529

[caesarsgrunt]

Latest patch contains overall standardisation of the look, feel, and behaviour across the different parts of WordPress - comments, media, etc.

Additionally, the patch changes the behaviour do that only one undo notice is visible at a time and they are all hidden when replying to or quick editing a comment (as discussed on IRC).

[lloydbudd]

Related new tickets:

#11259 Undo should not fade, instead it should update status

#11260 Should be able to undo "Marking [comment] as Spam"

[caesarsgrunt]

Alternative to 4529-tweaks.diff

[caesarsgrunt]

4529-tweaks-alt.diff is an alternative to 4529-tweaks.diff.

Instead of making all notices fade out as soon as a new one is displayed, it makes no notice ever fade out (consistent with other notices across WP).

All other tweaks are the same in both patches.

Please commit one or other; not both!

[azaozz]

(In [12278]) Stop the fade-out of the Undo notices on Edit Comments screen, props caesarsgrunt, fixes #11259, see #4529

[azaozz]

Removed the dark pink background for now (#ffc0c0), as it feels too overpowering. If we add undo for spam, we would probably need different background colors for the trash undo and spam undo. Maybe light pink and light green (light blue is used when moderating comments with the keyboard).

[azaozz]

(In [12286]) Undo for setting a comment as spam, props caesarsgrunt, fixes #11260, see #4529

[azaozz]

Changed the patch in #11260 a bit: wp_trash_comment, wp_untrash_comment, wp_spam_comment and wp_unspam_comment return false if the comment status was not changed.

[caesarsgrunt]

Updated version of 4529-colors.diff

[caesarsgrunt]

Improved version doesn't make entire media details go red.

[caesarsgrunt]

4529-colors.2.diff is an tweaked version of 4529-colors.diff. It contains the following changes from trunk :

• fade thru green when untrashing, to match fade thru red when trashing
• make media trash notice whit, to match comment trash notice
• fade thru red when trashing media, to match comments

in version 2, only the title of the media fades thru red, rather than the whole details table.

4529-fixes.diff contains the following changes from trunk :

• change wp_untrash_comment() to call wp_set_comment_status(), for back-compat
• fix a notice on wp-admin/upload.php

[nacin]

Can we change the space in "Delete Permanently" to   to bring it in line with Quick Edit and prevent wrapping?

[caesarsgrunt]

Updated patch also adds   to Delete Permenantly

[azaozz]

(In [12289]) Flash through red when sending an item to the trash, flash through green when undoing it, props caesarsgrunt, see #4529

[azaozz]

(In [12290]) "Trash" fixes, props caesarsgrunt, see #4529

[nacin]

The red flash-through doesn't appear to be committed. Also, green (#6c6) seems a bit dark, maybe something lighter? #ceb is used when a comment is approved -- maybe not the best idea as it is the same as approved, but an option.

[caesarsgrunt]

Replying to nacin:

The red flash-through doesn't appear to be committed. Also, green (#6c6) seems a bit dark, maybe something lighter? #ceb is used when a comment is approved -- maybe not the best idea as it is the same as approved, but an option.

Red flash is working fine for me, except on unapproved comments. This was already the case (red flash isn't new; just green). It does need fixing, but that's probably for another ticket.

I agree that the green is a little dark. I haven't seen a green when approving, though - for me it flashes grey when approving. However, I don't really see any reason why the green shouldn't be the same if we did use green for both approve and undo.

[caesarsgrunt]

Less bright colour fades for trash and untrash, and make undo notice pale grey.

[caesarsgrunt]

4529-colors.3.diff

• Makes the colour flashes for trash and untrash less bright; at #fbb and #ceb respectively.

• Makes the colour flash work on unapproved comments too.

• Makes the undo notice grey - #f4f4f4 - to differentiate it from ordinary comments.

[caesarsgrunt]

Same as 4529-colors.3.diff, but doesn't break unapproved color in IE6/7.

[azaozz]

(In [12291]) Tweak colors for trash, spam and undo of comments, fix IE6/7 background for unapproved comments, fix JS error in IE6/7, props caesarsgrunt, see #4529

[husobj]

Testing latest trunk version (revision 12294)

I have 2 posts in trash.
If I permanently delete 1, the message "Post permanently deleted." is displayed.

If I then immediately restore the other one, the message displays "Post permanently deleted.Post restored from the trash."

The previous message is not replaced, just added to.

[caesarsgrunt]

Oops; fixed that previously for comments but not for posts. I'll upload a patch later.

[caesarsgrunt]

Fix notices for posts and pages.

[caesarsgrunt]

4529-notices.diff fixes the issue described by husobj, and similar problems with the notices in other situations.

[azaozz]

In [12312], Fix multiple confirmation messages when restoring posts and pages from the trash, props caesarsgrunt, see #4529

[markjaquith]

Let's open tickets for any remaining issues. I think we're looking pretty good.

[hakre]

no question / trash for post tags. is that right or you want tickets for missing features as well?

[caesarsgrunt]

Yes, open a new ticket if you think it should be added. Personally I don´t think tags or categories need trash.