[wp-xmlrpc] GSOC Proposal - Extending WordPress Remote API

Eric Mann eric at eam.me
Sun Mar 20 00:50:11 UTC 2011


You've put a lot of thought into this so far, and I'm liking where you're
headed.  Here is a quick observation that might help you refine some of the
idea:

*Tags Management*
Both tags and categories are *taxonomies*.  Rather than build out new
features specific to tags to beef up the system, it might be a stronger idea
to generalize the system so it can manage *any* taxonomy.

Aside from that, I see no problems with what you're proposing, but let me
push back a little bit.  What experience do you have working with the
XML-RPC API so far?  Have you patched it yet, or will this be your first
stab at it?

On Sat, Mar 19, 2011 at 11:01 AM, prasath nadarajah <n.prasath.002 at gmail.com
> wrote:

> Hi hackers,
>
> I,m interested in working on extending WordPress xmlrpc capabilities for
> this years GSOC. I came up with some ideas for improving the current API.
> Please let me know what you think of these ideas and possible additions to
> this project. Thank You.
>
> *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.
>
> *Tags Management*
>
>  There are enough methods to manage categories via XMLRPC. But not tags.
> For example we cannot create a tag with description or a slug. Changing
> terms is a frequent thing we do with our weblog. Instead of going through
> the edit_post method it is good to have separate methods for managing terms.
> This will decrease the server load by efficiently changing the terms.
> Categories can be changed by mt_setPostCategories, mt_getPostCategories.
> Having similar methods for tags will improve efficiency.
>
> *Comment Management*
>
>  Adding support to return comment meta values. This has been requested in
> trac. I think having separate methods for comment meta values is good rater
> than integrating into comment methods.
>
> *Improved search API*
>
> This has been addressed on tickets #6850<http://core.trac.wordpress.org/ticket/6850> and
> #16316 <http://core.trac.wordpress.org/ticket/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.
>
>    -
>
>    Post/Pages - WP_Query class accepts a lot of parameters for querying
>    post/pages. Modify the getRecentPosts 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.
>
> *Trash improvements*
>
>  when you delete a post via xmlrpc it trashes it and the getRecentPosts
> method does not return the trashed items. It would be useful to have methods
> for deleting posts permanently and to retrieve trashed items. Pages,
>
> *Post Revisions*
>
>  Methods to support getting post revisions. This return a array of a posts
> for a given post id.
>
> *Flow Control Improvements*
>
> This to improve efficiency and reduce the server load. metaweblog methods
> can be used for post and pages. Putting common actions first and directing
> according to post/page and doing specific things. Similar improvements can
> be made wherever possible. Also capability checks can be made first before
> processing through the logic.
>
> Cheers
>
> _______________________________________________
> wp-xmlrpc mailing list
> wp-xmlrpc at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-xmlrpc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.automattic.com/pipermail/wp-xmlrpc/attachments/20110319/f8068bb5/attachment-0001.htm>


More information about the wp-xmlrpc mailing list