Make WordPress Core

Opened 16 years ago

Closed 16 years ago

#5569 closed enhancement (fixed)

Manage post_status via XML-RPC

Reported by: josephscott's profile josephscott Owned by: westi's profile westi
Milestone: 2.5 Priority: normal
Severity: normal Version: 2.5
Component: XML-RPC Keywords: has-patch
Focuses: Cc:


The post_status field is now exposed via XML-RPC methods, we need a way to set it as well. To that end this ticket addresses the following items:

  • Hide the 'future' post_status from posts, expose them as 'publish' instead
  • Look for a 'post_status' field in metaWeblog.newPost and metaWeblog.editPost and use it, overriding the publish argument
  • Add new wp.getPostStatusList and wp.getPageStatusList methods

The future post_status is an internal status only, so to make sure that clients don't get confused by posts that have a status of 'future' by sending it as published. This matches what a user would see for a future post in wp-admin.

If we find a 'post_status' field in metaWeblog.newPost or metaWeblog.editPost then check that has a value of 'draft', 'private', 'publish', 'pending' and if so then override the publish argument with the value in the 'post_status' field. We do the same thing for pages, with the exception that 'pending' isn't a valid status for a page.

Clients need a way to know what the valid statuses are for posts and pages, so wp.getPostStatusList and wp.getPageStatusList each return an array, with each item in the array being a valid post_status.

Attachments (5)

xmlrpc.php.diff (4.0 KB) - added by josephscott 16 years ago.
post.php.diff (1.3 KB) - added by josephscott 16 years ago.
edit-form-advanced.php.diff (2.0 KB) - added by josephscott 16 years ago.
edit-page-form.php.diff (1.7 KB) - added by josephscott 16 years ago.
xmlrpc.php.2.diff (1.7 KB) - added by josephscott 16 years ago.

Download all attachments as: .zip

Change History (13)

#1 @westi
16 years ago

  • Owner changed from anonymous to westi
  • Status changed from new to assigned

Looks good.


  • The arrays returned should be passed through a filter to allow a plugin to expose extra post_statuses.
  • we also need a way for a plugin to handle these added states when they come in through xmlrpc - I guess we need to pass $post_status through a filter passing the incoming status as an extra argument.

#2 @josephscott
16 years ago

I've updated the patch to make use of two new core functions, get_post_statuses() and get_page_statuses(). In addition I've updated the wp-admin write post and write page forms to make use of these functions as well, instead of hard coding the values as they were before.

I did not add filtering abilities of post/page statuses because right now the post_status field in database is an ENUM, so it currently won't accept any other values that what the schema defines. If/when that is changed then we could add filtering features.

#3 follow-up: @josephscott
16 years ago

Since wp-admin is still in state of flux can we commit just the xmlrpc.php and post.php diffs?

#4 in reply to: ↑ 3 @westi
16 years ago

Replying to josephscott:

Since wp-admin is still in state of flux can we commit just the xmlrpc.php and post.php diffs?

We can.

However at present the combination of these patches plus the ones for the admin pages will not translate correctly.

You can only pass strings to __('') and friends not variables.

#5 @westi
16 years ago

(In [6594]) Add xmlrpc methods to discover the valid post and page statuses. See #5569 props josephscott.

#6 @josephscott
16 years ago

While testing this after it was committed I realized that setting status for pages would end up being done by a field called post_status, which didn't make much sense because the status for pages was being exposed as page_status in other methods. The new xmlrpc.php.2.diff makes use of the post_type to determine if we need to look at post_status or page_status when setting the status value when creating and editing posts and pages.

#7 @westi
16 years ago

(In [6596]) Better xmlrpc field names. See #5569 props josephscott.

#8 @josephscott
16 years ago

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

This has been committed, I don't think there is any reason to leave this ticket open.

Note: See TracTickets for help on using tickets.