Support for handling resolution errors for Editor data module

WordPress 6.0 no longer ignores the exceptions thrown by the resolvers.

In WordPress 5.9 and earlier, an exception thrown inside the resolver kept it in the resolving state forever. It never got marked as finished. In WordPress 6.0, the resolver state is set to error and the exception is re-thrown. This backwards compatibility-breaking change affects both resolvers from newly registered stores and the resolvers from the WordPress stores, e.g. the getEntityRecord resolver from the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. store.

Example:

Let’s register an example store where the resolver always throws an error:

const temperatureStore = wp.data.createReduxStore( 'my-store', {
    selectors: {
        getTemperature: ( state ) => state.temperature
    },
    resolvers: {
        getTemperature: () => { throw new Error( 'Network error' ); }
    },
    reducer: () => ({}), // Bogus reducer for the example
} );
wp.data.registerStore( temperatureStore );

Using that resolver has different results in different WordPress versions:

In WordPress 5.9:

const promise = wp.data.resolveSelect( temperatureStore ).getTemperature();

Error handling is unsupported, so this promise never gets rejected nor resolved.

In WordPress 6.0:

const promise = wp.data.resolveSelect( temperatureStore ).getTemperature();

Error handling is now supported, so this promise gets rejected with Error( ‘Networknetwork (versus site, blog) error’ )

The error details may be retrieved using the hasLastResolutionFailed, getLastResolutionFailure, and `getResolutionState` metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress.-selectors available on every registered store:

wp.data.select( temperatureStore ).hasResolutionFailed( 'getTemperature' );
// the above returns: true

wp.data.select( temperatureStore ).getResolutionError( 'getTemperature' );
// the above returns: Error( 'Network error' )

wp.data.select( temperatureStore ).getResolutionState( 'getTemperature' );
// the above returns: { "state": "error", "error": Error( 'Network error' ) }

The state returned by getResolutionState is one of: “resolving”, “finished”, “error”, undefined. The undefined indicates that the resolver hasn’t been triggered yet.

PRs #38669 #39317

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

Theme export in WordPress 6.0

The “Export” feature in the Site Editor has been improved so that now you can export your whole theme, including all the edits you have made to your templates and styles. Previously the export function only gave you access to your template files. This change makes it possible to build a blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. theme using the site editor and easily share the zip file with anyone.

The Export process

The export process copies all files from the current theme into a zip file. Then it extracts the template changes that are stored in the database to files and adds them to the zip file. If these templates have the same names as those in the theme, they will be overwritten, so that the database version takes precedence. The same process happens for the theme.json file. There are three directories that are excluded from the export: .git, node_modules and vendor.

Unexpected changes

The export process may make a few unexpected changes to your templates and theme.jsonJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. files.

  1. The output of template files from the database will be sanitized for security reasons. You’re most likely to notice this with any CSSCSS Cascading Style Sheets. variables in your template files: e.g. --wp--custom--spacing--outer would become \u002d\u002dwp\u002d\u002dcustom\u002d\u002dspacing\u002d\u002douter.
  2. The properties in theme.json are now sorted alphabetically, so the first time you export you might notice some of the objects in your theme.json move position. This now gives us a standard order for these properties so in future it will be easy to know where everything should go.
  3. The schema may be updated – the export will update your theme.json schema to match the version of WordPress you are using, so if you theme was created with an older version of WordPress, the schema will be updated to match the version you are on.

How to submit a theme

Once you have your exported theme, you may need to make several changes before you can submit it to the theme repository.

  1. The screenshot will need to be updated, if you’ve made any visual changes to the homepage.
  2. You will have to add a changelog entry to the readme.txt file.
  3. You must update the version number of the theme in style.css.
  4. If this is a new theme, based on an existing theme, you will also need to update the name.
  5. If the theme doesn’t have a license file already you will need to add one.
  6. You will then need to rezip the theme with these changes.
  7. You can now submit the new zip file to https://wordpress.org/themes/getting-started/.

For more info see:

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

New features for working with patterns and themes in WordPress 6.0

WordPress 6.0 brings three new features to Themes to offer site owners patterns. Register selected patterns from the public pattern directory, add theme patterns to a separate folder /patterns, and add patterns that can be offered to use when creating a new page. 

Pattern registration from Pattern Directory for themes

With WordPress 6.0 themes can easily register patterns from Pattern Directory through theme.json. To accomplish this, themes should use the new patterns top level key in theme.json.

Within this field, themes can list patterns to register from Pattern Directory. The patterns field is an array of pattern slugs from the Pattern Directory. Pattern slugs can be extracted by the url in single pattern view at the Pattern Directory. 

Example: This url https://wordpress.org/patterns/pattern/partner-logos the slug is partner-logos.

