Make WordPress Core

Opened 15 years ago

Closed 15 years ago

Last modified 15 years ago

#5148 closed defect (bug) (fixed)

XMLRPC interface should support custom fields

Reported by: redsweater's profile redsweater Owned by:
Milestone: 2.5 Priority: normal
Severity: normal Version: 2.3
Component: XML-RPC Keywords:
Focuses: Cc:


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.


Attachments (2)

xmlrpc.php.diff (3.0 KB) - added by josephscott 15 years ago.
xmlrpc.php.2.diff (2.9 KB) - added by josephscott 15 years ago.

Download all attachments as: .zip

Change History (9)

#1 @josephscott
15 years ago

  • Cc josephscott added

#2 @jcheng
15 years ago

(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?

#3 @redsweater
15 years ago

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:

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.

#4 @josephscott
15 years ago

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.

#5 @josephscott
15 years ago

Updated patch that cleanly applies to -trunk.

#6 @ryan
15 years ago

  • Resolution set to fixed
  • Status changed from new to closed

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

#7 @santosj
15 years ago

  • Milestone changed from 2.5 to 2.4

Assumed fixed on trunk.

Note: See TracTickets for help on using tickets.