Thank you.<br><br>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.<br>
<br><br><br><br><div class="gmail_quote">On Wed, Apr 8, 2009 at 8:54 AM, Dougal Campbell <span dir="ltr"><<a href="mailto:dougal@gunters.org">dougal@gunters.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Daniel Jalkut wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Joseph - thanks for clarifying what I was talking about.<br>
<br>
Also:<br>
<br>
On Apr 7, 2009, at 4:04 PM, Joseph Scott wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.<br>

</blockquote>
<br>
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.<br>

<br>
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.<br>
<br>
</blockquote>
<br>
I implemented the PostMeta (Custom Fields) feature that way for a reason.<br>
<br>
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.<br>

<br>
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.<br>
<font color="#888888">
<br>
-- <br>
Dougal Campbell <<a href="mailto:dougal@gunters.org" target="_blank">dougal@gunters.org</a>><br>
<a href="http://dougal.gunters.org/" target="_blank">http://dougal.gunters.org/</a><br>
<a href="http://twitter.com/dougal" target="_blank">http://twitter.com/dougal</a><br>
<a href="http://twitual.com/" target="_blank">http://twitual.com/</a><br>
*Hire me!*</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
wp-xmlrpc mailing list<br>
<a href="mailto:wp-xmlrpc@lists.automattic.com" target="_blank">wp-xmlrpc@lists.automattic.com</a><br>
<a href="http://lists.automattic.com/mailman/listinfo/wp-xmlrpc" target="_blank">http://lists.automattic.com/mailman/listinfo/wp-xmlrpc</a><br>
</div></div></blockquote></div><br>