Make WordPress Core

Opened 3 years ago

Closed 18 months ago

#17156 closed enhancement (fixed)

Filters to allow setting custom taxonomy on the fly

Reported by: dougal Owned by:
Milestone: 3.4 Priority: normal
Severity: normal Version:
Component: XML-RPC Keywords:
Focuses: Cc:


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 recursive loop.

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.

Change History (6)

comment:1 scribu3 years ago

  • Component changed from Taxonomy to XML-RPC

comment:2 josephscott3 years ago

  • Cc josephscott added

comment:3 markoheijnen21 months ago

  • Keywords close added

I believe this can be closed now due the work in 3.4 where you now can add terms and there are some extra hooks added

comment:4 dougal21 months ago

Are you sure? I just took a quick glance through the xmlrpc code and post.php, and I don't see any new places to hook a filter for what I've described. I also did a diff of the 3.3 and 3.4 versions of post.php, and nothing jumped out at me. If you can point out something specific, I'll be happy, and just adapt my workaround code.

If not, I'll re-open and submit a patch.

Last edited 21 months ago by dougal (previous) (diff)

comment:5 markoheijnen21 months ago

Only the wp.* methods should be used now. In 3.4 we added wp.newPost and that can handle taxonomies by names or id's.
It uses the function _insert_post inside the XML-RPC class. This has a filter "xmlrpc_wp_insert_post_data" what filters the data before it get passed in.

I'm not sure if this is what you wanted or not. Please let me know.

comment:6 markoheijnen18 months ago

  • Keywords close removed
  • Milestone changed from Awaiting Review to 3.4
  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.