Changes to do_parse_request filter in WordPress 6.0

Prior to the WordPress 6.0 release pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party and theme developers used the do_parse_request filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. to hot-wire requests and hook in early to render custom pages. Not needed post queries and 404 lookups were still run. This resulted in unnecessary SQL queries running on these requests.

The change

In 6.0 we added a return value to the parse_request method of the WP class. These queries are not needed and now skipped if false is returned by the do_parse_request filter.

We encourage developers to update their code run by the filter  do_parse_request to return false if they are handling the request in their code.

Example

In the simplest filter:

add_filter( 'do_parse_request', '__return_false' );

But you might want to check for a parameter before returning:

function wporg_add_custom_query( $do_parse, $wp, $extra_query_vars ) {
    if ( 'CUSTOM_VALUE' === $extra_query_vars['custom_arg'] ) {
        return false;
    }

    return $do_parse;
}

add_filter( 'do_parse_request', 'wporg_add_custom_query', 10, 3 );

Props to @sergey, @kkautzman, and @milana_cap for review and proofreading.

#6-0, #dev-notes, #dev-notes-6-0, #performance