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
Dan December 23, 2011
If you could add featured image support, thousands of mobile users would thank you
http://core.trac.wordpress.org/ticket/15098
maxcutler December 23, 2011
@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.
Thorsten Ott December 23, 2011
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
Joseph Scott December 23, 2011
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.
Joseph Scott December 30, 2011
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
Joseph Scott December 30, 2011
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.
maxcutler December 30, 2011
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.
Ian JOhnston April 19, 2012
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
Andrew Nacin April 19, 2012
@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.
Ian Johnstonn April 20, 2012
@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