[wp-trac] [WordPress Trac] #56991: Update to get_page_by_title in 6.1 changes WHERE clause

[WordPress Trac]

#56991: Update to get_page_by_title in 6.1 changes WHERE clause
--------------------------+---------------------
 Reporter:  Bjorn2404     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  6.1.1
Component:  General       |     Version:  6.1
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:
--------------------------+---------------------

Comment (by peterwilsoncc):

 Having considered this for the last few days, I remain unsure of what is
 the best course of action here. There are no good choices.

 **The problem**:

 Without an ordering clause in 6.0 and earlier versions, it's basically
 been chance as to which post object is returned. The docblock describing
 the order has historically been inaccurate and different database engines
 or versions will optimize and order the query differently.

 Whether the function returns a public post has historically been left to
 chance.

 Even thought the new query specifies all post statuses (matching the
 previous behavior), some -- or possibly all -- database engines are
 optimizing the query differently and now returning a different post in
 some circumstances.

 **Possible solutions**:

 * close as `wontfix` and recommend developers use `WP_Query` when wishing
 to specify particular post statuses
 * break back-compat by querying only public post statuses (per pull
 request)
 * add a `post_status` parameter, either retain or change the default
 statuses searched
 * revert to previous wpdb query but add a cache to retain the performance
 gain by switching to `WP_Query`. Come back to this in 6.2 so a dev-note
 can be published with any changes in behaviour.

 With 6.1.1 scheduled for next week, at the time of writing, my inclination
 is to revert with a caching wrapper so WordPress Core developers can
 consider the best course for 6.2

 There are no optimal solutions so I think targeting the least-worst
 solution is the best that can be done on this ticket. In my view,
 maintaining backward compatibility is the least worst choice.

 I'll set up a PR.

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