[wp-xmlrpc] Updating Custom Fields Using metaWeblog.editPost

[David Weiss]

Thank you.

Now I understand it a bit better.  I was coming from a perspective of custom
fields being more like an extension of the WP data dictionary.  I'm still
trying to figure out how I'm going to update a specific key's value through
XMLRPC though.  Technically, I'm fine, but functionally, it seems
problematic to me.  I'd somehow have to do a getPost, then inspect the
custom_fields array to figure out what meta_ID is attached to the specific
field I'm wanting to update.




On Wed, Apr 8, 2009 at 8:54 AM, Dougal Campbell <dougal at gunters.org> wrote:

> Daniel Jalkut wrote:
>
>> Joseph - thanks for clarifying what I was talking about.
>>
>> Also:
>>
>> On Apr 7, 2009, at 4:04 PM, Joseph Scott wrote:
>>
>>  The reason for this because you can have duplicate keys, so the id is
>>> required in order to uniquely identify a field.  There's nothing to stop you
>>> from having 25 custom fields on a post all with the same key name.
>>>
>>
>> Do you have a sense for whether many (any?) plugins expect this kind of
>> scenario? In providing a service to my customers, I'm expecting to allow
>> them to configure named fields with the assumption that there will be a 1-1
>> relationship of names and fields. I wonder if I'm setting myself up for a
>> customer backlash with this restriction.
>>
>> I'm thinking mostly of the obvious cases for custom fields like "mood",
>> "music I'm listening to", etc.  Seems like if it has a name, most customers
>> will only expect for there to be one.
>>
>>
> I implemented the PostMeta (Custom Fields) feature that way for a reason.
>
> At the time, it seemed like the best/easiest way to allow an array of
> values for a key to be stored. Why would you want an array of values? Keep
> in mind that custom fields were added to WordPress long before tags were.
> But, custom fields made it possible to implement per-post tags. Yes, you
> could have used a comma- or space-separated list of values, but then every
> plugin developer would need to work out their own formats and parsing when
> they needed break simple text lists back up into arrays for processing. I
> wanted to make the system flexible for plugin developers to build upon, yet
> keep the UI simple for end-users.
>
> Keep in mind that even if you have multiple custom fields attached to a
> post with the same key, you can fetch them all as an array with a single
> call. The API consolidates them for you. It may look confusing to some
> people if you are *expecting* to have unique keys per post, but it still
> seems to me like the best compromise between simplicity and flexibility.
> Every other way I could think of to do it becomes over-complicated pretty
> quickly.
>
> --
> Dougal Campbell <dougal at gunters.org>
> http://dougal.gunters.org/
> http://twitter.com/dougal
> http://twitual.com/
> *Hire me!*
>
> _______________________________________________
> wp-xmlrpc mailing list
> wp-xmlrpc at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-xmlrpc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://comox.textdrive.com/pipermail/wp-xmlrpc/attachments/20090408/8fc1aba8/attachment.htm