WordPress.org

Make WordPress Core

Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#5148 closed defect (bug) (fixed)

XMLRPC interface should support custom fields

Reported by: redsweater Owned by:
Milestone: 2.5 Priority: normal
Severity: normal Version: 2.3
Component: XML-RPC Keywords:
Focuses: Cc:
PR Number:

Description

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

Attachments (2)

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

Download all attachments as: .zip

Change History (9)

#1 @josephscott
12 years ago

  • Cc josephscott added

#2 @jcheng
12 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
12 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:

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.

#4 @josephscott
12 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
12 years ago

Updated patch that cleanly applies to -trunk.

#6 @ryan
12 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
12 years ago

  • Milestone changed from 2.5 to 2.4

Assumed fixed on trunk.

Note: See TracTickets for help on using tickets.