{
    "version": 2,
    "patterns": [ "short-text-surrounded-by-round-images", "partner-logos" ]
}

Noting that this field requires using the version 2 of theme.json.

The content creator will then find the respective Pattern in the inserter “Patterns” tab in the categories that match the categories from the Pattern Directory.

Place Patterns in the subfolder /patterns of your theme

Themes can now define blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. patterns as files in the /patterns folder:

devnotes-patterns-directory

Each pattern file consists of a set of 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-style headers followed by the pattern’s actual source:

<?php
 /**
  * Title: Hello
  * Slug: my-theme/hello
  * Categories: featured, text
  */
?>
<!-- wp:heading -->
  <h2>Hello</h2>
<!-- /wp:heading -->

Motivation

While all themes benefit from this APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways., it is especially convenient for block themes, where conventional folders like templates, template-parts and now patterns reduce the role of functions.php as a control structure. This API also paves the way for any future theme-editing tools that integrate with the block editor.

Note that this is not a breaking change. Much like plugins, themes have been able to register block patterns since the introduction of register_block_pattern() in WordPress 5.5, and that interface is not expected to change.

Observations

  • For now, the only format supported for these files is PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher. While a simpler HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. format has been considered, PHP offers theme developers an escape hatch, should the pattern have any special content that dynamic blocks haven’t yet absorbed. For instance:
<img src="<?php echo esc_url( get_template_directory_uri() ); ?>/assets/hello.png">
  • As a general reminder, these PHP blocks are only run upon loading the block editor in order to compute the patterns. Once inserted into a post, patterns are static.

Supported fields

  • Title (required) (implicitly translatable)
  • Slug (required)
  • Description (implicitly translatable)
  • Viewport Width
  • Categories (comma-separated values)
  • Keywords (comma-separated values)
  • Block Types (comma-separated values)
  • Inserter (yes/no)

Props to @ntsekouras.

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

Object type specific registration hooks in 6.0

If you’ve ever worked with post types in WordPress, chances are you’ve used register_post_type_args 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. where you had to perform post type check. In WordPress 6.0 you won’t have to do that any more as new object type hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. are introduced.

Similar to other dynamic hooks, these will allow you to directly hook into your custom post types and custom taxonomies.

New filters:

  • register_{$post_type}_post_type_args – Filters the arguments for registering a specific post type.
  • register_{$taxonomy}_taxonomy_args – Filters the arguments for registering a specific taxonomyTaxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies..

New actions:

  • registered_post_type_{$post_type} – Fires after a specific post type is registered.
  • registered_taxonomy_{$taxonomy} – Fires after a specific taxonomy is registered.

For more info see #53212.

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

Media: storing file size as part of metadata

In #49412 a tweak was made to the upload process. When files are uploaded to the WordPress media library, the file’s size is now stored as part of the metadata. This means that when calling the wp_get_attachment_metadata function, developers will easily be able to receive the file size of a selected image without having to call the php function filesize. This change is especially useful in situations when media is being offloaded to a third party, such as cloud services like Amazon’s S3 and Google cloud storage or a networknetwork (versus site, blog) share like NFS; as a call to get the file’s size can result in slow calls to an external server. 

Along with saving the file size to the attachment’s metadata, a new function and 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. have been added. The new wp_filesize function is useful when storing attachments on a third party source. It means that value can be filtered, preventing a possibility of a slow call to an external server. 

It is recommended that authors and maintainers of plugins designed to offload attachments to external services review this change and check that it does not affect your 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.

Props to @milana_cap for review and proofreading.

#6-0, #dev-notes, #dev-notes-6-0, #media

Performance increase for sites with large user counts (now also available on single site)

In WordPress 6.0, websites with more than 10,000 users will see improvements in handling users. Prior to changes in #38741, sites with more than 10,000 users would suffer from slow page loading time in the user and post list screens. 

The user screen was slow because a complex SQL query was run to get the number of users for each role. This sometimes resulted in page timeout or failures to load. On the post edit screen, a dropdown of authors in the quick edit option used to change the post’s author. On large sites, this results in thousands of options rendered on the page, which creates a large amount of markup and causes timeouts and slowdowns. 

Introducing large sites

The idea of a large networknetwork (versus site, blog) in multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site configurations of WordPress has existed since WordPress 3.0. A network is considered large when it has over 10,000 users. When marked as such, any real time calculation of the number of users is skipped and all counts of users are deferred to scheduled (cron) events. 

This idea of a large network has now been ported to single site installs of WordPress. Any site with more than 10,000 users is marked as large. Once this threshold is met, real time counts, such as ones noted above, no longer occur on every page load. This means that when viewing user lists, the count next to each user role will be missing. This massively improves the performance of the page page load and prevents slow database queries causing PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher timeout errors, which in turn helps ensure the user list renders every time on large sites. 

