The WordPress XML-RPC (Ticket) Hit List

After half a year of complaining about the state of XML-RPC in WordPress, I’ve tried to get the stars aligned for some significant improvements in the next release (3.4). The 3.4 development cycle has just begun after the release of 3.3 last week, and I am currently on winter break until spring semester classes start on January 9. Some of the core developers have shown interest in seeing XML-RPC improved, so I hope to make their job easier by doing the legwork on patches.

As of today (12/22/2011), there are 72 open tickets in the WordPress core Trac XML-RPC component. While I’d love to see them all fixed, there is limited amount of time and so we must prioritize. This post represents my current priorities and plans.

GSoC Project

The first area of focus will be refining the work from the WordPress Web Services 2011 Google Summer of Code project, which resulted in the wp-webservices plugin. These new methods expand the wp.* method namespace and deprecate the usage of metaWeblog/MT/Blogger API methods for common tasks.

I’ll first release a new plugin based on wp-webservices but with updated implementations. The goal is to allow people to test the new methods on 3.3 or earlier, and to make it easier than applying two dozen patches against trunk. I’ll also have a new branch of python-wordpress-xmlrpc that can talk to the new methods.

Ticket # Type Method Priority
18433 Posts wp.getPosts 0
18432 wp.getPost 2
18430 wp.editPost 2
18431 wp.deletePost 3
18437 wp.getPostTypes 3
18436 wp.getPostType 3
18444 Taxonomies wp.getTaxonomies 1
18443 wp.getTaxonomy 2
18442 wp.getTerms 1
18441 wp.getTerm 2
18438 wp.newTerm 1
18439 wp.editTerm 2
18440 wp.deleteTerm 4
18434 wp.getPostTerms 1
18435 wp.setPostTerms 1
18428 Users wp.getUsers 1
18427 wp.getUser 2
18424 wp.newUser 1
18425 wp.editUser 1
18426 wp.deleteUser 3

(Note: priorities are my opinion, not necessarily that of WordPress core team)

Bugfixes

The remainder of the tickets are a mix of feature requests and bugs. Many already have patches, though they may need to be updated to apply against trunk. An example of some easy fixes that would make the lives of the mobile app developers (and other XML-RPC users) so much better:

Ticket # Description Status
18566 Expose discussion settings on XML-RPC has-patch
18126 Expose image options on XML-RPC has-patch
17981 wp.getComments should work for non-admins has-patch
18683 wp.getMediaLibrary doesn’t return attachment ids has-patch
17109 Add more hooks for pluggability has-patch
13917 wp.uploadFile cannot be attached to a post has-patch
17132 Expose template/active_plugins on XML-RPC has-patch
10933 Expose custom more text on XML-RPC has-patch
19027 Return modification date on mw.getPost/mw.getRecentPosts has-patch

Of the 51 open non-GSoC XML-RPC tickets, 34 currently have patches.

Next Steps

My first task is to get a release of the improved wp-webservices plugin out the door. I started work on it this summer when the GSoC project was winding down, and I’ll spend the next few days doing some more refining. My goal is to have code available by Tuesday, and updated patches on all the GSoC tickets by Wednesday.

Starting this weekend I’ll also start idling in #wordpress-dev again, where I’ll be pestering nacin, westi and josephscott about triaging the old tickets and getting some of the low-hanging fruit committed.

10 Responses to The WordPress XML-RPC (Ticket) Hit List
  1. Dan

    If you could add featured image support, thousands of mobile users would thank you :)

    http://core.trac.wordpress.org/ticket/15098

  2. maxcutler

    @Dan: I omitted that ticket because I planned for that to be a part of wp.{new,edit}Post.

    But now that you mention it, I can see the value in backporting it to the metaWeblog methods (using something like cfinke’s patch) to make it easier for the mobile apps to adapt instead of switching entirely to the new wp.* methods.

  3. Thorsten Ott

    I’m happy to assist. I mentored the wp-web services plugin and am hugely interested in getting xmlrpc to a more unto date state

  4. Joseph Scott

    Now is a good time to go over XML-RPC items and get them into WP -trunk. When I’m online I’m usually on #wordpress-dev, so ping away.

  5. Joseph Scott

    I looked at the following tickets:

    19027 – ok
    18566 – ok
    18126 – ok (with a note about listing what the legitimate values are)
    18683 – ok
    13917 – ok

  6. Joseph Scott

    Found another XML-RPC ticket that would be nice to have in as well: 18684 – XMLRPC metaWeblog.newMediaObject doesn’t have possibility for setting excerpt/content

    Concept is good, would like get some core folks looking at that though to make sure it is solid.

  7. maxcutler

    Thanks for looking at those Joseph, and 18684 does indeed look like a nice one to get in pending a security review.

    I hope to be done my own triage on the GSoC tickets by Saturday evening and have it out as a plugin for people to test. Would be great to get your feedback on those tickets at that point.

  8. Ian JOhnston

    May I kindly ask if any of these methods will provide information about metaboxes and custom fields for custom post types (most probably wp.getPostTypes.

    I am testing wordpress 3.4 beta 2 but cannot (might be my bad) work out how to get the full structure of a custom post type so that you can create data entry screen for a remote xmlrpc client

    Many thanks in advance

  9. Andrew Nacin

    @Ian: Meta boxes and custom fields aren’t necessarily specific to individual post types, and they are simply key/value pairs, so it is difficult to detect what specifically is registered and in use.

    What we could probably do is add a method in the future that can fetch all non-protected meta keys in use for a particular post type and return those. At the moment though, you can still use ‘custom_fields’ to get and set individual keys without issue.

  10. Ian Johnstonn

    @Andrew Thanks for your time.

    All the work done in this new set of xmlrpc methods is fantastic and I applaud all the many contributors.

    Our primary use case is to provide the ability to create and edit custom posts via xmlrpc client.

    This is also a much requested feature for ios.wordpress and other mobile clients as it would provide full mobile functionality for the many themes and plugins that utilize the full power of WordPress’s extensibility with custom posts, taxonomies and the like.

    This new set of xmlrpc methods is complete(?) and in the main seemingly directed at this use case. a wp.getFields

    From our understanding from testing and your answer the new methods cannot used in a client application to “blindly” support custom post types.

    Custom PostTypes, Taxonomies and Fields are all interrelated. Any taxonomy or field can be attributed and used by any postType.

    The purpose of wp.getPostTypeshould is, in my very humble opinion, to detail these interrelationships so that a remote client can present “views” to gather information to publish and edit “custom” posts via methods such as wp.newePost and wp.editPost.

    If wp.getPostTypes does not fully describe the parameters and interrelationships of the post type it is difficult to understand how this method will be used and for what purpose. Custom fields are these days de rigueur in most themes and plugins.

    Breaking out a separate method to get meta-fields would appear redundant as the correct place for this information would, again in my opinion, wp.getPostTypes.

    To add to the potential complexity of this issue I also note that custom fields are often added to standard posts and pages. For example, an SEO plugin might add meta keywords, title and description fields to standard posts which should (for completeness) also be incorporated into the wp.getPostType response…(??)

    I look forward to your thoughts on my analysis and in discussing this in more detail. I am also happy to get more involved in the establishment of the xmlrpc API if indeed that is worthwhile.

    Many thanks and best Regards

Leave a Reply