Performance Chat Agenda: 18 October 2022

Here is the agenda for this week’s performance team meeting scheduled for October 18, 2022, at 15:00 UTC.


This meeting happens in the #core-performance channel. To join the meeting, you’ll need an account on the Make WordPress Slack.

#agenda, #meeting, #performance, #performance-chat

Performance team meeting summary 11 October 2022

Meeting agenda here and the full chat log is available beginning here on Slack.

Focus area updates

Images

@adamsilverstein @mikeschroder

GitHub project

  • @adamsilverstein: Committed two small fixes related to the existing `image_editor_output_format` 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.#54476 and #56442
  • @mukesh27: Added checkbox to Settings > Media to control whether to generate JPEG in addition to WebP in #537
    • @flixos90: This is unlikely to ever make it into coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., but it is useful in the 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 to test either of the two behaviors
  • @ankitgade: Continuing to work on background processing infrastructure

Feedback requested

Object Cache

@tillkruess @spacedmonkey

GitHub project

  • @spacedmonkey: Published and helped with several dev notesdev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. for 6.1:
    • https://make.wordpress.org/core/2022/10/10/performance-improvements-to-the-rest-api/
    • https://make.wordpress.org/core/2022/10/10/multisite-improvements-in-wordpress-6-1/
    • https://make.wordpress.org/core/2022/10/07/improvements-to-wp_query-performance-in-6-1/
    • https://make.wordpress.org/core/2022/10/06/new-cache-site-health-checks-in-wordpress-6-1/
    • https://make.wordpress.org/core/2022/10/11/performance-field-guide-for-wordpress-6-1/
  • @spacedmonkey: Also merged https://github.com/WordPress/wordpress-develop/pull/3424 and https://github.com/WordPress/wordpress-develop/pull/3403 and need code review for https://github.com/WordPress/wordpress-develop/commit/832b6c35f36d5f1ca84feadc49b0e5424af0ad6c, which will add a new function to core called wp_cache_supports to allow object caches to support different functionality
  • @spacedmonkey: Been investigating the performance regression seen in Beta 2, particularly new caching issues in block themes – see https://github.com/WordPress/gutenberg/issues/44772 for details. PR in the works https://github.com/WordPress/wordpress-develop/pull/3418 that needs review ASAP before the RC1 cutoff.

Feedback requested

Site Health

N/A

GitHub project

  • We’re seeking 1-2 POCs for this group; if you’re interested, please comment here or pingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.
  • @mxbclang: Dev note for new Site Health checks has been published: https://make.wordpress.org/core/2022/10/06/new-cache-site-health-checks-in-wordpress-6-1/

Feedback requested

Measurement

N/A

GitHub project

  • We’re seeking 1-2 POCs for this group; if you’re interested, please comment here or ping in Slack

Feedback requested

JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/.

@aristath @sergiomdgomes

GitHub project

  • No updates

Feedback requested

Infrastructure

@flixos90