This change includes some new functions:

  • get_user_count
    Now available for both single- and multi-site installations. For sites with over 10,000 users recounting is performed twice a day by a scheduled event. 
  • wp_update_user_counts
    Perform a user count and cache the result in the user_count site option. 
  • wp_is_large_user_count
    Determines whether the site has a large number of users. The default threshold of 10,000 users can be modified using a 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. of the same name.

Now that the get_user_count is available for both single and multisite, it is strongly recommended not to use the count_users function in your code. This function is not performant and is the root cause of issues noted above. Wherever possible, every instance of count_users in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. has been converted to use get_user_count, which is also recommended action for 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 authors. 

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

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

WP_User_Query now accepts fields options in WordPress 6.0 

Prior to the WordPress 6.0 release the function WP_User_Query would only accept ID and all_with_meta/all in the fields parameter.

The change

You can now pass any of these options in the field parameter and get the associated values back

  • ‘ID’
  • ‘display_name’
  • ‘user_login’
  • ‘user_pass’
  • ‘user_nicename’
  • ‘user_email’
  • ‘user_url’
  • ‘user_registered’
  • ‘user_activation_key”
  • ‘user_status’

    and for a multi site also
  • ‘spam’
  • ‘deleted’

The following return WP_user objects in an array

  • ‘all’ – default,
  • ‘all_with_meta’

Example

Code like this:

$users = get_users( ['fields' => 'display_name'] );

Will now return values like this

Array ( 
  [0] => Jack 
  [1] => jb 
  [2] => momo 
  [3] => Roberta
)

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

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

Caching improvements in WordPress 6.0

As part of the release of WordPress 6.0, the new Performance team has been working on several improvements to the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. There are a few new additions to the WordPress Caching APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways..

Batch API methods for Cache Operations (wp_cache_*_multiple)

The function wp_cache_get_multiple() was added in WordPress 5.5. This allowed for multiple cache keys to be collected in just one request. To complete this API, a full CRUDCRUD Create, read, update and delete, the four basic functions of storing data. (More on Wikipedia.) was needed and has been added via the following functions:

  • wp_cache_add_multiple
  • wp_cache_set_multiple
  • wp_cache_delete_multiple

All of these functions accept an array of data to be passed so that multiple cache objects can be created, edited, or deleted in a single cache call.

In WordPress core, these are just wrappers for core functions to allow multiple keys to be passed in one function call, but this would also allow object caching drop-in developers to implement them if their back-end supports it.

Example usage of wp_cache_add_multiple( $data, $group = '', $expire = 0 )

  • $data: Array of key and value pairs to be added.
  • $group: Optional. String. Where the cache contents are grouped. Default ”.
  • $expire: Optional. Int. When to expire the cache in seconds. Default 0 (no expiration).
wp_cache_add_multiple( array( 'foo1' => 'value1', 'foo2' => 'value2' ), 'group1' );

Example usage of wp_cache_delete_multiple( $data, $group = '' )

  • $data: Array of keys to be deleted.
  • $group: Optional. String. Where the cache contents are grouped. Default ”.
wp_cache_delete_multiple( array( 'foo1', 'foo2' ), 'group1' );

Example usage of wp_cache_set_multiple( $data, $group = '', $expire = 0 )

  • $data: Array of key and value pairs to be set.
  • $group: Optional. String. Where the cache contents are grouped. Default ”.
  • $expire: Optional. Int. When to expire the cache in seconds. Default 0 (no expiration).
wp_cache_set_multiple( array( 'foo1' => 'value1', 'foo2' => 'value2' ), 'group1' );

With these additions, some additional core refactoring has been done to utilize these new functions. See more details in TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. #55029.

Allow runtime cache to be flushed (wp_cache_flush_runtime)

As discussed in the Performance issue #81 and Trac #55080, Core needed a way to allow users to flush the runtime (in-memory) cache without flushing the entire persistent cache.

This feature was often requested for instances where long-running processes such as Action Scheduler or WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/ are run.

Example usage of  wp_cache_flush_runtime()

$counter = 0;
foreach ( $posts as $post ) {
	wp_insert_post( $post );
	if ( 100 === $counter ) {
		wp_cache_flush_runtime();
		$counter = 0;
	} 
	$counter++;
}

The above example would reset the runtime cache after 100 posts are inserted into the database.

Thanks to @shetheliving, @milana_cap, @costdev, @webcommsat, and @spacedmonkey for peer review.

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

Taxonomy performance improvements in WordPress 6.0

As part of the 6.0 release of WordPress, the new performance team has been hard at work to improve the performance of term queries. There are many term queries on the average page load and improving these improves the performance of WordPress in general. 

Improvement to term query caching. 

