Tagged: wp webservices Toggle Comment Threads | Keyboard Shortcuts

  • Prasath Nadarajah 4:08 pm on August 28, 2011 Permalink | Reply
    Tags: , wp webservices   

    WordPress web services screencast 

    • Dan 1:05 pm on August 29, 2011 Permalink | Reply

      Nice, we can use a lot of these in the mobile apps if these make it into core someday. Good job!

      • Prasath Nadarajah 3:42 pm on August 29, 2011 Permalink | Reply

        Hi Dan,
        I have already added patches to the trunk.
        i would appreciate if you can have a look 🙂

        • Max Cutler 5:25 pm on August 29, 2011 Permalink

          I’ve been digging through the patches and will have full notes by the review chat tomorrow.

          A quick question: what’s the point of wp.getSettings and wp.updateSettings? Are they really necessary when we already have wp.getOptions and wp.setOptions? Unless I’m missing something, I don’t see that the *Settings versions really add anything over the *Options versions…

    • Prasath Nadarajah 5:46 pm on August 29, 2011 Permalink | Reply

      There two types of options with different permission levels.
      For example thumbnail size, image size information must be available for content writers.
      Currently there is no cap validation for this.

      But other information like admin mail id, mail server password must be validated against ‘manage_options’ cap. That is why i,m dividing options into to two categories and have two different methods.

      Blog_options – available for any users
      Admin_options – available only for users with ‘manage_options’ cap.

      To share admin_options in different functions i declared it as a global variable.
      When adding to the trunk it will initialized separately after initializing blog options.

      • Max Cutler 6:14 pm on August 29, 2011 Permalink | Reply

        Instead of duplicating so much code, wouldn’t it make more sense to just add an ‘if’ statement to get/setOptions depending on which list of options the requested one falls in? And if it’s in admin_options, you do the manage_options cap check?

  • Prasath Nadarajah 11:17 am on August 19, 2011 Permalink | Reply
    Tags: , wp webservices   

    WP web services – weekly update 

    I have added all the patches to the WordPress trac.

    You can find the patches here.

    Please add your opinions their as comments to these tickets.

    I will continue to add any changes there until it get committed to the WordPress trunk.

    Hope to see this with 3.3 release.

    You can download the plugin version here to test it.




  • Prasath Nadarajah 6:02 am on August 12, 2011 Permalink | Reply
    Tags: , wp webservices   

    WP web services weekly update 

    Hi guys,

    Finally i uploaded the wp webservices plugin yesterday and had 96 downloads within one day.


    I am waiting for more feedback from the users. I will be adding tickets to the WordPress trunk after that and work through for getting it in the 3.3 release. I will soon update this blog with the  trac tickets.

    I have also fixed sending ack emails for the new users. All the methods are wrking as far as i tested them.


  • Prasath Nadarajah 2:44 am on August 6, 2011 Permalink | Reply
    Tags: , wp webservices   

    This week started adding documentation. Hope to finish it by next week. I changed all the user map keys for ease of use. After finishing documentation I,m planning to add the tickets to the WordPress trunk.

  • Prasath Nadarajah 2:44 am on July 30, 2011 Permalink | Reply
    Tags: , wp webservices   

    WP web services – weekly update 

    I started adding documentation now. I was not well for the past 3/4 days. So not much progress. I have finished testing the plugin. I’d probably finish documentation within two weeks.


    • Max Cutler 1:07 pm on July 31, 2011 Permalink | Reply

      Is documentation all that remains at this point, or is there more work you intend to do?

      • Prasath Nadarajah 4:01 pm on July 31, 2011 Permalink | Reply

        I just started adding documentation.
        It will be complete as it is in the current xmlrpc class

        • Steve Steiner 6:38 pm on July 31, 2011 Permalink

          What about the changes to the parameter names we talked about in the comments of your previous post?


  • Prasath Nadarajah 2:26 am on July 23, 2011 Permalink | Reply
    Tags: , wp webservices   

    WP web services – weekly update 

    Continued testing the plugin again. Nothing much this week.

    I attended the IRC chat and discussed my progress with my mentor.

    Next week i will focus on adding documentation.

    • Steve Steiner 5:26 pm on July 27, 2011 Permalink | Reply

      I have installed the plugin and am beginning to use some of the functions.

      I have a question: Why did you rename all of the parameters?

      For example, in the wp_newUser function, which serves as a wrapper for wp_insert_user(), the parameter ‘user_login’ is renamed to ‘username’, `user_pass` is renamed `password` and so on.

      Wouldn’t it be easier to just use the name of the parameter as passed to wp_insert_user() to avoid having to remember two completely different sets of parameter names?

      This seems to have been done with almost every parameter to every function — “user_description” becomes “bio”, user_nicename becomes “nicename” and so on.

      Since these are brand new functions, there is no legacy ‘compatibility’ consideration so it would seem good practice to keep the parameter names the same as the parameter names passed to the WordPress functions and avoid all of this translation overhead.



      • Prasath Nadarajah 5:06 pm on July 28, 2011 Permalink | Reply

        I got these names from the wp-admin backend. When you add/edit users you get these ‘user_description’ as ‘bio’. Its realy good to have same names to avoid translation overhead. I will discuss this with my mentor and change it.

        let me know any bugs on these functions


    • Steve Steiner 5:48 pm on July 28, 2011 Permalink | Reply

      I’m so glad you agree!

      Some of these name translations are also carry-overs from the legacy Blogger etc. support.

      Since these are shiny new “WordPress only” functions, with no need for legacy support, the closer the functions (in both capabilities and parameter names) stay to the back-end WordPress functions they wrap, the easier they’ll be to learn, use, and, especially, remember.



    • Steve Steiner 2:12 pm on July 29, 2011 Permalink | Reply

      Would it be possible to get wp_getUser() to also accept a user_login as well as a user_ID?

      I think it’s a much more prevalent use case to have the user’s login name rather than the database ID; at least it is for me.

      Unfortunately, at the moment, it’s necessary to call wp_getUsers() to get a list of users, then find the user’s ID in the return value, then call wp_getUser() with that ID.



  • Prasath Nadarajah 3:23 am on July 8, 2011 Permalink | Reply
    Tags: , wp webservices   

    WP web services 

    Hi all,

    Fixed a lot of bugs this week and tested all the functions except custom post type functions

    Other functions are working fine to the extent i tested it. I would able to upload the plugin before midterm.


    Do i need to support user meta. Currently most of the data including capabilities of the users are saved as user meta. providing support for user meta would be very complicated. I have to filter from set of predefined meta keys.

    • Steve Steiner 3:30 pm on July 8, 2011 Permalink | Reply

      Not hard at all.

      “I have to filter from set of predefined meta keys.” — no you don’t, just have the caller “get_user_meta_keys()”, (which you may have to write if the one in WP doesn’t do what you want) if they want to get a list of the keys defined for that particular user. Then they can modify whatever they want.

      Any unrecognized keys on the “set_user_meta_keys()” (or whatever it’s called) are just created on the fly as I’m sure they are now by the internal WP functions.

      Frankly, I think you should work on improving the code quality (de-duping, testing) of what you already have before writing any more stuff. In my previous tests, some of your (duplicate) code wasn’t working at all in ways that would have been caught by even the most cursory of test suites.

      Once you have an automated test suite, you can proceed to write tests, then write new functions without wondering whether things are (still) working.

      My vote would be to focus on quality over quantity.


  • Prasath Nadarajah 4:38 am on July 1, 2011 Permalink | Reply
    Tags: , wp webservices   

    WP web services 


    This week i spent some time fixing couple of security leaks. I added more options

    to the admin options and changed some function. I stopped it developing as a seperate class and

    decided to go with the current model. Just before the midterm i will upload it the plugin repository,

    get feedback from the community to add it to the trunk


    • Steve Steiner 1:12 pm on July 1, 2011 Permalink | Reply

      Any unit testing yet?

      Any work on removing the reams of duplicate code between e.g. functions that add/update posts?

      In most cases, the only difference between create new and update is whether you provide the ID of the item to be operated on but the current codebase duplicates the entire function which is much harder to debug and maintain.


    • Prasath Nadarajah 3:12 am on July 8, 2011 Permalink | Reply

      I test functions with an external client and Apache tcpmon. The approach is specifiedin the proposal
      I analysed about removing duplicate code but thought it is easy and less complicated to keep both seperarely.

    • Steve Steiner 4:02 am on July 8, 2011 Permalink | Reply

      Please publish the tests.

      Keeping duplicate code is *never* a good idea. I would hope your mentor reinforces this basic principal of software engineering.


    • Prasath Nadarajah 4:19 am on July 8, 2011 Permalink | Reply

      The tests are in Java and i manually edit the sample datas for each scenario. So there is nothing i can publish. here is the client i use for that. http://code.google.com/p/wp-xmlrpc-server/source/browse/trunk/Client/WPClient.java

      • Steve Steiner 3:32 pm on July 8, 2011 Permalink | Reply

        Why is the code also being kept in Google Code if the official repository is the GSOC svn repository attached to the Trac instance?


    • Prasath Nadarajah 4:21 am on July 8, 2011 Permalink | Reply

      I,m preparing a doc (a check list of function capabilities for each functions). I will post it soon for inspection

    • Steve Steiner 3:00 pm on July 8, 2011 Permalink | Reply


      “manually edit[ing] the sample data for each scenario” is not a test suite — it’s a recipe for releasing buggy, untested code.

      As for duplicate code, the difference between “edit post” and “new post” is, quite literally, whether the post ID is provided. To have six pages of duplicate code is not “easy and less complicated”, it’s bad engineering and wouldn’t be tolerated on any project I’ve ever worked on. I would hope that it wouldn’t be accepted into the WordPress codebase either.

      I have worked with a number of “code cloners” over my career and they have always, justifiably, stalled out at the “junior programmer” level. If that’s where you want to spend your career, then your approach is still wrong, but understandable. I thought the purpose of GSOC was to *develop* programming talent through a short mentored and peer-reviewed project.


    • Prasath 5:27 pm on July 8, 2011 Permalink | Reply

      “As for duplicate code, the difference between “edit post” and “new post” is, quite literally, whether the post ID is provided” – no it is not
      I suggest you go through the code once again carefully.

      I tried your approach in user management and ended up with this.
      I introduced functions that handles common tasks and the functions seems to be
      pretty thin. I don’t see a *big advantage* on introducing functions to
      remove duplicate code.

      “I would hope that it wouldn’t be accepted into the WordPress codebase either.”
      Each and every function in the wp-xmlrpc class is written in that way.
      Exposing web service endpoints is very risky for a website.
      We must carefully validate/sanitize each inputs in a proper manner
      which will differ from “new” and “edit”.
      Also it makes the code more readable


      • Steve Steiner 6:40 pm on July 8, 2011 Permalink | Reply

        > I don’t see a *big advantage* on introducing functions to remove duplicate code.

        I see what you mean in this particular case; there’s not as much overlap as there is in e.g. the post code.

        What I’m getting at is that, where there are large overlaps in functionality, e.g. new vs. update post, the refactoring will help more. It’s more a case of factoring out the “special case” code, then calling a common function to do the work as with wp_update_post() calling wp_insert_post() after it does its own small set of validation checks.

        > Each and every function in the wp-xmlrpc class is written in that way.

        Yes; the original does contain large swaths of virtually identical code, but the fact that the original is written that way doesn’t mean that new code has to be written the same way. Unfortunately, I think much of WordPress came to be just like this. There are large areas of duplicate code with very slight modifications and a bug in one place becomes a nightmare to track down in all the places it was duplicated.

        I don’t mean to pick on you, I just hate to see “because it’s always been done this way” become a reason for developing bad habits that will not serve you well in your future professional programming career. I’ve been around a long time (you were -8 when I started (!) ) and duplicate code has always been one of my pet peeves. I’ve been on more than one maintenance project where a seemingly simple change became a nightmare because of the need to track down every place where the (almost) identical code lived.

        Also, please accept my apology for the seeming negativity in my comments. I’m very glad you’re taking this particular project on and want you to succeed in not only getting it done and adding some great functionality to WordPress, but learning something in the process. I’m afraid that some parts WordPress codebase are not particularly good examples of “best practices.”


        P.S. On an entirely different point, I find the “three tab indent” in your code makes it run off the edge of the screen much earlier than the nesting level would dictate. May I suggest:


    • Steve Steiner 5:54 pm on July 8, 2011 Permalink | Reply


      “no it is not” — no, it’s not in your code.

      However, in the function wp_insert_post(), the only difference between updating and creating is whether a post id is provided and, in fact, wp_update_post() calls it after it performs a small amount of mangling of the passed $postarr array. I’m suggesting that your code should be similarly structured.

  • Prasath Nadarajah 4:41 pm on June 24, 2011 Permalink | Reply
    Tags: , wp webservices   

    I have already released a beta version and… 

    I have already released a beta version and updated the blog with details.

    This week i spent on testing and fixing few bugs and changes

    Next week I’m planning to create a bew wp-xmlrpc-server class and integrate all new/old methods.


    • Steve Steiner 7:16 pm on June 24, 2011 Permalink | Reply

      Hi! I’m following this with great interest and have two questions…
      1> If you’re making bug-fixes/improvements, how come you’re not checking them into SVN?
      2> Some of the tickets in the project Trac have comments to the effect that the ticket has been implemented, but the tickets are still listed as “new.” Shouldn’t you be closing tickets as things get done?

      I’d really like to see the most recent code as I’m working on a project where I need access to custom post types and, so, could really test this out in a real life scenario.



      • Prasath Nadarajah 3:13 am on June 25, 2011 Permalink | Reply

        1. I have committed the changes i made. Most of the time i spent time on testing the code.
        2. The tickets will be open until the end of summer as there are possible changes

        The most recent code is here http://gsoc.svn.wordpress.org/2011/nprasath002/
        I have tested with an xmlrpc client and works fine for me. I am happy to hear any changes i could make on this

        • Steve Steiner 11:29 pm on June 25, 2011 Permalink

          Are you planning on adding any formal tests and having your tests incorporated into the main test suite for the release containing your changes?

          I’m not sure how thorough the overall WP test suite is, but this would seem to be a good time to have the XMLRPC portion of WordPress lead the way towards full test coverage.

          The procedure for getting a test included seems a bit cumbersome but, for these critical functions with such global ramifications, worth it.



    • Steve Steiner 2:04 am on June 25, 2011 Permalink | Reply

      Please post a link to a github or bitbucket repository where we can make forks and request that you pull in our changes.

      You asked for help with messages and such, but there’s no obvious way to submit changes.

      Also, please put a link to that repository somewhere within each entry within this blog.

      I had to go all the way back to the first post just to find where the (now 10 days old) repository was.



    • Steve Steiner 12:25 pm on June 25, 2011 Permalink | Reply

      Great, thanks!

      A couple of quick suggestions:

      1> Please add a “CHANGES.log” or somesuch to document what changes between each checked in version. Also, on those changes, put a date and time. This will help anyone following along to be aware of any changes/bug fixes in each incremental release. This is most important for people attempting to actually test out the code in a development project; you can warn of incompatible changes, new features, etc.

      2> Since each ticket roughly conforms to a function in the source code, put the name of the related function(s) right in the ticket name. This would make it much easier to find the relevant ticket when making comments, reporting bugs, etc.

      3> I realize that you copied the message from the original code, but I would suggest dropping the “For some strange yet very annoying reason,” from error messages. It’s much too “cutesy” for a real product. . In my opinion, this would be a good time to adopt a more professional tone for the error messages in both the old and new code. Obviously, this is a call for the powers that be, and is just my opinion.

      4> Again, I realize this also came from the original code, but I would suggest changing error messages to either be “Sorry, …” or not. I’m not sure what WordPress’ normal tone should be for these types of messages, but the messages in this code should be consistent. This is a pervasive problem in WordPress since there doesn’t seem to be a style guide for error messages. Maybe discuss with your mentor : choose a voice and use it in the entire module you’re working on.

      That’s my two cents for today…



    • Steve Steiner 3:08 am on June 28, 2011 Permalink | Reply

      As per my entries on this project’s Trac, certain parts of this project’s code are completely broken.

      I have written my own substitute functions, but it would be nice to hear that you are at least working on it.



      • Prasath Nadarajah 3:11 am on June 28, 2011 Permalink | Reply

        Oops did’nt notice that!!
        I will fix that and update the blog asap!!

      • Prasath Nadarajah 12:06 pm on June 28, 2011 Permalink | Reply

        I fixed all the errors you mentioned. Thanks for your input. I”m planning to write some new function to add more capability. If you have any ideas please drop here 🙂

  • Prasath Nadarajah 1:24 pm on June 15, 2011 Permalink | Reply
    Tags: , wp webservices   

    WP web services beta 

    Hi everybody.

    I finished coding web services API. Still it needs some cleanup


    • wp.newUser – allows to create a new user
    • wp.editUser – edit user information
    • wp.deleteUser – delete a specfic user
    • wp.getUser – get information about a specific user
    • wp.getUsers – retrieve a list of users
    • wp.newPost  – create a new post in any post type
    • wp.editPost  – edit any post type
    • wp.deletePost – delete a specific post
    • wp.getPost  – get any post from any post type
    • wp.getPosts  – get a list of posts in the blog
    • wp.getPostType – get information about a specific post type
    • wp.getPostTypes – get a list of registered taxonomies
    • wp.getPostTerms – get terms associated with a post
    • wp.setPostTerms – set terms associated with a post
    • wp.getTaxonomy – get information about a specific taxonomy
    • wp.getTaxonomies  – get a list of registered taxonomies
    • wp.newTerm  – create a new term in a taxonomy
    • wp.editTerm  – edit a term in a taxonomy
    • wp.deleteTerm  – delete a term in a taxonomy
    • wp.getTerm  – get information about a specific term in a taxonomy
    • wp.getTerms – get a list of term associated with a taxonomy
    • wp.getSettings – get blog settings
    • wp.updateSettings – update blog settings
    Here you can find the relevant tickets.
    The plugin code can be found here.

    Next few weeks i will be working on bug fixing and cleaning up the code.


    • As I,m not a native English speaker feel free to edit/comment on any error messages or related 😉


    • Implement the send mail feature
    • cleanup and bug fixing


    • options are not validated individually. This may cause errors when users try to update with invalid values. The current implementation also dont validate options


    Duplicate  class-wp-xmlrpc-server. add the new methods if possible add new methods.

    Bug fixing and documetation.

    Change the plugin to use the new xmlrpc class instead of the default one.

    After the end of the summer we will be able to replace the new class with the existing class hopefully from WordPress 3.3


    • Brian Layman 2:15 pm on June 15, 2011 Permalink | Reply

      Whoa! that’s awesome Prasath! Good job!

      Is getSettings the blog’s option table?
      Are comments outside the scope of this project? What about sitemeta?

      • Prasath Nadarajah 3:03 am on June 16, 2011 Permalink | Reply

        Yes. getSettings enables to edit option found in the setting tab in the backend.
        Comments are outside the scope.
        there is not methods to support multisite in xmlrpc. probably in the future

    • Joseph Scott 3:04 pm on June 15, 2011 Permalink | Reply

      Can you elaborate on options not be validated/filtered? When the setOption code was originally written that was working correctly.

      I just tried editing blog_tagline and large_size_w via wp.setOptions with javascript and both filtered it out correctly. If you have a test that shows a weakness in one of the options send me an email with the details and I’ll be happy to take a look.

      I’ve only skimmed through the plugin code you linked to, but it looks like methods like wp.getPost aren’t providing anything beyond what existing methods provide. And they copy some of the existing weaknesses, like mixed signatures with and with out blog_id. Was there something planned in the future for these duplicated features?

      • Prasath Nadarajah 4:41 am on June 16, 2011 Permalink | Reply

        If i want to edit the start_of_week via wp.updateSettings and i send a value “saturday” or “some wrong string”. It will update the tables with the value without validating that. validating every option will be a lot of code

        wp.getPost can be used for any post type including posts, pages and it returns all terms associated with the post.
        Can you elaborate in more detail about the weaknessess of the method so i can fix it?

        • Joseph Scott 7:03 pm on June 17, 2011 Permalink

          The start_of_week option gets stored as an integer, not as a string. Look at the sanitize_option() function, you’ll see that values for start_of_week get passed through absint().

          Ah, on wp.getPost I missed the filter on post_type. If this will support any post type perhaps we should come up with a more generalized name?

          Any particular reason to limit the number of posts returned to 10 (unless another plugin filters that value)? An upper limit is probably reasonable, but perhaps something a bit higher?

          Also the value for xmlrpc_getPosts_maxvalue should probably be exposed to the client in some way, so that they can tell if their request for 12 posts and only getting 10 meant there are only 10 posts or that we cut it down to 10 to enforce the limit.

    • alex 10:38 pm on June 15, 2011 Permalink | Reply

      Reading some code of the user management, you may want to review it to avoid security issues. For example, the wp.editUser method seems to allow an unprivileged user to become an administrator (you don’t verify if the current user has the capabilities to change to the specified role).

Compose new post
Next post/Next comment
Previous post/Previous comment
Show/Hide comments
Go to top
Go to login
Show/Hide help
shift + esc