[wp-trac] [WordPress Trac] #26937: get_adjacent_post() should use WP_Query rather than build its own SQL query

[WordPress Trac]

#26937: get_adjacent_post() should use WP_Query rather than build its own SQL query
-------------------------+-----------------------
 Reporter:  ethitter     |       Owner:  nacin
     Type:  enhancement  |      Status:  reopened
 Priority:  normal       |   Milestone:  3.9
Component:  Query        |     Version:  3.7
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:
-------------------------+-----------------------

Comment (by nacin):

 #27564 is another bug in this, caused by excluded terms. Fixing that also
 means our test coverage needs to be increased.

 As indicated in IRC when talking with kovshenin, at this point, I'm really
 concerned about this for 3.9. Let's face it, it's been a rabbit hole
 trying to get this fully backwards compatible. ethitter and I did not
 expect it to get this bad, and things like table aliases probably should
 have been the final straw. But we're also not just dealing with those
 kinds of bugs; we're also dealing with performance. For obvious reasons,
 WP_Query is slower than a raw query, but there are still some things we
 could do here to offset some of our losses — like a non-persistent cache
 so each adjacent link doesn't get re-queried (in the head then in the
 body, for example), which has always bothered me.

 Right now, though, this adds a solid 2-3ms to each request. Maybe this
 would be OK normally, but then there are also a number of late-blooming
 bugs. On top of that, this doesn't actually give us any benefit beyond the
 feel-good of using date queries of raw SQL. It allows for better
 manipulation via WP_Query filters but without query contexts (like #17019
 / #23833), it's tough to actually target them. And, the original
 justification was to do this for performance, but without actually
 bringing advanced post cache into core (#22176) we didn't actually gain
 anything — in fact, we lost a step.

 There are also other concerns like sites just breaking because some plugin
 didn't expect these WP_Query calls. (For example, poor use of
 pre_get_posts as cited in #27564, or something else.) That doesn't impress
 me much, but because we've been fighting with bugs for weeks on this, it's
 possible that developers didn't even notice these more subtle breakage
 points. That we only now noticed that excluded terms were broken
 definitely shakes my confidence that this will go smoothly in 3.9 final,
 given my past experience.

 So given all of this, and with ticket still open on the eve of the final
 beta, only days before what I hope to be an RC, and less than three before
 final release, it's all a pretty clear indicator of a revert-and-retry.

 ethitter and I agree it's time to revert this from 3.9 and move this
 ticket to future release. The good thing is, the long soak this got in 3.9
 has, presumably, allowed us to work out all or nearly of the kinks. I am
 happy to try this again in the future if the circumstances improve.

 I'd like to commend ethitter for working extra hard during beta to support
 this feature to get it to a shippable state. This ticket was a pretty
 herculean effort and we definitely didn't expect these challenges at the
 start, but I'm glad the whole effort was undertaken.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/26937#comment:52>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform