[wp-trac] [WordPress Trac] #56991: Update to get_page_by_title in 6.1 changes WHERE clause
WordPress Trac
noreply at wordpress.org
Tue Nov 8 00:21:43 UTC 2022
#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 TimothyBlynJacobs):
Replying to [comment:14 peterwilsoncc]:
> close as wontfix and recommend developers use `WP_Query` when wishing to
specify particular post statuses
This makes the most sense to me in my opinion.
> break back-compat by querying only public post statuses (per pull
request)
I agree this would be a BC break.
> add a post_status parameter, either retain or change the default
statuses searched
I'm generally not a fan of these one of functions to begin with. The DUX
of `WP_Query` is sufficient to point users to it if they want to do a more
customized query instead of adding multiple function parameters to
customize behavior.
> 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.
If we revert, I think we should just do a clean revert. Not try and add in
separate caching behavior in a minor release.
----
We could also potentially not set a `limit` of `1` result, and instead try
to return the first post with a publicly queryable post status. If there
are none, then we'd just return the first result. This should keep the
desired behavior for the reporter, but also allow private posts to be
returned if that is the only match.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/56991#comment:23>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list