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

WordPress Trac noreply at wordpress.org
Tue Mar 18 23:45:51 UTC 2014


#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:  has-patch    |     Focuses:
-------------------------+-----------------------

Comment (by ethitter):

 Replying to [comment:31 ethitter]:
 > I'm reviewing the backwards compatibility issues with the `WHERE` filter
 [comment:21 noted by Kovshenin].

 I can't believe I overlooked this detail. :(

 The old filter passed the entire clause
 ([https://core.trac.wordpress.org/browser/tags/3.8.1/src/wp-includes/link-
 template.php#L1183 ref]), with the `WHERE` prefixed, whereas `WP_Query`
 doesn't include the `WHERE` in the filters I used since it's added later
 on in the process of building the final query
 ([https://core.trac.wordpress.org/browser/trunk/src/wp-
 includes/query.php?rev=27511#L3189 ref]).

 One option is to use the `posts_request` filter instead, which is applied
 to the final query, to split the query out to the three pieces needed for
 the old filters: `JOIN`, `WHERE` (including `GROUP BY`), and `ORDER BY`
 (including `LIMIT`). I'm not keen on the additional string manipulation
 that this would require, as it increases the room for error when mapping
 the legacy filters' return values back to the relevant `WP_Query` filters.

 Another possible solution, and the one I'm inclined towards, is to simply
 prepend `WHERE 1=1` to the relevant clause as it goes to the legacy
 filter, and strip out any `WHERE` that the filter returns, while also
 ensuring the filter's return value starts with `AND` as it does initially
 in `WP_Query`. This approach requires considerably-less string
 manipulation, which seems a plus given there's already enough of that in
 the `filter_sort()` method.

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


More information about the wp-trac mailing list