XMLRPC interface should support custom fields

[redsweater]

WordPress's XMLRPC interface doesn't provide a mechanism for reading or writing custom fields on a post.

I chatted with Joseph Scott and Westi a bit about this, and there is some debate about whether the custom fields should be included in the body of the post for new/edit/getRecent posts, or whether there should be a separate API.

It seems like it would be tedious to have to explicitly ask for and set the custom fields separately from the main get/set APIs, but I would be happy to see support for it in one way or another. Right now there's no way for custom clients like MarsEdit to support this feature.

Daniel

[jcheng]

(Just to make sure I know what you're talking about... custom fields meaning fields that are interpreted by WP plugins?)

I think it's much more natural to have custom fields be part of new/edit/getRecent/getPost but there is the problem that clients generally drop fields that they don't understand or don't deal with. The semantics would have to be such that the absence of a field in edit means, "Don't change the value". (I believe this is the case with dateCreated, for example--but not mt_keywords.) And there also then needs to be a distinct way to say "delete the value".

For example, if I were designing mt_keywords today, editPost not having mt_keywords would mean don't change the keywords; but mt_keywords with a zero-length string as the value, means remove the existing keywords.

I'm still in favor of these things being part of the post struct instead of separate methods, though. Having to publish a post and then modify it with separate setters is a disaster. What if password protection was implemented as a separate field?

[redsweater]

Good points, Joe. I there should be extreme caution as to not obliterate existing fields when a client doesn't supply a value.

I didn't really know much about the custom fields until a customer pointed me to this wiki page today:

​http://codex.wordpress.org/Using_Custom_Fields

So yeah - it seems like it's just sort of a generic repository of keyed values, and plugins can use them for nifty purposes of their choosing.

[josephscott]

The attached diff exposes custom fields via wp.getPage and metaWeblog.getPost (and their friends). The new field is called "custom_fields" and an array of structs, with each struct containing three entries: id, key and value. Something like this:

    "custom_fields" = (
        {id = 129; key = city; value = Sacramento; }, 
        {id = 130; key = city; value = Sandy; }
    )

Custom fields can be added via wp.newPost/editPost and metaWeblog.newPost/editPost following the same general format. If a custom field entry included with a post contains an "id" value then an update is done. If there is no "id" then an add is done. If there is an "id" value and no "key" value then the custom field with that id is deleted.

I'm also open to the possibility of a wp.addCustomField(blog_id, post_id, key, value) style methods if discussions show that there is an interest and a reasonable use for them.

[josephscott]

Updated patch that cleanly applies to -trunk.

[ryan]

(In [6418]) Custom fields support for xmlrpc from josephscott. fixes #5148

[santosj]

Assumed fixed on trunk.