Use WP_Term_Query to fetch a post's terms.
#2780
Conversation
Previously, when the 'post' parameter was passed to a terms collection query, the `get_terms_for_post()` method was used, in order to leverage the WP's taxonomy relationship cache. In WordPress 4.7, object-term queries are natively cached, so the API-specific workaround can be removed. See WP-API#2740.
|
Another note: this PR includes #2779, since the offending code addressed in that ticket is removed altogether here. Apologies for the crossed streams. |
I think we should do whatever you think is best, and put our best foot forward. We've made breaking changes in the past, so I don't see that as a problem. |
|
@boonebgorges does this mean we no longer get the object caching on a post's terms? |
Thinking more about it: As a plugin author, I'd expect that my plugin filtering
No. I see that the PR is no longer applying properly because of #2779. I'll fix and resubmit. |
|
I've updated the PR:
The last item required a core bugfix, so the test will only pass against WP trunk https://core.trac.wordpress.org/changeset/38784 |
| $found_2 = wp_list_pluck( $response->data, 'id' ); | ||
|
|
||
| $this->assertEqualSets( $found_1, $found_2 ); | ||
| $this->assertSame( $num_queries, $wpdb->num_queries ); |
There was a problem hiding this comment.
This is currently failing in the tests.
There was a problem hiding this comment.
@rmccue this is the test Boone indicated would only pass against trunk; are we using trunk in our test suite?
This patch looks good to me, other than I wonder if we can gate this test somehow for now.
|
Hmm this is causing more issues, as the WP_Term_Query changes in 4.7 are making backwards compatibility for 4.6 break in several places. It's not just the new unit test that fails under 4.6, we have others ones too, which the change to using WP_Term_Query. I feel like we should be supported the latest release of WordPress, and right now that means supporting 4.6, so I'm -1 on merging this right now. |
|
Tests were passing locally for me with WP nightly. Not sure why it's failing on Travis. I'll look into it more carefully.
@joehoyle When you say that "the change to using |
|
@boonebgorges right, it's (b), sorry for not being clear. this isn't a backwards compat issue for core, it's because with this PR, we are switching old code to WP_Term_Query even under 4.6, but expecting it to do the same things as under 4.7, which isn't the case, of course. It makes sense for this to be merged if we merge the API into core, as that code can then of course be dependant on 4.7, however as it stands right now, I'd rather not release another beta of the plugin a couple of days and break things for sites on 4.6 using the plugin. |
|
FYI tests do pass on nightly. |
|
Thanks, @joehoyle. I asked in Slack a couple days ago about your policy regarding fixes that depend on core patches, but didn't get a response :) Your policy sounds fine to me. Tests don't seem to be passing on all versions of PHP. See eg https://travis-ci.org/WP-API/WP-API/builds/167090500. I don't understand why. There could be a race condition or something that's causing a cache miss (hard to believe that our tests are not bulletproof, I know) |
|
I think those tests were failing due to running on Nightly too early, I re-ran them and they all pass now. |
|
I think that's called an "external race condition" |
|
Marking this "blocked on core" since it depends on 4.7; maybe an over-extrapolation of the ticket but feels right :) |
|
I've migrated to Trac. https://core.trac.wordpress.org/ticket/38504#ticket |
See #2740.
The most parsimonious approach would've been to replace the
get_terms()call withnew WP_Term_Query, with the 'object_id' argument set to the value of$request['post']. But this would be a change in behavior for the term controller, since it'd mean bypassing the 'get_terms' filter. If we're sticking with the 'get_terms' filter, it seems consistent to usewp_get_object_terms()for object-specific queries, which is what I've done in this PR. Feedback welcome on this decision.