[wp-hackers] Setting custom taxonomy on the fly
dougal at gunters.org
Sun Apr 17 16:49:34 UTC 2011
I'm currently working on a theme, and one of the things I wanted to do
is to automatically set the Post Format when using an XML-RPC client.
This isn't currently supported by the WordPress for iPhone app, for
example, so I was trying to hack around it by looking for a string at
the beginning of a post, something like:
:status: Watching the game and drinking a beer. Life is good.
I was going to detect the ':status:' string, remove it from
post_content, update the post on the fly, and set the post format.
But I keep running into roadblocks.
For one thing, in class-wp-xmlrpc-server.php, the mw_newPost() method
doesn't do any filtering of the supplied data. This would be the ideal
place for me to do what I want, because I could theoretically just add a
'tax_input' key to the post data that is passed into wp_insert_post(),
and everything would just be magic from there. I suggest adding a new
filter after the data is compacted into the $postdata array, and before
it is passed to wp_insert_post();
Similarly, another opportunity would be is if there was a filter in
wp_insert_post() after parsing the args, but before the extract() is
performed. This would give another chance to inject/alter the post data
before it is processed.
Without a filter in one of those places, it's extremely difficult for a
plugin or theme to set/change custom taxonomy terms on a post on the
fly, when the post comes in via XML-RPC.
So that leaves us with just a couple of other opportunities to act: the
'wp_insert_post_data' filter, and the 'wp_insert_post' action. With the
filter, I can detect my sentinel string and strip it back out of the
post, but I can't set the post_format, because we don't have a post_ID
yet. But if we get all the way to the 'wp_insert_post' action, updating
the post content to strip out the sentinel is a problem, because using
wp_update_post() will in turn call wp_insert_post(), which is a
One more place where a filter would be useful is when wp_insert_post()
checks for the $tax_input variable (which would have been included in
the original $postarr argument passed into the function). A 'tax_input'
filter which received the post_ID would be another chance to extend the
ability to manipulate custom taxonomies on the fly, at post creation time.
(I've also posted this as a Trac ticket:
Dougal Campbell <dougal at gunters.org>
More information about the wp-hackers