Mentors – Thorsten Ott(primary), Eric Mann

Prasath Nadarajah

Bio: Hello everyone, My name is Prasath Nadarajah. I’m 22 years old and I’m from Colombo, Sri Lanka (UTC 5.30+). I’m doing computer science & engineering at University of Moratuwa, Sri Lanka. My areas of interest are “Java”, “XML”, “Webservices” and related technologies. I’m also familiar with numerous apache projects through my work

Project Goals

User Management

There is no methods to manage users via XMLRPC. Managing users using clients would be a very useful feature.There would be new user tab in my wp-android app ;). The proposed methods will allow only current user to manage user with a capability check. New users can’t register themselves because it will allow spammers to create mass accounts.

Also its better if we have a method to get capabilities of the user when connecting at the first instance so we can validate capabilities at the client end. This will reduce redundant calls to the server.

This is a very important feature we need.

Improved Search API

This has been addressed on tickets #6850and #16316. The current search methods imposed unnecessary burden to the server, A more generalized search API for all getters (posts, users, comments etc) will increase the performance of both client and server. The new methods  will only act as an agent for the existing query API. So the amount of work here is very small. All parameters will checked before passing to the query API.

  • Post/Pages – WP_Query class accepts a lot of parameters for querying post/pages. A getPosts methods to accept these parameters and pass it to the WP_Query. This includes retrieving posts by category,tag,date etc.

  • Users – WP_User_Query class can be used to query users. These parameters will be passed through the new wp.getusers method. This includes retrieving users by roles etc

  • Comments – Again WP_Comment_Query class can be used. wp.getComments will pass more paremeters such as author _email etc.

There is also another option of separately querying using global $wpdb similar to getPageList.

Custom Post Types Management

WordPress 3.0 gives you the capability to add your own custom post types and to use them in different ways.A generic API for managing posts would be beneficial include post, pages, nav_menu_items as well as user defined custom post types.

Custom post type are not stored persistently. Managing custom post types want be desirable and many developersfeel that way. So I’m dropping managing custom post types via xmlrpc. What would be desirable is that editing posts with already registered types. Abstracting the metaweblog API to support custom post types is useful.

Same approach can be done for taxonomy management as well.

Custom Taxonomy Management

WordPress 3 gives us fully hierarchical custom taxonomies. Managing custom taxonomies would using clients be awesome. Again custom taxonomies also not stored persistently. So I,m not supporting new taxonomies via xmlrpc. Same as custom post type a generic API for editing taxonomies is good as it includes categories, tags, post formats, nav_menus as well as user defined taxonomies.

Managing Blog Options

There is only a few options that can be changed via xmlrpc. Its good to extend it to support more options. These options can be grouped as public and private. Some options must be exposed all registered users where as some must be exposed only who has the capability ‘Manage options.

Considering backward compatibility we can introduced completely new methods which can acts as a gateway to get_options, update_options in the functions.php. Using these two methods any of the blog settings can be changed.

Schedule of Deliverables




Community Bonding Period

Finalize the API. Develope Common functions to be used in the plugin. Plan the coding approach and abstraction of functions

Apr 25 – May 22

User Management


May 23 – May 29






Custom Post Type


May 30 – June 12







Custom Taxonomies


June 13 – June 26








Search API


June 27 – July 3




Blog Options


July 5 – July 8


Release Alpha Version

July 9 – July 10


Testing with various use cases. Identify bugs and rework the code. Release beta version

July 12 – July 25

Get feedback from the community and developers. Improve the code with possible additions

July 26 – Aug 3

 Documentation and final stable release

Aug 4 – Aug 15