Make WordPress Core

Opened 9 years ago

Last modified 2 years ago

#30775 reopened defect (bug)

Delete empty post problem

Reported by: axdr's profile axdr Owned by: wonderboymusic's profile wonderboymusic
Milestone: Priority: normal
Severity: normal Version: 3.3
Component: Posts, Post Types Keywords: has-patch dev-feedback
Focuses: Cc:

Description

If empty post was created it cannot be deleted

Details are here http://arul.ru/pages/writings/delete_post_problem.htm

Attachments (3)

30775.diff (682 bytes) - added by wonderboymusic 9 years ago.
30775.2.diff (511 bytes) - added by DrewAPicture 8 years ago.
post.php.patch (590 bytes) - added by Ninos Ego 8 years ago.

Download all attachments as: .zip

Change History (17)

#1 @nacin
9 years ago

Hi axdr, in the future, please use your bug report to document your bug. Over the years, single-use web pages like this have gone missing — I have seen it dozens of times.


19 Dec 2014 Wordpress v4.1
Delete empty post problem

To see the problem, follow the steps below:
Enter the Dashboard
Install bad-plugin and activate it
Select command 'Add new' in 'Posts'-submenu and then press 'Safe Draft'.
After this you will see an empty post you have created on the Posts-page.

Without bad_plugin you cannot create such a post. But now you can.

Perhaps you do not understand where it is from. You remember the last change in your Wordpress was the bad_plugin. And you delete it with no doubt.

And here is the Problem: You cannot delete your empty post

Why cannot?

Open wp-includes/post.php in Editor.

See the marked line where wp_insert_post($post) is called. The matter is that wp_insert_post returns 0 but wp_trash_post knows nothing about it.

What to do?

Admin should be able to delete any post.

Wp_trash_post does not need to call wp_insert_post with all its checking and only has to change post_status desplite post's incorrectness. There should be no requirement to the post intended to be deleted.

The return from trash should be the same because no one is able to correct a trashed post.

PS: Smart minds can offer another plugin as a cure. But I think that is the wrong way.


Bad plugin:

add_filter('wp_insert_post_empty_content', 'the_bug', 10, 2);
function the_bug($maybe_empty, $postarr) {
  return false;
}

#2 @nacin
9 years ago

  • Component changed from Administration to Posts, Post Types
  • Version changed from 4.1 to 3.3

This is an interesting bug! Definitely not new. But I'd wonder why your plugin allows the post to be saved, but not to be trashed?

#3 @axdr
9 years ago

It allows while it's active. But it doesn't matter.
Thanks for help. Next time I'll do all correct.

#4 @tmoitie1
9 years ago

I've got this problem - Advanced Custom Fields is overriding this filter in order to post and has created a lot of untrashable posts:

	/*
	*  wp_insert_post_empty_content
	*
	*  This function will allow WP to insert a new post without title / content if ACF data exists
	*
	*  @type	function
	*  @date	16/07/2014
	*  @since	5.0.1
	*
	*  @param	$maybe_empty (bool) whether the post should be considered "empty"
	*  @param	$postarr (array) Array of post data
	*  @return	$maybe_empty
	*/
	
	function wp_insert_post_empty_content( $maybe_empty, $postarr ) {
		
		if( $maybe_empty && !empty($_POST['_acfchanged']) ) {
			
			$maybe_empty = false;
			
		}

		
		// return
		return $maybe_empty;
	}

Whilst this example is probably a bug of ACF, I think that WordPress should be able to delete any posts independently of validation rules defining how they should be created or updated.

@wonderboymusic
9 years ago

#5 @wonderboymusic
9 years ago

  • Keywords has-patch added
  • Milestone changed from Awaiting Review to 4.4

Can we skip this check when $update is true? Patch attached.

#6 @wonderboymusic
8 years ago

  • Owner set to boonebgorges
  • Status changed from new to assigned

code review

@DrewAPicture
8 years ago

#7 @DrewAPicture
8 years ago

  • Keywords dev-feedback added
  • Owner changed from boonebgorges to wonderboymusic

@wonderboymusic: In my testing 30775.diff fixes the issue and seems logical. As an alternative, I've attached 30775.2.diff, which moves the ! $update check to the conditionals list for $maybe_empty.

Seems like if anybody is doing something interesting with the filter, that might be a better choice to combine it.

#8 @wonderboymusic
8 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 35621:

Posts: allow empty posts to be deleted - $maybe_empty should not be set to true for updates.

Props DrewAPicture.
Fixes #30775.

#9 @wonderboymusic
8 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

#10 @wonderboymusic
8 years ago

  • Milestone changed from 4.4 to Future Release

#11 @wonderboymusic
8 years ago

In 35623:

Revert [35621], breaks XML-RPC unit tests.

See #30775.

#12 @ocean90
8 years ago

#37027 was marked as a duplicate.

@Ninos Ego
8 years ago

#13 @Ninos Ego
8 years ago

I have uploaded another solution / patch, if you want to allow editing post with empty entries just if status is not going to publish (publish, future, pending...).

For me the update check does not make much sense because otherwise it's possible to empty the title, content and excerpt in a later state. If it should be allowed, then previous patches are fine :D

#14 @anthonyeden
2 years ago

I wonder if it's possible to get some more eyes on this one? I don't know the full implications of the suggested patch, but I do know it's confusing when a user can't delete an empty post (no title, body, excerpt).

Note: See TracTickets for help on using tickets.