Queries run by WP_Term_Query have been cached since 4.6. The way these caches are primed and handled has been improved in WordPress 6.0.

Removing to cache limit

Prior to WordPress 6.0, term query caches were limited to a 24-hour period for those using persistent object caching. This limitation is now removed, so if caches are not invalidated, it means that term query should cache much longer. For inactive sites or overnight, caches should remain primed, which should improve site performance. 

For more information, see #54511.

Term query cache only caches the term ID

Term query caches have been changed so that instead of caching the whole term object, now only the term IDs are cached. This means that the value stored in cache will be much smaller (in terms of memory) and will not fill up memory in session or persistent object cache.

Once all the IDs for the terms are loaded, the _prime_term_cache function is called. This loads into memory terms that are not already in cache. If the term is already in memory, then it is not loaded again, which is a performance benefit. On an average page load, a term may be requested multiple times, like the case of a tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) archive page. Early in the page load, get_term_by, will prime the term cache and all other calls, such as get_the_terms, will have the term already primed in page memory. This results, in most cases in fewer and smaller queries that are run against the term table. 

For more information, see #37189.

Improved term query cache key generation

Previously, similar term queries that have similar cache keys would result in basically the same query being run twice on a single page load. Because all queries now only get the term ID and store it in cache (see above), the cache exactly the same. For example, you create a call to get_terms where you request all categories and return only the field slug. If you do the same query and request only the name, then this would hit the same cache.

Another improvement is the handling of parameters that can be passed to WP_Term_Query that can be ambiguous. Fields like slug that can be either a string or an array are now converted to always be an array, meaning that the likelihood of reusing a cache is higher as the cache key is the same, no matter which type of parameter is passed. 

For more information, see #55352.

Improve performance for navigation menuNavigation Menu A theme feature introduced with Version 3.0. WordPress includes an easy to use mechanism for giving various control options to get users to click from one place to another on a site. items

Convert wp_get_nav_menu_items to use a taxonomyTaxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies. query

This replaces usage of get_objects_in_term function with a simple taxonomy query. This replacement converts the use of two queries to get the menu items to use one simple query. This saves one query for each menu requested and adds consistency. 

For more information, see #55372.

Prime all term and posts caches in wp_get_nav_menu_items

The wp_get_nav_menu_items function now calls _prime_term_cache and _prime_post_cache for all objects linked to menu items. If a menu contains a list of categories and pages, all the related objects are now primed in two cache calls (one for terms and one for posts). This will result in far fewer requests to the database and cache.

For more information, see #55428.

Convert term_exists to use get_terms

The function term_exists has now been converted to use get_terms ( WP_Term_Query ) internally replacing raw uncached database queries. This function was one of the last places to perform raw queries to the terms table in the database. Using the get_terms function has a number of key benefits, including: 

  • Consistency with other coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. functions like get_term_by
  • The ability to 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. the results.
  • Results of get_terms are cached 

term_exists is designed for back-end use and is mostly used in core functions designed to write data to the term table. However, term_exists can and is used by some theme and 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 developers. This results in raw uncachable and unfilterable queries to be run on the front-end of a site. 

Now that term_exists is cached, custom import / migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. tools may need to check if they correctly cache invalidation terms. If your importation code is using core functions like wp_insert_term, then there is no need to do anything, as core does its own cache invalidation for you. However, if you are writing data to the term table manually, then you may need to call the clean_term_cache function. 

For those that need to ensure that term_exists is getting an uncached result, there are two ways to do this:

  1. Using the new term_exists_default_query_args filter 
$callback = function ( $args ) {
   $args['cache_domain'] = microtime();
};
add_filter( 'term_exists_default_query_args',  $callback );
$check = term_exists( 123, 'category' );
remove_filter( 'term_exists_default_query_args',  $callback );
  1. Using wp_suspend_cache_invalidation
wp_suspend_cache_invalidation( true );
$check = term_exists( 123, 'category' );
wp_suspend_cache_invalidation( false );

For more information, see #36949.

Add a limit to taxonomy queries

The ​​WP_Tax_Query class is used in WP_Query to limit queries by term. Under the hood, ​​WP_Tax_Query uses ​​WP_Term_Query, which means that ​​WP_Tax_Query will get the benefits of the cache improvements documented above. The ​​WP_Tax_Query run, which transforms term slugs / names into term IDs to be queried, now has a limit added to it. This query limit improves the performance of the query, as well as improves the likelihood of an existing cache query to continue to exist in the object cache. For example, a standard tag archive calls get_term_by and primes the cache. By the time it gets to the ​​WP_Tax_Query, that query is being loaded from cache. This removes one query per tag archive page. 

For more information, see #55360.

Props to @milana_cap, @shetheliving, @flixos90 for peer review.

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

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