WP webservices
Hi everybody,
I haven’t posted my update last week because there is nothing new to update. last week we got our SVN credentials. So i decided to start coding early since i have completed all my learning part before submitting the proposal. I started coding my first part of the project, User management. It was very smooth as expected 🙂 Thanks to the existing API which made my job easy.
I have added a patch for each methods for review. After the review necessary changes will be made and committed to the core
http://gsoc.trac.wordpress.org/ticket/41
http://gsoc.trac.wordpress.org/ticket/42
http://gsoc.trac.wordpress.org/ticket/43
http://gsoc.trac.wordpress.org/ticket/44
http://gsoc.trac.wordpress.org/ticket/45
IMPLEMENTATION
- I have omitted some of the fields in user management as it will be not useful for external clients such as admin color scheme etc
- The first field of all methods are reserved for blog_ID for future use
- wp-admin interface do not validate user websites. So I,m leaving that as it is.
ISSUES
- blocker – http://core.trac.wordpress.org/ticket/16980 There is this known issue that empty values are ignored by IXR server. So there is no way to set a field empty via XMLRPC. Say if you first add your AIM and you want clear it as you no longer use AIM, there is no way to do that unless the issue is fixed.
TODOS
- i worked on sending a confirmation mail to users after registration. But there was no mail in the test mail. Even the registering via admin interface doesn’t send a mail. I’m leaving it for the moment and come back to that later.
QUESTIONS
- I couldn’t identify a common pattern in the use of error codes used. Although i have used as it is from the existing methods there is no resources explaining the use of error codes in WordPress ?
- A user can be identified using different parameters such as user_ID, email, username etc. Currently the methods only support modifying users using user_ID. Will it be desirable to support all the parameters ?
- What is the use of user_nicename field?
This week I’m starting on my next part. Abstracting metaWeblog methods to support custom post types. This will be the most challenging part.
Prasath Nadarajah are discussing. 
WordPress Summer of Code 2011 
Joseph Scott 5:13 pm on May 23, 2011 Permalink |
On the blocker, I already posted a work around on the WPORG ticket you referenced.
As I recall most of the error codes are loosely lined up with the correct HTTP error code. Some of these don’t line up perfect, like 405 for disabled XML-RPC services, but have tried to keep them in the ball park. Are there specific error conditions where you aren’t sure which code to use?
On user lookup, at this point I’d just keep it to user id.
The user_nicename field is used for things like the post author slug.
In previous conversations I thought we’d talked about having separate custom post type methods. Am I mis-remembering that?
Prasath Nadarajah 4:14 am on May 24, 2011 Permalink |
Most client don’t allow you to control the xml structure sent to WordPress. Also most the available libraries used to generate this strcuture does’nt include a type. I think this should be fixed.
Agreed on implementing custom post types as a separate method.
Joseph Scott 4:24 am on May 24, 2011 Permalink
Long term, yes, the IXR library should follow the spec, but in the short term I wouldn’t wait on that. At best this won’t get in until WordPress 3.3.
We’ve had XML-RPC clients talking to WordPress for years and this is the first time it has come up so it doesn’t seem to be an immediate issue.
Eric Mann 2:05 pm on May 24, 2011 Permalink
Patching IXR should be on some to-do list somewhere, but for now I’d recommend sticking with Joseph’s workaround for testing. True, not every client will specify a type, but let’s get things working as-is for now and chalk that up as a known issue until we can fix IXR.