function wp_get_object_terms() passes sql data into `wp_get_object_terms` filter for $taxonomies

[postpostmodern]

In wp-includes/taxonomy.php, the return data is passed through the wp_get_object_terms filter using the sql-ready data for $taxonomies, meaning it is quoted and comma seperated, for example "'category', 'post_tag', 'post_format'". Even for one taxonomy, it has quotes added, it seems this would be easier to work with if it matched the data passed into the function more closely.

[postpostmodern]

function wp_get_object_terms() fixing $taxonomy for filter

[ryan]

An array would indeed be better, but we need to see how many plugins this change impacts.

[wonderboymusic]

Let's figure out if we can do this

[nacin]

We need to figure out:

• If any plugins are using the wp_get_object_terms filter, and what they do when they handle $taxonomies.
• When we broke this, or if it was always like this.

[jdgrimes]

Replying to nacin:

We need to figure out:

• If any plugins are using the wp_get_object_terms filter, and what they do when they handle $taxonomies.
• When we broke this, or if it was always like this.

It appears that the taxonomies have been passed like this since the filter was first introduced in [11253].

[postpostmodern]

Replying to nacin:

We need to figure out:

• If any plugins are using the wp_get_object_terms filter, and what they do when they handle $taxonomies.
• When we broke this, or if it was always like this.

As far as I can tell, this affects two plugins in the plugins directory.

​Custom Taxonomy Sort This plugin has not been updated in over two years. The method get_terms in ​http://plugins.trac.wordpress.org/browser/custom-taxonomy-sort/trunk/custom-taxonomy-sort.php uses this as the $taxonomy argument and ignores it.

The other plugin that uses this is ​Co-Authors Plus. The method filter_wp_get_object_terms in ​http://plugins.trac.wordpress.org/browser/co-authors-plus/trunk/co-authors-plus.php uses this data in the way WordPress is currently built, directly inserted into a manual sql query. However, this plugin is authored by Core contributors and could easily be updated, and as it is only tested to 3.5.2 it is due to be checked for compatibility anyways.

I would argue that using $taxonomies as an array in this filter is still better and more flexible to work with, a use case would be pulling or inserting specific taxonomies into this data.

[doublesharp]

The same issue applies to $object_ids as well - its type is changed from an array to a string before it is passed to the wp_get_object_terms filter. All of the caveats of use by plugins, etc apply as well but I am attaching a patch that updates both the $taxonomy (array) to $_taxonomy (string) and $object_ids (array) to $_object_ids (string).

[doublesharp]

wp_get_object_terms filter fix for $taxonomies and $object_ids

[doublesharp]

taxonomy_wp_get_object_terms corrected

[SergeyBiryukov]

#31098 was marked as a duplicate.

[MikeHansenMe]

Refreshed.

[MikeHansenMe]

Looks like one of the plugins has not been updated in a couple years and the other is authored by people who are active in the community. Should be fairly easy to get them to update their plugin. I refreshed the existing patch since it failed when I applied it.

[boonebgorges]

Replying to postpostmodern:

As far as I can tell, this affects two plugins in the plugins directory.

Here's a complete list of the affected plugins I just found in a search of the repo:

• wpmovielibrary
• co-authors-plus
• polylang
• capa
• webcomic
• qtranslate-slug
• cpt-onomies

All of these plugins are actually using the $taxonomies variable passed to the filter, and either using it directly in a SQL query, or manipulating it as a string (eg explode( ',', $taxonomies )). They'll all break more or less every time the 'wp_get_object_terms' filter is called.

If this list is indicative of the popularity of this filter - and I'd wager that it is, and that the nature of the filter is such that it would be used even less on bespoke WP customizations than in distributed plugins - I'd be OK with breaking it. Does anyone have a problem with this?

To move forward, I'd like to see an updated patch that explains the change in the docblock (maybe another @since annotation).

[johnjamesjacoby]

A few thoughts:

• Co-authors-plus has almost 100k downloads and is quite popular amongst the WordPress.com VIP group.
• CPT-onomies is around 20k downloads, and probably relies on this bit to make its connections.

Before we break anything, can we loop those plugin authors in and have an approximation of a fix ready for them?

[boonebgorges]

Thanks johnjamesjacoby. Yes, the authors of those plugins should definitely be looped in once a decision is made one way or another. The fix in most cases is trivial: nearly all of the plugins are doing manipulation to turn the string into an array, and the fix will be to wrap that logic in if ( ! is_array( $taxonomies ) ).

Heck, I'm happy to write the necessary patches myself for this small handful of plugins. I'm not worried about the authors of co-authors-plus and cpt-onomies - they'll likely be proactive about changes like this. It's the long tail of plugins and private customizations that are more worrisome, but my guess is that the tail actually isn't that long in this case.

[boonebgorges]

Per a suggestion by nacin, 18828.3.diff​ skirts the issue by introducing a new filter, 'get_object_terms', which is passed a proper array of taxonomies.

[boonebgorges]

In 31581:

Introduce 'get_object_terms' filter in wp_get_object_terms().

The existing 'wp_get_object_terms' filter accepts a parameter $taxonomies,
which is a list of taxonomy names formatted for direct use in a MySQL IN clause.
This formatting makes it difficult to make use of the taxonomy list in filter
callbacks. However, changing the parameters passed to the existing filter
raises backward compatibility concerns, so we introduce a new filter that
receives a structured $taxonomy_array parameter.

We also take this opportunity to correct and clean up some of the documentation
on the 'wp_get_object_terms' filter.

Props postpostmodern, doublesharp, wonderboymusic, nacin.
Fixes #18828.

[doublesharp]

@boonebgorges This same behavior is applied to the $object_ids as well - it is passed as a SQL fragment rather than an array of IDs. The array is imploded just after the taxonomy array with:

$object_ids = implode(', ', $object_ids);

This differs from your documentation on the get_object_terms filter. Instead of a single ID or array of IDs, it will be a comma separated string as it is currently implemented.

[doublesharp]

Pass $object_id_array instead of $object_ids to filter

[boonebgorges]

Good catch - thanks, doublesharp.

[boonebgorges]

In 31639:

Ensure that an array of object IDs is passed to the 'get_object_terms' filter.

Originally introduced in [31581].

Props doublesharp.
Fixes #18828.