id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc
11470	Have wp_delete_comment trash/delete the same way as its post and attachment counterparts	nacin		"In 2.8, if a plugin wanted to delete a post, it called wp_delete_post($id).

No more. Now, that simply calls wp_trash_post($id) and sends the post to the trash. You need to call wp_delete_post($id, true) to delete a post now, as in 2.9 the function is now {{{wp_delete_post( $id, $force_delete = false )}}}.

Since wp_trash_post() exists, then wp_delete_post() should do what it has always done -- delete the post. If a plugin wanted a post to be trashed, they can use wp_trash_post().

After [https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2009-12-17#m45393 an IRC discussion with azaozz], it appears intended to widen the scope of the Trash. But they're separate and equal functions and should perform their own actions.  These should be standard across the board else the Trash API gets confusing. Otherwise, we have two functions, designed to perform two different actions, peforming the same action by default, which is counter-intuitive.

$force_delete also introduces consistency issues with 3.0. With media trash in core as expected, there will be wp_trash_attachment(). But wp_delete_attachment() has that same $force_delete = false argument that wp_delete_post() now has.

Suggested fix:
 - Remove $force_delete arguments from wp_delete_post() and wp_delete_attachment().
 - Remove wp_trash_post() call from wp_delete_post().
 - Create wp_trash_attachment() -- better to standardize it now than to have a single function with $force_delete later when this whole API likely becomes wider functions with some wrappers.
 - Remove trash actions from wp_delete_attachment().
 - Go through core references of wp_delete_post() and wp_delete_attachment() and modify them as appropriate."	defect (bug)	closed	normal	3.0	Trash	2.9	normal	fixed	has-patch	ceasarsgrunt raven@… caesar@… sirzooro