WordPress.org

Make WordPress Core

Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#22220 closed defect (bug) (fixed)

XML-RPC wp.editPost clears post categories

Reported by: yousefed Owned by: westi
Milestone: 3.5 Priority: normal
Severity: normal Version:
Component: XML-RPC Keywords: has-patch commit
Focuses: Cc:

Description

According to http://codex.wordpress.org/XML-RPC_WordPress_API/Posts#wp.editPost

"Only needs to contain fields that you wish to modify; all other fields will retain their current values."

When I only post custom_fields to update the custom fields of a post (custom post type by the way, didn't check for normal posts) the categories of the post are removed (now "Unassigned").

I think the source of the problem might be the following part in wp_insert_post:

// Make sure we set a valid category.
	if ( empty($post_category) || 0 == count($post_category) || !is_array($post_category) ) {
		// 'post' requires at least one category.
		if ( 'post' == $post_type && 'auto-draft' != $post_status )
			$post_category = array( get_option('default_category') );
		else
			$post_category = array();
	}

Attachments (1)

22220.diff (597 bytes) - added by nacin 2 years ago.

Download all attachments as: .zip

Change History (17)

comment:1 @markoheijnen2 years ago

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

You are using the build in taxonomy "Category" or are you using a custom taxonomy?

Maybe this is related: #19954?

comment:2 @yousefed2 years ago

Seems somewhat related, but the patch won't fix the issue for non-'post' post types

Version 0, edited 2 years ago by yousefed (next)

comment:3 @markoheijnen2 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from assigned to closed

I close this as duplicate. Since it is the same issue as #19954. The patch I wrote doesn't seem to fix it properly then.
I will start writing unit tests for it and hopefully this can be fixed in 3.5

comment:4 @yousefed2 years ago

My apologies, I retried and the patch from #19954 does seem to resolve the issue. Thanks.

comment:5 @SergeyBiryukov2 years ago

  • Component changed from General to XML-RPC

comment:6 @nacin2 years ago

  • Milestone set to 3.5
  • Resolution duplicate deleted
  • Status changed from closed to reopened

A switch to wp_update_post would be sufficient to fix XML-RPC.

comment:7 follow-up: @nacin2 years ago

What are we doing here? I don't know how feasible it is to switch the _insert_post() method to wp_update_post(). This needs unit tests, I gather.

comment:8 @MikeHansenMe2 years ago

  • Keywords needs-unit-tests added

comment:9 in reply to: ↑ 7 @westi2 years ago

  • Keywords needs-patch punt added

Replying to nacin:

What are we doing here? I don't know how feasible it is to switch the _insert_post() method to wp_update_post(). This needs unit tests, I gather.

We definitely need some tests to cover this agreed.

I also think that we should maybe make _insert_post() work differently for new/editing as we should be using wp_update_post when editing for sure.

@nacin2 years ago

comment:10 follow-up: @nacin2 years ago

  • Keywords has-patch added; needs-patch removed

comment:11 in reply to: ↑ 10 @westi2 years ago

Replying to nacin:

Thanks, I guess we just need the requisite tests now ;)

comment:12 follow-up: @nacin2 years ago

  • Keywords commit added; needs-unit-tests punt removed
  • Owner changed from markoheijnen to westi
  • Status changed from reopened to assigned

Basic unit test in [UT1133].

comment:13 in reply to: ↑ 12 @westi2 years ago

Replying to nacin:

Basic unit test in [UT1133].

Fixed up in [UT1137] as it was broken.

comment:14 @westi2 years ago

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

In 22584:

XMLRPC: When Editing an existing post make sure to use wp_update_post instead of wp_insert_post so as to not perform destructive actions on the content.

The wp.EditPost() API will accept very limited data to only edit specific attributes of a post, if you didn't supply a category change then we would previously
overwrite the original categories with the default cat.

Fixes #22220 props nacin.

comment:15 @nacin2 years ago

The check for IXR_Error makes sense, but I can't reproduce "Previously the test created a post that the test user couldn't edit and so the Post Editing failed." [UT1137] The user was an editor and should have been able to modify any post. The test passed for me (with patch applied), which included the updating of the post title. Perhaps something to look into your local copy of the tests.

comment:16 @nacin2 years ago

Seems that only occurs when the test suite is run as a whole.

Note: See TracTickets for help on using tickets.