WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 21 months ago

#16003 closed enhancement (fixed)

XMLRPC should use category ids instead of names

Reported by: koke Owned by: ericmann
Milestone: 3.4 Priority: normal
Severity: normal Version: 3.1
Component: XML-RPC Keywords: has-patch needs-testing mobile
Focuses: Cc:

Description

You can have categories with the same name at different points in the hierarchy.

Right now, metaWeblog.getPost, metaWeblog.getRecentPosts, and metaWeblog.newPost at least return/take an array of category names.

Names are probably more useful in most of the cases, but not being able to use the ids can lead into trouble

Attachments (2)

wp_category_ids.diff (1.6 KB) - added by ericmann 3 years ago.
Adds support for using an array of category IDs.
wp_category_ids-2.diff (2.1 KB) - added by ericmann 3 years ago.
New patch sends/receives category IDs as ints rather than strings.

Download all attachments as: .zip

Change History (11)

comment:1 follow-up: westi3 years ago

If we want to change this we need to create new functions in the wp namespace that use IDs

comment:2 in reply to: ↑ 1 ericmann3 years ago

  • Component changed from General to XML-RPC
  • Type changed from defect (bug) to enhancement

Replying to westi:

If we want to change this we need to create new functions in the wp namespace that use IDs

I agree. Let's not change the existing API (several third party applications already depend on it working as documented) but create wp_ analogue methods. I'm open to taking ownership of this if no one else is interested ...

comment:3 follow-up: josephscott3 years ago

  • Cc josephscott added

Accepting category IDs seems like a reasonable thing to do. Don't know why we couldn't just allow metaWeblog.newPost and friends to grow support for that using a new field. category_ids ?

comment:4 in reply to: ↑ 3 ericmann3 years ago

Replying to josephscott:

allow metaWeblog.newPost and friends to grow support for that using a new field. category_ids ?

That seems like a fair compromise, and would be easier to implement than creating a full set of new methods.

The complexity comes in if a user specifies both categories by name and categories by ID ... would we accept only one over the other? Accept and filter on both?

And would we return both categories and category_ids as arrays with similar information?

ericmann3 years ago

Adds support for using an array of category IDs.

comment:5 ericmann3 years ago

  • Keywords has-patch needs-testing added
  • Owner set to ericmann
  • Status changed from new to assigned

A quick look at the code shows we're already fetching an array of category IDs while performing metaWeblog.getPost and metaWeblog.getRecentPosts, so I've added a return parameter called wp_category_ids that just adds this array to the XML-RPC response for those two requests.

For metaWeblog.newPost, you can send an array of category IDs in the parameter wp_category_ids. The code will first create an empty array, then fill it with the IDs of any named categories sent the old way (this was existing code) and add in any IDs sent in the new parameter. So, you could actually send some categories as named values and some as just their IDs, and WordPress will map the entire group to a single array of IDs.

comment:6 follow-up: mdawaffe3 years ago

  • Milestone changed from Awaiting Review to Future Release

The $catids should be sent and received as ints, not strings. As ints, you won't need to verify that the IDs correspond to actual categories.

comment:7 in reply to: ↑ 6 ericmann3 years ago

Replying to mdawaffe:

The $catids should be sent and received as ints, not strings.

Fair enough, and something I didn't think of the first time 'round. New patch uses array_map to convert the $catids to an array of ints before sending/persisting.

I've also added the ability to send categories by ID to metaWeblog.editPost (if you can set them with newPost you should be able to edit them with editPost).

ericmann3 years ago

New patch sends/receives category IDs as ints rather than strings.

comment:8 koke3 years ago

  • Keywords mobile added

comment:9 markoheijnen21 months ago

  • Milestone changed from Future Release to 3.4
  • Resolution set to fixed
  • Status changed from assigned to closed

Resolved it since the wp.* methods now able to handle this

Note: See TracTickets for help on using tickets.