[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