[wp-trac] [WordPress Trac] #64390: get_adjacent_post() SQL changes can loop infinitely in Storefront/derivative theme code

WordPress Trac noreply at wordpress.org
Thu Dec 11 13:33:03 UTC 2025


#64390: get_adjacent_post() SQL changes can loop infinitely in
Storefront/derivative theme code
-------------------------------+------------------------------------
 Reporter:  jmdodd             |       Owner:  (none)
     Type:  defect (bug)       |      Status:  new
 Priority:  normal             |   Milestone:  6.9.1
Component:  Posts, Post Types  |     Version:  6.9
 Severity:  normal             |  Resolution:
 Keywords:  close 2nd-opinion  |     Focuses:  template, performance
-------------------------------+------------------------------------
Changes (by azaozz):

 * keywords:  close => close 2nd-opinion


Comment:

 Replying to [comment:3 ramonopoly]:

 > Do folks have any recommendations for making the changes in
 https://github.com/WordPress/wordpress-develop/pull/10394/files more
 defensive/plugin friendly?

 Seems there are couple things that can be done:

 1. What if we move the logic from this [https://github.com/WordPress
 /wordpress-develop/pull/10394/files#diff-
 b4070c4f94ed08fdcc78182a9941e3ff552a458744bcfb9eb33713c47d93fb02R1967-R1969
 new block of code] after the `get_{$adjacent}_post_where` filter? Same for
 [https://github.com/WordPress/wordpress-develop/pull/10394/files#diff-
 b4070c4f94ed08fdcc78182a9941e3ff552a458744bcfb9eb33713c47d93fb02R2013 the
 change] to the `$sort` in `get_{$adjacent}_post_sort`. I know it's not
 great to edit/tweak prepared SQL, but both of these filters expect plugins
 to do just that. (Ideally these filters should be deprecated, and replaced
 with something better. Hard on back-compat though.)

 2. As above, move the changes after the filters. But instead of tweaking
 the prepared SQL, check to see if a plugin has changed the defaults and
 leave it alone if yes. If not, redo the SQL with adding the post ID. This
 would be most backwards compatible but might miss some cases where a
 plugin would supply (old style) SQL that still has problems. That of
 course can be mitigated by (loudly) telling plugins authors about it :)

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


More information about the wp-trac mailing list