[wp-trac] [WordPress Trac] #4529: "Trash" status for comments and posts

[WordPress Trac]

#4529: "Trash" status for comments and posts
----------------------------+-----------------------------------------------
 Reporter:  markjaquith     |       Owner:  caesarsgrunt
     Type:  task (blessed)  |      Status:  accepted    
 Priority:  normal          |   Milestone:  2.9         
Component:  Administration  |     Version:              
 Severity:  normal          |    Keywords:  has-patch   
----------------------------+-----------------------------------------------

Comment(by junsuijin):

 Replying to [comment:49 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).

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/4529#comment:50>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software