[wp-trac] [WordPress Trac] #56689: Use WP_Query in get_page_by_path
WordPress Trac
noreply at wordpress.org
Fri Feb 3 18:43:12 UTC 2023
#56689: Use WP_Query in get_page_by_path
-------------------------------------------------+-------------------------
Reporter: spacedmonkey | Owner:
| spacedmonkey
Type: defect (bug) | Status: closed
Priority: normal | Milestone:
Component: Query | Version: trunk
Severity: normal | Resolution: wontfix
Keywords: needs-testing has-patch has-unit- | Focuses:
tests has-testing-info 2nd-opinion | performance
-------------------------------------------------+-------------------------
Comment (by SergeyBiryukov):
Replying to [comment:24 Otto42]:
> I believe that would still trigger the loop.
>
> The problem is the `pre_get_posts` filter is one that may be used for a
lot of different things. In this particular circumstance, it is being
called and then calling `get_page_by_path`. If this function calls a new
WP_Query, that's going to, once again, call the `pre_get_posts` filter.
And that's where the loop is.
Ah yes, you're right, it never gets to the point where `wp_cache_set()` is
called, so `wp_cache_get()` doesn't work.
> One way around it would be to disable the filter on creation of the
WP_Query. However, there's not natively a way to do that, and potentially
other filters could produce similar results as well.
Yeah, this avoids the loop in my testing, though having a `WP_Query`
argument to skip `pre_get_posts` and any other hooks that still run with
`'suppress_filters' => true` would be much better:
{{{
if ( doing_action( 'pre_get_posts' ) ) {
$original_wp_filter = $wp_filter;
unset( $wp_filter['pre_get_posts'] );
}
$query = new WP_Query( $args );
$posts = $query->get_posts();
if ( isset( $original_wp_filter ) ) {
$wp_filter = $original_wp_filter;
}
}}}
--
Ticket URL: <https://core.trac.wordpress.org/ticket/56689#comment:25>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list