GitHub project

  • @flixos90: Our next release, 1.6.0, will be this coming Monday, October 17. Any feature or enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. that you want to include in this release should be completed and merged by tomorrow (Wednesday, October 12, see #548).

Feedback requested

Focus area updates

@flixos90

  • @flixos90: Three proposed changes that have come up in recent weeks to align focus areas. First is to introduce a new Database focus area; there are several module proposals (SQLite, optimized autoloaded options, database health checks) and some core optimizations that would also fit into this
    • @spacedmonkey: Should Object Caching and Database be the same?
    • @olliejones: Suggest keeping them separate
    • @flixos90: Don’t think so, some are pure database optimizations while sometimes object caching works around DB requests. I’d say adding caching around DB queries is still “Object Caching,” but there’s also room to improve some queries themselves and other DB issues
    • @spacedmonkey agrees
  • @flixos90: Second: We have a JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. focus, but there’s also a lot of work going on in GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ to improve CSSCSS Cascading Style Sheets. loading. Should we introduce a CSS area, or alternatively broaden the existing focus to be Assets (including CSS & JS)?
    • @mxbclang: Makes sense to me to broaden JS to both unless we have someone who is really interested in leading CSS
    • @spacedmonkey: Think they should be separate; if no one leads CSS, then it is not a “focus”
    • @mxbclang: That’s not entirely true; there’s some maintenance around designating something as a “focus,” e.g. having it on our weekly agenda, GH labels, updating the CODEOWNERS file, etc.
    • @olliejones: Is the scope of the JS focus intended to cover ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. apps and XHR/fetch performance?
    • @flixos90: FWIW the JS focus has barely made any updates here since it was established, but it’s a noticeable aspect of performance and some projects have been kicked off so would not want to remove it; @aristath has been quite involved with CSS though
    • @spacedmonkey: What does the JS focus mean right now?
    • @adamsilverstein: We do have some work around enabling better loading strategies for scripts that falls under JavaScript; I’ve been working on researching the benefits of using defer
    • @flixos90: Generally most of our focus is on website front-end performance, so the JS focus is also focused on front-end – things like deferring scripts, not loading JS that isn’t used, etc.
    • @spacedmonkey: How about a “Front-End” focus then?
    • @flixos90: Don’t think that would make sense, since everything we do is about front-end. Even DB queries and object caching improvements affect the front-end a lot. Let’s discuss later.
  • @flixos90: Last one: Suggest removing the Site Health focus – not because we shouldn’t work on Site Health, but more because any Site Health check actually fits into other areas and would be better suited as part of the other focus areas as opposed to it’s own area. There has not been a focus lead for Site Health, which is maybe another indicator that we should retire this area and consider checks to be part of other focus areas moving forward.
    • @spacedmonkey: So like an object caching-related Site Health check would be part of the Object Caching focus, right? Yes
    • @flixos90: Looking at our current SH modules:
      • Autoloaded options audit > Database
      • Enqueued assets > JS/CSS (TBD)
      • Full page cache > Object Caching
      • WebP support > Images
  • Vote on all through proposals here through Tuesday, October 18, 2022 at 1pm EDT: https://github.com/WordPress/performance/issues/554

Our next chat will be held on Tuesday, October 18, 2022 at 11am EDT in the #core-performance channel in Slack.

#core-js, #core-media, #performance, #performance-chat, #summary, #hosting-community

#meta

Performance Field Guide for WordPress 6.1

WordPress 6.1 introduces a number of important performance improvements which will have impact in all aspects. The most significant improvements are done in caching WP_Query as well as REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/..

Improvements to WP_Query

Database queries in WP_Query being cached is a long wanted feature for many developers and finally a dream come true in WordPress 6.1. A couple of new functions will ensure that users cache and linked objects for menu items are now primed while get_page_by_title function will from now on use WP_Query and take the full advantage of all these improvements.

TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets holding these changes: #22176, #55716, #55620, #36905.

Improvements to REST API

Priming caches in a single query will significantly improve Posts controller with several new helper functions but that’s not all. User and comments controller will benefit in a similar way while 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. and post type controllers are now going to prepare_links only when needed. This control over prepare_links method will be available for custom controllers as well.

Trac tickets holding these changes: #52992, #56019, #56020, #55592, #55593, #55620, #55674, #56272.

Site Health improvements

WordPress 6.1 will have two new Site Health checks – Persistent Object Cache and Page Cache, along with a number of new filters. Find out more in dedicated Dev notedev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase..

Trac tickets holding these changes: #56040, #56041.

Improvements to 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

In WordPress 6.1 the networknetwork (versus site, blog) options functions have been updated to be consistent with other metadata types, support for register_meta is added, prime caching network options in a single query, string main site ID in network options and more.

Trac tickets holding these changes: #37181, #55802.

Bootstrap/Load

The order of action 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. is slightly changed in order to gain more control over caching behavior, preloading assets and conditionally executing redirects.

Trac ticketticket Created for both bug reports and feature development on the bug tracker. holding these changes: #56068.

Improvements to Cache 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.

Cache API improvements bring validating cache keys in WP_Object_Cache methods, deleting cache by group and making a number of private cache priming functions public, and thus, available for usage in plugins and themes.

A valid cache key must be either an integer number or a non-empty string. This will prevent silent failing in wp_cache_*() functions, done by a quick type check and adding a _doing_it_wrong() message if the string is empty, false, or null. Also, a check in update_user_caches() and clean_user_cache() will make sure that the email is not empty before being cached or removed from cache. Read more in #56198.

Several private cache priming functions for various object types are now public 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 and theme authors are encouraged to use these functions to improve the performance of their code by reducing the number of database queries. These functions are:

  • _prime_post_caches()
  • _prime_term_caches()
  • _prime_comment_caches()
  • _prime_network_caches()
  • _prime_site_caches()
  • _get_non_cached_ids()

Read more in #56386.

Introducing wp_cache_flush_group() function

If you wanted to delete cached item with wp_cache_delete you had to specify the item’s ID, or you had to flush the entire cache with wp_cache_flush. WordPress 6.1 introduces a new plugable function called wp_cache_flush_group which removes all cache items in a group, if the object cache implementation supports it.

Introducing wp_cache_supports() function

Developers can now detect if their current implementation of an object cache supports flushing by group, by calling wp_cache_supports( $feature ) which returns true if the feature is supported. Third-party object cache plugins can declare a wp_cache_supports() function and correctly list their supported features:

  • add_multiple
  • set_multiple
  • get_multiple
  • delete_multiple
  • flush_runtime
  • flush_group

Note: The wp_cache_supports() function replaces and supersedes the wp_cache_supports_group_flush() function added in #4476.

Read more in #56605.

Media improvements

WordPress 6.1 will add decoding="async" to image attributes, along with new wp_img_tag_add_decoding_attr() function and wp_img_tag_add_decoding_attr 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.. Read more in #53232.

Query-attachments AJAX endpoint now caches the parent post objects. Read more in #56037.

WP_Media_List_Table class will call update_post_parent_caches function in order to prime parent caches in a single database request. Read more in #56036.

Added caching to wp_count_attachments() for better consistency with wp_count_posts(). Read more in #55227.

Avoid duplicated query when retrieving empty posts collections. Read more in #55677.

Post, Post Types improvements

In WordPress 6.1 WP_Posts_List_Table class will call update_post_author_caches function in order to prime post author caches in a single database request. Read more in #56100.

A new filter post_class_taxonomies will allow developers to reduce the number of taxonomies for which classes term classes are generated. Read more in #37114.

Sites running persistent object caching will have result of database queries in _find_post_by_old_slug and _find_post_by_old_date functions, cached. Read more in #36723.

Editor

Additional build task copy:block-json will convert and store all block.json files in a single blocks-json.php which will prevent all of this from happening for every 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. on each page load.

Trac ticket holding these changes: #55005.

Database

Identifiers (such as Table and Field names) are escaped with the %i placeholder which will prevent SQL Injection Vulnerabilities and provide a small performance improvement.

Trac ticket holding these changes: #52506.

Other performance improvements

Administration

Performance of WP_List_Table::get_column_info() is improved by adding the primary column to the cached headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. values (#34564).

Cron API

In 6.1 wp-cron will be non-blocking for LiteSpeed LSAPI (#54668).

Taxonomy

Retain default term option when unregistering taxonomies and adjustments to handling default terms for custom taxonomies (#54472).

Themes

Two new actions are wrapping the process of loading a template file (load_template) – wp_before_load_template and wp_after_load_template (#54541).

Script loader

New filter wp_preload_resources enables resource preloading with rel='preload' (#42438).

Users

Prime user 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. in WP_User_Query (#55594).

Thanks to @spacedmonkey, @tweetythierry, and @tillkruess for peer review.

#6-1, #dev-notes, #dev-notes-6-1, #field-guide, #performance

Moving the send_headers action to later in the load

As of WordPress 6.1, the send_headers hook has been moved to slightly later in the WordPress loading routine (ticket). Historically, all the is_ functions (like is_singular) wouldn’t work when you were determining which headers to send. With this change, moving `send_headers` to after WordPress parses the query, those functions now work properly.

People can now have more control over things like:

  • Managing caching behavior
  • Preloading assets with HTTPHTTP HTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. rel=preload headers
  • Conditionally executing redirects, and managing other non-200 status scenarios

Currently, these types of scenarios are often filtered in late actions like template_redirect; which is semantically confusing, and inefficient.

There’s a good example of code that becomes easier with this. In fact, it has already been changed in this ticketticket Created for both bug reports and feature development on the bug tracker.: the X-Pingback HTTP headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. only needs to be sent for posts, and can now be sent at the right time (commit).

Let’s see what it means in terms of load order:

Action sequence before this change

  • wp_loaded
  • parse_request
  • send_headers
  • parse_query
  • pre_get_posts — WP main query.

Action sequence after this change

  • wp_loaded
  • parse_request
  • parse_query
  • pre_get_posts — WP main query.
  • send_headers

This should not affect any of your existing code negatively unless you were using send_headers to do things that really should have been happening on wp_loaded or parse_request. So please check your code for that! If you were doing that, just changing to an earlier hook should fix your problem.

For new code, you can now happily use all the is_ functions.

Props to @jonoaldersonwp, @sergeybiryukov, @aristath, @milana_cap for reviewing this post.

#6-1, #dev-notes, #dev-notes-6-1, #performance

Performance improvements to the REST API

WordPress 6.1 brings a number of key improvements to the REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. to increase performance. These improvements decrease the number of database queries that are run on each REST API request. 

Avoid unnecessarily preparing item links

Prior to WordPress 6.1, the prepare_links method in the REST API was called in all controllers. If the _fields parameter is passed to the REST API request, it might mean that the links field is not requested and would never be returned in the response. This is wasteful, as prepare_links can contain database calls or other complex logic that would be run even if it never returned the response. 

In 6.1 prepare_links are only called if requested in the response, when links are requested in fields or the _embedded parameter is passed. As part of this work, the 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. and post type controllers have now been updated to implement said prepare_links method to bring them in line with other REST API controllers. 

This is the code example of implementing this change in custom REST API controllers.

Before

$response = rest_ensure_response( $data );
$links = $this->prepare_links( $post );
$response->add_links( $links );

return $response;

After

$response = rest_ensure_response( $data );

if ( rest_is_field_included( '_links', $fields ) || rest_is_field_included( '_embedded', $fields ) ) {
  $links = $this->prepare_links( $post );
  $response->add_links( $links );
}

return $response;

This logic conditionally calls prepare_links only if _links or _embedded is requested. This logic only applies when using the _fields query parameter. When not using _fields, links are included in the response as normal. 

For more info see TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker.: #52992, #56019, #56020

Improvement to the Posts controller

When running profiling tools against the responses of REST API requests, it was discovered that post controllers request a lot of linked data to each post. For example, when returning a post in a REST API response, linked data such as author (user), featured imageFeatured image A featured image is the main image used on your blog archive page and is pulled when the post or page is shared on social media. The image can be used to display in widget areas on your site or in a summary list of posts., and parent post were all requested. As these linked items were not primed in caches, it could mean that for each post in the REST API response there would be 3 separate database queries: one for the user, one for the featured image, and another for the parent post. 

In WordPress 6.1 all the caches are primed in a single database query and there are new helper functions to enable this:

update_post_author_caches

Takes an array of posts and primes users caches in a single query. 

update_post_parent_caches

Takes an array of posts and primes post parents in a single query. 

update_menu_item_cache

Takes an array of posts and primes post / terms link to menu items single query. 

The existing function update_post_thumbnail_cache was used to prime featured image caches. These functions are also being rolled out to other parts of the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. that can benefit from priming caches in a single place. 

For more info see Trac tickets: #55592, #55593, #55620    

Improvements to other controllers

The comments and user controllers have also been improved: User controller now primes user 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. in a single query and the comments controller now primes the linked post cache in a single query. Improvements were made to the post search controller to improve database performance along with the media controller. 

For more info see Trac tickets: #55674, #56272, #55677, #55716

Props to @flixos90 and @milana_cap for peer review and @mxbclang and @webcommsat for proofreading.

#6-1, #core-restapi, #dev-notes, #dev-notes-6-1, #performance, #rest-api

Multisite improvements in WordPress 6.1

NOTE: Due to issues reported in #56845, this enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. was reverted in r54637 and will not be included in the final 6.1 release. Work will continue in 6.2 and beyond. Please follow along in the original TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. Ticketticket Created for both bug reports and feature development on the bug tracker. (#37181)

Using the metadata 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. for networknetwork (versus site, blog) options

The way that network options are accessed is changing in WordPress 6.1. Network options have always been stored in a meta table called sitemeta. This name is confusing, as “site” in this context means “network,” not to be confused with blogblog (versus network, site) meta, used to store site metadata. Prior to WordPress 6.1, the functions get_network_option, add_network_option, update_network_options, and delete_network_option used custom database queries and caching. This resulted in some performance issues and lots of code to maintain.

In WordPress 6.1, the network options functions have been updated to use the more established metadata API, which is already used for metadata of other object types like posts, terms, and users. This effectively makes a function like get_network_option a wrapper around get_metadata. This has a number of advantages including:

  • Consistency with other metadata types
  • Support for register_meta functionality, such as default values
  • Improved cache priming 
  • Fewer database queries, as all network options are primed in a single request 

Along with these improvements, WP_Network_Query has a new parameter called update_network_meta_cache that allows for all networks in the query to prime the network options in a single query. 

One side effect of this change is that newly updated network options using an integer value may result in a string being returned. When using values like this with an integer comparison, it is important to allow cast to an int. In the old implementation, the second page load of the option would have resulted in returning a string. This change can be considered a fix but it is different from the current behavior. 

This change makes cache group site-options no longer in use and a candidate to be removed in future releases. 

For more information, visit Trac ticket #37181

Store main site ID of network in network options

When a 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 is created in WordPress 6.1, the main site ID on the network is stored in network options. As the main site on the network does not change in most cases, this is a value that can be stored for future reference. This saves a call to WP_Site_Query to look up the main site by domain and path in the bootstrap process which makes This lookup wasteful and not needed. This change also helps setup multiple networks, as noted above, since network options are primed in a single request. This means that when looking up multiple networks, the main site ID is now primed in along with other network options, resulting in fewer database queries / cache lookups. 

For more information, visit Trac ticket #55802

Thanks to @flixos90 and @milana_cap for peer review, and @mxbclang and @webcommsat for proofreading.

#6-1, #core-multisite, #dev-notes, #dev-notes-6-1, #multisite, #performance

Escaping Table and Field names with wpdb::prepare() in WordPress

This has been postponed to WordPress 6.2. See also Postponed to WP 6.2: Escaping Table and Field names with wpdb::prepare()

As part of the WordPress 6.1, wpdb::prepare() has been will be updated to escape Identifiers (such as Table and Field names) with the %i placeholder (#52506).

This ensures these values are escaped correctly and don’t lead to SQL Injection Vulnerabilities.

Example

$table = 'my_table';
$field = 'my_field';
$value = 'my_value';

$wpdb->prepare('SELECT * FROM %i WHERE %i = %s', $table, $field, $value);

// Output:
//   SELECT * FROM `my_table` WHERE `my_field` = 'my_value'

While this protects you against SQL Injection, where possible you should limit the values the user (attacker) can choose via an allow-list of trusted values; e.g.

$fields = array(
    'name'    => 'user_nicename',
    'url'     => 'user_url',
    'created' => 'DATE(created)',
  );

$sql .= ' ORDER BY ' . ($fields[$order_field] ?? 'user_login');

Performance Improvement

The change to add support for %i has a small performance improvement, as there is a little bit less Regular Expression work involved (generally the more parameters, the better the improvement).

In the Future

This was going to be released in WordPress 6.1, but a problem was identified in RC5 where the use of '%%%s%%' (which can often be seen in LIKE queries) stopped working. For reference, the documentation says “numbered or formatted string placeholders” will not have quotes added by this function (an old/unsafe feature), but this also happens when a placeholder immediately follows a “%”.

WordPress is looking to use %i in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. (#56091).

This change will help developers use the literal-string type for the $query parameter (this is where the $query is written as a developer defined string, and all user values are provided separately).

Props to @davidbaumwald for reviewing this dev notedev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase..

#6-1, #dev-notes, #dev-notes-6-1, #performance, #wpdb

Improved PHP performance for core blocks registration

WordPress 6.1 also comes with a considerable performance improvement for handling blocks in plugins and in the WordPress backend (PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher).

Early block.json Registration Method

Starting with WordPress 5.8, extenders were encouraged to begin to utilize block.json to register blocks through a unified registration process. The benefits offered by this update provide consistency and convenience when registering blocks through PHP or JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/..

However, while this block.json scanning convention is extremely convenient, it does add additional processing when coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. blocks are instantiated. On each page load, 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. registration undergoes the following steps:

  • Scan folders for block.json files.
  • When a block.json file is found, read its contents into memory.
  • Call json_decode on the file contents to convert it to a PHP array.
  • Register the block using the decoded data.

With over 70 core block files to scan and load, this presented an opportunity for optimization.

Core Block Registration Update

To reduce filesystem reads and processing of block.json files, which should benefit all WordPress sites and improve performance, block registration has been updated to:

  • Introduce a new Grunt task (copy:block-json) that scans and converts core block.json files to PHP arrays and stores them in a single blocks-json.php at build time.
  • Use the new blocks-json.php file in the register_block_type_from_metadata() function.
  • Assign the block registration data to a static variable (cache) so that it’s only loaded once per request.

The addition of an extra build task to compile the decoded 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. data to PHP reduces block registration filesystem reads from ~70 files to just a single file. And since blocks-json.php is a native PHP array, it can be used directly without additional conversion.

The conversion from block.json files to PHP arrays is achieved through the json2php package, which is already utilized in Core and GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/.

References

Props to @aristath for source material and collaboration, and to @milana_cap for review of this dev notedev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase..

#6-1, #dev-notes, #dev-notes-6-1, #performance

Performance Chat Agenda: 11 October 2022

Here is the agenda for this week’s performance team meeting scheduled for October 11, 2022, at 15:00 UTC.


This meeting happens in the #core-performance channel. To join the meeting, you’ll need an account on the Make WordPress Slack.

#agenda, #meeting, #performance, #performance-chat

Improvements to WP_Query performance in 6.1

Adding caching to database queries in WP_Query

WordPress 6.1 includes an improvement to how database queries are performed in the WP_Query class, resulting in database queries will be cached. This means that if the same database query is run more than once, the result will be loaded from cache. For those using persistent object caching, this will mean that the database query will not run again until caches are invalidated, resulting in far fewer queries to the database. Sites using in-memory caching will also see the benefit of not repeating these queries, though the performance improvement will not be as significant. 

For those doing custom development, please ensure that you are using coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. functions such as wp_insert_post to add posts to the database. These functions are well-maintained, and by using them, you ensure that caches are correctly invalidated. If you are updating the database directly, then it is strongly recommended that you call the clean_post_cache function after updating the database row. 

It is worth noting that by default, all calls to WP_Query will be cached going forward. It is possible to opt out of caching queries by simply passing the cache_results parameter as false. See example:

$args = array(
   'posts_per_page' => 50,
   'cache_results'  => false
);
$query = new WP_Query( $args );

It is also possible to globally disable caching, 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.:

function disable_caching( $wp_query ) {
   $wp_query->query_vars['cache_results'] = false;
}
add_action( 'parse_query', 'disable_caching' );

Disabling caching like this should only be done in extreme cases. For best performance, it is highly recommended to keep caching enabled and invalidate caches using the clean_post_cache function. 

Cache keys are generated using the parameters passed to the WP_Query class instance. However, the following parameters are ignored:

  • suppress_filters
  • cache_results
  • fields
  • update_post_meta_cache
  • update_post_term_cache
  • update_menu_item_cache
  • lazy_load_term_meta

These parameters do not affect the database query that is run. The most important ignored parameter is fields. This means that if you run the following: 

$args1 = array(
	'posts_per_page' => 50,
	'fields'  => 'ids'
);
$query1 = new WP_Query( $args1 );

$args2 = array(
	'posts_per_page' => 50,
	'fields'  => 'all'
);
$query2 = new WP_Query( $args2 );

In both cases, the query will now request all fields, so that the result can be cached and then be used regardless of the fields parameter. Prior to this change, the database query for those two was different, but keeping it like that would have resulted in multiple caches for effectively subsets of the same data. This means that there is now less of a performance improvement when limiting fields ids than there was in the previous version of WordPress. 

This change also means that the update_post_meta_cache and update_post_term_cache caches are always respected. 

In cases where caching was added to WP_Query by using plugins such as advanced-post-cache, Enhanced Post Cache or Cache WP_Query, it is recommended that these plugins are disabled and removed as they are no longer required.

For more info, see TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker. #22176

Prime users cache in WP_Query

WordPress 6.1 introduces a new function, update_post_author_caches. Prior to 6.1, sites with multiple authors required several single database queries to get author information, as the user is loaded as part of the loopLoop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop.. Instead of loading each user one by one, user (author) caches are now primed in a single database call by calling update_post_author_caches at the start of the loop, resulting in far fewer database queries. 

This function accepts an array of post objects and will prime user caches. Calls to update_post_author_caches have also been added in key parts of the codebase to improve database performance.

For more info, see Trac ticket #55716

Prime linked objects for menu items

A new function has been added to core called update_menu_item_cache. It accepts an array of post objects and will prime caches for post or terms referenced in a menu item. A new parameter for WP_Query has been added called update_menu_item_cache. When set to true it will call update_menu_item_cache which will allow you to prime menu items in a two database queries (one for posts and one for terms). 

For more info, see Trac ticket #55620

get_page_by_title now uses WP_Query

The function get_page_by_title now uses WP_Query. Previously,  this function used a raw database query to get the page by title. As noted above, WP_Query is now cached, meaning that calls to get_page_by_title will also be cached. This also has the benefit of running through all the filters in WP_Query

For more info, see Trac ticket #36905 

Thanks to @flixos90@milana_cap@peterwilsoncc for peer review and @mxbclang for proofreading.

#6-1, #dev-notes, #dev-notes-6-1, #performance