Filtering get_tax_sql for advanced queries

[sc0ttkclark]

Currently in the code for 3.1 (trunk) there are no filters running on the new function get_tax_sql which would be useful for plugins to perform more complex MySQL functionality on specific columns.

I suggest adding a filter ;)

At the moment, it appears this function has disappeared from trunk for whatever reason. It's no longer in /wp-includes/classes.php so I'll keep an eye out for where it's being moved to before patching.

WP_Object_Query has been moved to wp-includes/class-wp-object-query.php

Related: #15018, #15249

Initial Patch including the new filter

Added patch that includes the new filter in query.php (not within get_tax_sql function itself due to the lack of information the function is given like no access to $this)

Since get_tax_sql() is a method of WP_Object_Query, which is the parent class, you do have access to $this.

Why wouldn't passing $tax_query and $object_id_column to the filter be enough?

If it has access to $this, then that would be fine within the function. It was just a misunderstanding on my side.

'get_tax_sql' filter with context

context.15250.patch applies the 'get_tax_sql' filter, passing a context too.

I'm still concerned about what would happen if we decide we also need to alter the JOIN clause, for example.

Hm... well now with [16414] the terms are first transformed into term_taxonomy_ids, which I guess would need additional handling.

Perhaps we should see how things go in 3.1 before exposing the guts of get_tax_sql().

Agreed.

Why would we push this to another 3.x release if it's dependent on code that could change in 3.1, can't we just patch / implement once those dependencies are set in stone?

Which dependencies?

Also, no code is set in stone.

Dependencies would be whatever happens to get_tax_sql that @ryan brought up concerns with.

I think what ryan was trying to say is that we should wait to see how people use get_tax_sql() after 3.1 is released, before adding the filter.

I see that, but I also believe that losing out on implementing a filter out the gate means waiting a whole new dev cycle to be able to do things with core. The proposed filter applies to many needs by giving quite a bit of information to a function that wishes to extend the SQL generated by the function.

Please take another look at the code inside get_tax_sql(). It's quite different from what you made the patch against.

If you can give me an example that can efficiently leverage the filter you're proposing, i.e. without wasting queries made by _transform_terms(), I will commit it.

Will do, the patch was before a lot of things happened so I'll update today.

Updated patch for latest SVN Revision (16692)

Refreshing this patch w/ 3.5 trunk, updated filter args with ones now used

Refreshed this patch with the latest code from 3.5 trunk

Using apply_filters_ref_array() is not necessary anymore, since we dropped support for PHP 4. Can just use apply_filters().

Changing to use of apply_filters