XML-RPC API should return commentmeta values

[djr]

This ticket is a follow up on my Twitter and subsequently email conversation with Joseph Scott (josephscott) about the new commentmeta table in WordPress 2.9 and the XML-RPC API. We use the plugin Feature Comments (​http://wpprogrammer.com/feature-comments-wordpress-plugin/) for hiding or featuring certain comments. The plugin stores either a value of 'Buried' or 'Featured' in the commentmeta table and uses these values to append a css class to comment_class.

I'd love to retrieve these commentmeta values (buried/features) through the XML-RPC API (which we use) with wp.GetComment or wp.GetComments, so we're able to programmatically hide or feature these comments in our own iPhone app.

Please note this is a specific example, but my request should I no way be seen as a private request. I think the commentmeta in 2.9 was a great addition for stuff like Twitter usernames, mood, gender, and so forth. I hope we're able to retrieve these values programmaticaly through the API as well.

[ericmann]

That patch won't work.

get_comment_meta() takes in more than just the comment id. You also need to specify the key you're retrieving. Here's the full function from the source:

function get_comment_meta($comment_id, $key, $single = false) {
    return get_metadata('comment', $comment_id, $key, $single);
}

$single is optional (and not needed in this case), but $key is not. At the very minimum, you'd have to loop through and get all the keys so you could retrieve all the comment meta.

[ericmann]

Scratch that, apparently you can leave $key blank to have the function return everything. Looks good.

[aaroncampbell]

Please don't change the version on the ticket. The version is used to track the version when the error first occurred.

[ericmann]

Replying to aaroncampbell:

The version is used to track the version when the error first occurred.

Considering this is a feature request and not a bug fix, should we be patching and reporting against trunk? It's not an error ... but a requested API enhancement for a feature introduced in 2.9.

[nacin]

Replying to ericmann:

Considering this is a feature request and not a bug fix, should we be patching and reporting against trunk?

Yes, always patch against trunk.

It's not an error ... but a requested API enhancement for a feature introduced in 2.9.

The version field is for the earliest applicable version of a report. Generally for bugs, but works for enhancements just fine too. Version 2.9 is appropriate here as that's when commentmeta came into play.

[nprasath002]

THe documentation for get_comment_meta is not complete as the key value and the boolean is optional.
i created a ticket for that here
​http://core.trac.wordpress.org/ticket/16965

Also i normally test with a java client and print to see whether i,m
getting the expected results
should i removed needs testing??

P.S - i,m nt getting any updates about this ticket via email. how can i do that

[dd32]

P.S - i,m nt getting any updates about this ticket via email. how can i do that

Ensure your email is listed in the ​preferences and check the CC box when making a reply.

[chriscct7]

Patch on this needs to be updated per comments, but not a refresh so needs patch I guess.

[swissspidy]

See also #35991 for term meta.

With the REST API now in core, are these new features to XML-RPC still relevant?

[redsweater]

Speaking only as one significant user of the XML-RPC API, these enhancements are not useful to me. Generally speaking I would be happy to see XML-RPC development slow or cease in favor of the REST API, which I hope to move to at some point.

[dd32]

I would be happy to see XML-RPC development slow or cease in favor of the REST API, which I hope to move to at some point.

I would be happy to see that happen; XML-RPC should be maintained and bugs fixed obviously - but I'm not sure adding new features to an API which few people would choose to use over a REST API - even if only just for the larger number of API clients written.

[swissspidy]

Given the lack of traction, the recent feedback, and the shift to the REST API, I'm closing this one as a wontfix. Could also be a maybelater, but I doubt that it will suddenly become relevant.