WordPress.org

Make WordPress Core

Opened 7 years ago

Closed 6 years ago

Last modified 6 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:

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 6 years ago.
xmlrpc.php.2.diff (2.9 KB) - added by josephscott 6 years ago.

Download all attachments as: .zip

Change History (9)

comment:1 josephscott7 years ago

  • Cc josephscott added

comment:2 jcheng7 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?

comment:3 redsweater7 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.

josephscott6 years ago

comment:4 josephscott6 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.

josephscott6 years ago

comment:5 josephscott6 years ago

Updated patch that cleanly applies to -trunk.

comment:6 ryan6 years ago

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

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

comment:7 santosj6 years ago

  • Milestone changed from 2.5 to 2.4

Assumed fixed on trunk.

Note: See TracTickets for help on using tickets.