Postponed to WP 6.2: Escaping Table and Field names with wpdb::prepare()

Support for %i to escape Table and Field names was postponed to 6.2, see:
https://make.wordpress.org/core/2022/10/08/escaping-table-and-field-names-with-wpdbprepare-in-wordpress-6-1/

A problem was found during RC5, where some extensions use field LIKE "%%%s%%", and expect the %s to remain unquoted.

This is undocumented behaviour. Officially the only time placeholders should not be quoted (for backwards compatibility reasons) is when using numbered or formatted string placeholders (this is unsafe, and should be avoided).

In this case, the first %% results in a literal "%", but this goes on to affect the %s.

For reference, developers should rely on wpdb::prepare() to quote all variables, so mistakes cannot be made. In this case it’s recommended to use something like the following:

$wpdb->prepare( 
     'field LIKE %s', 
     '%' . $wpdb->esc_like( $var ) . '%' );

Thanks to @AlanP57 for reporting, @hellofromtonya and @sergeybiryukov for reverting the patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing., @azaozz and @bph for helping document this, and everyone else for generally helping out.

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

Block API changes in WordPress 6.1

WordPress 6.1 introduces several new 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. 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. features available via the block.json file.

As a recap, the block.json file was introduced in WordPress 5.5 and has been encouraged as the canonical way of registering block types since the WordPress 5.8 release. Many of the recent Block API features, including the ones in this post, depend on block.json being available on the server.

PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher templates for rendering blocks

Before WordPress 6.1, the main output of a block would often be generated in either a 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/. save function, or in a PHP render_callback function.

WordPress 6.1 adds a third way: a separate PHP template file. The path can be specified via the render property of block.json:

{
    "render": "file:./render.php"
}

If you don’t have a render_callback setting specified, then the template is used instead. It behaves similarly, but feels much more like traditional WordPress template handling.

The template path is prefixed with file: and relative to the location of the block.json file, following the npm specification.

The render.php template could look like this:

<p <?php echo get_block_wrapper_attributes(); ?>>
    <?php esc_html_e( 'Hello from a dynamic block!', 'my-plugin' ); ?>
</p>

Note: The entire file is used as a template, so there’s no need to define additional wrapping functions.

The following variables are available inside the template:

  • $attributes (array): The block attributes.
  • $content (string): The block default content.
  • $block (WP_Block): The block instance.

Use multiple scripts per block

The WordPress 6.1 version enables defining multiple script files in all relevant block.json entries: editScript, script, and viewScript. (Trac #56408) It’s now possible to pass a script handle registered with the wp_register_script function, a path to a JavaScript file relative to the block.json file, or an array with a mix of both:

{
    "editorScript": "file:./index.js",
    "script": "file:./script.js",
    "viewScript": [ "file:./view.js", "example-shared-view-script" ]
}

WordPress maintains a degree of backwards compatibility by passing along only the first (string) item to any existing code working with these values.

Note: Processing a single string requires a different code than processing an array of strings. Therefore, the WP_Block_Type class and the /wp/v2/block-types 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/. endpoint deprecate accessing string values through their old names: editor_script, script, view_script, editor_style, and style.

The full array of scripts can be accessed via the following new properties of the WP_Block_Type class and the /wp/v2/block-types REST API endpoint:

  • editor_script_handles,
  • script_handles,
  • view_script_handles,
  • editor_style_handles, and
  • style_handles.

Furthermore, the scripts and styles registered in block.json will automatically be loaded for static and dynamic blocks in WordPress 6.1. Previously, the dynamic blocks were expected to register their assets.

Combined with the support for multiple stylesheets per block shipped with WordPress 5.9, this change enables developers to use multiple entries for all supported asset types.

Import individual coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. blocks from @wordpress/block-library

The import of individual core blocks (Pull request #42258) from the @wordpress/block-library npm package was enabled to help developers reduce the bundle size of their applications. Prior to this change, the use of a single core block required pulling in the entire set.

Individual core blocks can be imported in three different ways:

// You can import and automatically register the block:
import '@wordpress/block-library/build-module/verse/init';

// Or you can automatically register the block and reuse the reference:
import verseBlock from '@wordpress/block-library/build-module/verse/init';

// Or you can import the init function without registering the block…
import { init } from '@wordpress/block-library/build-module/verse';

// …and then register the block when needed:
const verseBlock = init();

Props to @gziolo, and @revgeorge for technical review, to @bph and @webcommsat for final review.

#6-1, #dev-notes, #dev-notes-6-1, #developer-documentation

Content only editing and other locking updates

WordPress 6.1 comes with content-only editing for blocks, patterns, and templates, as well as a template lock inheritance for the Column 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..

Almost any layout using the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. blocks can be composed and shared as a pattern. End users may have found they could accidentally break these layouts or use them in an unexpected way. Previously, the experience of using patterns was not on par with having a specific block for a complex layout.

With WordPress 6.1, a new experimental type of locking has been added called “contentOnly”. This locking method can be used by any pattern or block. When enabled, the users can only change the nested content inside the block/pattern. The block structure starts behaving as a single unit where the block hierarchy is entirely hidden. The user can only change text and media URLs in the blocks. 

Additionally, block types without content are hidden from the List View and are unable to gain focus within the block list. This makes it harder to break the expected layout.

In locked mode, the inspector controls of the blocks are also disabled. Instead, the sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. only shows a list of content blocks a user can change.

For now, users still have the freedom to leave this locked mode by pressing modify. When modify is pressed, the block editor shows the hierarchy, and the user has complete control. For now, any user can press the modify button. In the future, it may depend on the capabilities of the user.

Content only editing in a block

The core blocks that support content locking are column, cover, and group.

To use content locking, the templateLock attribute of one of the previously referred blocks should be set to “contentOnly”.

In the following pattern, only the content of the paragraph blocks can be edited. A user would not view the spacer block in between.


Paragraph 1

Paragraph 2

Using as custom post-type template locking

The new content-only locking can also be used as custom post-type template locking, like all the other locking methods that exist.

Example:

function myplugin_register_template() {
    $post_type_object = get_post_type_object( 'post' );
    $post_type_object->template = array(
        array(
			'core/group',
			array(),
			array(
				array(
					'core/paragraph',
					array( 'placeholder' => 'Add Description...',
					)
				)
			)
		),
    );
    $post_type_object->template_lock = 'contentOnly';
}
add_action( 'init', 'myplugin_register_template' );

Visit pull request: #43037 and Block Template Documentation

Global template_lock inheritance in the column block

The block template defines a default list of blocks in an editor session. To prevent manipulation of the block list, all blocks can be locked by the template_lock property.

However, in column blocks, the editor would crash on certain operations because it would initialize the lock status defined in the block template. To resolve this issue and to be more consistent about template lock status inheritance, column blocks now inherit the lock status of block templates.

For more information visit #42677.

Props to @wildworks contribution, @bph and @webcommsat for reviews.

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

Simplified data access with new React hooks in WordPress 6.1

The @wordpress/core-data 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/. package in 6.1 ships new ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. 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. that make accessing WordPress data easier than before.

useEntityRecords

With useEntityRecords developers, can fetch a list of records with a single hook call:

useEntityRecords( 'postType', 'page' )

Below is what it looks like when used in a React component:

import { useEntityRecord } from '@wordpress/core-data';
 
function PageTitlesList() {
   const pages = useEntityRecords( 'postType', 'page' );
 
   if ( pages.isResolving ) {
      return 'Loading...';
   }
 
   return (
      <ul>
         {pages.records.map(( page ) => (
            <li>{ page.title }</li>
         ))}
      </ul>
   );
};
 
// Rendered in the application:
// <PageTitlesList />

In the above example when PageTitlesList is rendered, the list of records and the resolution details will be retrieved from the store state using getEntityRecords(), or resolved if missing.

The useEntityRecords accepts four arguments:

  • kind (string) – Kind of the entity, e.g. root or a postType.
  • name (string) – Name of the entity, e.g. plugin or a post.
  • queryArgs (object) – Optional 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. query to pass to the requested 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. endpoint, e.g. { "per_page": 10 }
  • options (object) – Optional hook options. Currently, the only supported option is enabled and determines whether the records will be requested.

It returns an object with the following properties:

  • records (array) – The requested entity records
  • isResolving (boolean) – Are these records being resolved at the moment?
  • hasResolved (boolean) – Have these records resolved already?
  • status (string) – Resolution status. One of: IDLE, RESOLVING, SUCCESS, or ERROR

useEntityRecord:

Developers can retrieve a single record using the useEntityRecord hook:

import { useEntityRecord } from '@wordpress/core-data';

function PageTitleDisplay( { id } ) {
	const page = useEntityRecord( 'postType', 'page', id );

	if ( page.isResolving ) {
		return 'Loading...';
	}

	return page.title;
}

// Rendered in the application:
// <PageTitleDisplay id={ 13 } />

In the above example, when PageTitleDisplay is rendered, the page and the resolution details will be retrieved from the store state using getEntityRecord(), or resolved if missing.

The useEntityRecord hook accepts four arguments:

  • kind (string) – Kind of the entity, e.g. root or a postType.
  • name (string) – Name of the entity, e.g. plugin or a post.
  • recordId (string|number) – The ID of the requested entity record.
  • options (object) – Optional hook options. Currently, the only supported option is enabled and determines whether the records will be requested.

It returns an object with the following properties:

  • record (object|null) – The resolved entity record.
  • isResolving (boolean) – Is the record being resolved at the moment?
  • hasResolved (boolean) – Has the record already resolved already?
  • status (string) – Resolution status. One of: IDLE, RESOLVING, SUCCESS, or ERROR.
  • hasEdits (boolean) – Does the record have any in-browser edits?
  • editedRecord (object|null) – The record with any in-browser edits applied.
  • edit (function) – Applies the in-browser edits to the edited entity record.
  • save (function) – Persist the in-browser edits to the server.

Below is an example showcasing the editing capabilities provided by useEntityRecord:

import { useDispatch } from '@wordpress/data';
import { useCallback } from '@wordpress/element';
import { __ } from '@wordpress/i18n';
import { TextControl } from '@wordpress/components';
import { store as noticeStore } from '@wordpress/notices';
import { useEntityRecord } from '@wordpress/core-data';
 
function PageRenameForm( { id } ) {
 	const page = useEntityRecord( 'postType', 'page', id );
 	const { createSuccessNotice, createErrorNotice } =
 		useDispatch( noticeStore );
 
 	const setTitle = useCallback( ( title ) => {
 		page.edit( { title } );
 	}, [ page.edit ] );
 
 	if ( page.isResolving ) {
 		return 'Loading...';
 	}
 
 	async function onRename( event ) {
 		event.preventDefault();
 		try {
 			await page.save();
 			createSuccessNotice( __( 'Page renamed.' ), {
 				type: 'snackbar',
 			} );
 		} catch ( error ) {
 			createErrorNotice( error.message, { type: 'snackbar' } );
 		}
 	}
 
 	return (
		<form onSubmit={ onRename }>
			<TextControl
				label={ __( 'Name' ) }
				value={ page.editedRecord.title }
				onChange={ setTitle }
			/>
			<button type="submit">{ __( 'Save' ) }</button>
		</form>
 	);
}
// Rendered in the application:
// <PageRenameForm id={ 1 } />

In the above example, updating and saving the page title is handled via the edit() and save() mutation helpers provided by useEntityRecord();

useResourcePermissions

Developers can check the current user’s permissions using the useResourcePermissions hook:

import { useResourcePermissions } from '@wordpress/core-data';

function Page({ pageId }) {
	const pagePermissions = useResourcePermissions( 'pages', pageId );

	if ( pagePermissions.isResolving ) {
		return 'Loading ...';
	}

	return (
        <div>
			{pagePermissions.canCreate
				? (+ Create a new page)
				: false}
			{pagePermissions.canUpdate
				? (Edit page)
				: false}
			{pagePermissions.canDelete
				? (Delete page)
				: false}
			// ...
        </div>
	);
}

// Rendered in the application:
// <Page pageId={ 15 } />

In the above example when the Page is rendered, the appropriate record-level page permissions and the resolution details will be retrieved from the store state using the canUser() selector, or resolved if missing.

In the following example, the PagesList component requests permissions for the pages collection and not a specific page record:

import { useResourcePermissions } from '@wordpress/core-data';

function PagesList() {
   const pagesPermissions = useResourcePermissions( 'pages' );

   if ( pagesPermissions.isResolving ) {
      return 'Loading ...';
   }

   return (
      <div>
         {pagesPermissions.canCreate
            ? (+ Create a new page)
            : false }
         // ...
      </div>
   );
}

// Rendered in the application:
// <PagesList />

The useResourcePermissions hook accepts two arguments:

  • resource (string) – The resource in question, e.g., media.
  • id (string|number) – Optional ID of a specific resource entry, e.g., 10.

It returns an object with the following properties:

  • status (string) – Resolution status. One of: IDLE, RESOLVING, SUCCESS, or ERROR
  • isResolving (boolean) – Is the record being resolved at the moment?
  • hasResolved (boolean) – Has the record already resolved?
  • create (boolean) – Can the current user create new resources of this type?
  • read (boolean) – Can the current user read resources of this type?
  • update (boolean) – Only if id is provided. Can the current user update the requested resource?
  • delete (boolean) – Only if id is provided. Can the current user delete the requested resource?

Documentation: @wordpress/core-data packages

Props for review @bph, @gziolo, and @webcommsat

#6-1, #wordpress-data, #dev-notes, #dev-notes-6-1, #editor

Reference Styles values in theme.json

With WordPress 6.1, theme developers can style elements with references from other settings.

Theme designs often require consistency in the styles applied to blocks. This can be achieved by setting Styles properties which are inherited by blocks using the inheritance of the CSSCSS Cascading Style Sheets. cascade. In some cases blocks want to apply settings from Styles to a different property of the 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. – for example the button element might want to use the global text color for its background color and the global background for its text color.

To solve this problem, themes need to be able to share Styles settings with blocks. This will make it easier for users to update these shared properties across all their blocks. Again, as example for button element the developer wants to use the text color for its background. If the button element is set up as in the example above, then when a user edits the global text color, the background color of their buttons will also be updated, too.

To achieve this, a new ref property was added to 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. which allows one property to set itself to the value of another, for example defining this for button elements:

"elements": {
	"button": {
		"color": {
			"background": {
				"ref": "styles.color.text"
			},
			"text": {
				"ref": "styles.color.background"
			}
		}
	}
}

Styles will convert {ref: "styles.color.background"} the value at: styles > color > background in theme.json.

Limitations

It is currently only possible to use ref to get one value from theme.json; a ref value cannot point to another ref. This also prevents circular refs from causing problems.

Props to @bph and @webcommsat for review of this post.

#6-1, #dev-notes, #dev-notes-6-1, #styles, #themes

WordPress 6.1 Accessibility Improvements

Thank you to @joedolson and @alexstine for collaborating to write this post.

With WordPress 6.1 around the corner, this post brings together the many accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) improvements and fixes to look forward to that might be hard to discover amongst the details of 500+ bugs and enhancements. As always, there’s more work to be done with accessibility requiring an ongoing effort and commitment. 

If you’re interested in helping with this work, please join the #accessibility channel in Make 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/. (need a slack account to view) and check out how you can get involved. There are numerous ways to get involved in this important work including testing, giving accessibility feedback, and creating PRs to address feedback.

Themes

Most notably, 6.1 will see the introduction of both Twenty Twenty-Two and Twenty Twenty-Three marked as accessibility ready, making them both the first default 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. themes to do so (and only default block themes). This helps open up more folks to the world of block themes and broader site editing features.

WP Adminadmin (and super admin) Screens

Across the many screens in WP Admin, improvements abound. Changes range from improvements in color contrast on 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 screen during recovery mode, to a switch from a text input to a textarea field in the media library, so users are better able to see the content of the field while editing. 

Login and Registration

To better call attention to the many improvements to this form, this section has been pulled out of the WP Admin Screen section. While this is a lesser used interface, the accessibility improvements are quite significant for this release, addressing many longstanding problems. This includes proper labels for required fields, explicitly associating errors with input fields so folks know what actions to take where, improved labels for radio buttons, and more. 

Site Editor/Template Editor

Even though the Site and Template editors both use blocks, there are some specific accessibility challenges for these new interfaces in a site editing world. More work is needed and, if you’re keen to help, please join the FSE Outreach Program where you can go through calls for testing to provide feedback, find bugs, and more. 

Navigation block

The navigation block continues to be a powerful and complex block, especially in the world of block themes. While there are fallbacks and an improved menu management experience to look forward to in this release, there is also a nice set of accessibility related fixes to make this necessary block usable for more people in more situations. 

General Block Editor (other blocks, writing flow, components, etc)

This section covers a wide range of items including everything from improvements to additional blocks, like a focus loss fix for the Table block, and larger improvements to functionality like the Tools Panel. Specifically, the Tools Panel helps power part of the experience of using the numerous design tools present in more blocks for this release. It’s what you’d interact with to interact with more tools or reset changes. Improving the accessibility of this single tool has a cascading impact by improving the experience everywhere it’s used.  

Comments

Comments now include proper contextual attributes for autocomplete fields, proper labels for the visible text describing required fields, and improved accessibility (and translatability) of the logged in as link.

#6-1, #accessibility, #dev-notes, #dev-notes-6-1

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

Enhanced TypeScript support in WordPress 6.1

WordPress 6.1 enhances the TypeScript support for the frontend data stores. The types it ships for the @wordpress/data and @wordpress/core-data npm packages enable auto-completion and improvements in static type checks.

As a recap, @wordpress/data is the foundational package powering all the data stores in the WordPress editor. WordPress 6.1 provides the TypeScript signatures for its central utilities: createReduxStore, and useSelect, ensuring the selector types are correctly reflected in the code that uses them:

import {
	createReduxStore,
	useSelect,
	useDispatch
} from '@wordpress/data';

const config = {
	reducer: () => null,
	selectors: {
		/**
		 * @param {Object} state
		 * @param {string} unit
		 * @return {number}
		 */
		getTemperature: ( state, unit = 'C' ) => {
			/* action implementation */
		}
	}
};

const store = createReduxStore( 'STORE_NAME', config );

// Correct call:
useSelect( store, [] ).getTemperature( 'F' ); 

// TypeScript error
useSelect( store, [] ).getTemperature( {} );

TypeScript developers can now build strongly typed data stores with autocompletion and static checks:

Video shows the interaction of an IDEIDE Integrated Development Environment. A software package that provides a full suite of functionality to software developers/programmers. Normally an IDE includes a source code editor, code-build tools and debugging functionality. for auto-completion and static checks.

The @wordpress/core-data store is the first to take advantage of the enhanced TypeScript support. Enhanced autocompletion and static checks are also available when working with the @wordpress/core-data selectors, including getEntityRecord and getEntityRecords:

Props to @bph, @gziolo, and @webcommsat for review.

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

Roster of design tools per block

For WordPress 6.1, there was a concerted effort to add design tools consistently to blocks, via 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. support and make them available via Inspector Controls and for themes in 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. file.

In this post, you will find a roster for quick reference showing which block has which controls.

If you need a list of blocks for each control displayed separately, visit the post Core Editor Improvement: Catalyst for creativity and control.

BlockTypographyColorDimensionBorderLayoutDuotone
Archives
Audio
AvatarAvatar An avatar is an image or illustration that specifically refers to a character that represents an online user. It’s usually a square box that appears next to the user’s name.
Button
Buttons
Calendar
Categories
Code
Column
Columns
Comment Author Avatar
Comment Author Name
Comment Content
Comment Date
Comment Edit Link
Comment Reply Link
Comment Template
Comments
Comments Pagination
Comments Pagination Next
Comments Pagination Numbers
Comments Pagination Previous
Comments Title
Cover
Embed
File
Gallery
Group
Heading
Home Link – Navigation
HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers.
Image
Latest Comments#43310
Latest Posts
List
List Item#43312
Login/logout
Media & Text
More (Read More)
Navigation
Navigation Link
Navigation Submenu
Next Page (Page Break)
Page List#43316
Paragraph
Post Author
Post Author Biography
Post Author Name
Post Comments Count
Post Comments Form
Post Comments Link
Post Content
Post Date
Post ExcerptExcerpt An excerpt is the description of the blog post or page that will by default show on the blog archive page, in search results (SERPs), and on social media. With an SEO plugin, the excerpt may also be in that plugin’s metabox.
Post 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.
Post Navigation Link
Post Template
Post Terms
Post Title
Preformatted✅ no link
Pullquote
Query
Query No Results
Query Pagination
Query Pagination Next
Query Pagination Numbers
Query Pagination Previous
Query Title
Quote
Read More
RSS
Search
Separator
Site Logo
Site Tagline
Site Title
Social Link
Social Links
Spacer
Table
Tag Cloud#43452
Term Description
Verse
Video

Legend: ⏳ Adoption of block supports is pending block refactoring e.g. Caption inner blocks

Props to @aaronrobertshaw for prep work on a similar table in #43242 , @annezazu and @webcommsat for review.

#6-1, #dev-notes, #dev-notes-6-1, #editor

Miscellaneous Core changes for WordPress 6.1

WordPress 6.1 brings a number of new 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. and functions, which developers should be aware of.

New functions

is_term_publicly_viewable()

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. component gets counterpart to the is_post_publicly_viewable() in a form of is_term_publicly_viewable() function. It will centralise and reduce the logic needed to validate a term and determine if it’s publicly viewable.

Before:

$term = get_term( $term_id );

if ( ( $term instanceof WP_Term ) && is_taxonomy_viewable( $term->taxonomy ) ) {
    $link = get_term_link( $term_id );
}

After:

if ( is_term_publicly_viewable( $term_id ) ) {
    $link = get_term_link( $term_id );
}

Read more in #56215.

did_filter()

Another counterpart comes to Plugins component: did_filter() retrieves the number of times 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. has been applied during the current request, bringing parity with did_action().

Read more in #35357.

Function changes

Allow to wrap settings sections with custom HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. in add_settings_section()

WP 6.1 improves the add_settings_section() function to allow developers to pass extra HTML mark-up to be rendered before and after the settings section. Extra argument $args can now be passed to the function, and is an array that can contain the following items:

  • before_section: HTML content to prepend to the section’s HTML output. Receives the section’s class name provided with the section_class argument via an optional %s placeholder. Default empty.
  • after_section: HTML content to append to the section’s HTML output. Default empty.
  • section_class: The class name to use for the section. Used by before_section if a %s placeholder is present. Default empty.

The HTML passed using these extra arguments is escaped using wp_kses_post() just before rendering. This changeset also provides a set of unit tests for this new feature.

Readme more in #17851.

Cron Component

Add error logging and hooks to wp-cron.php

In #56048 error logging was added to WP-Cron to indicate when an event fails to get rescheduled or unscheduled. The actions cron_reschedule_event_error and cron_unschedule_event_error have been introduced to allow developers to run custom tracking on these errors.

Non blocking wp-cron.php with LSAPI

In #54668 requests to wp-cron.php were made non-blocking for the LSAPI PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher implementation. Networknetwork (versus site, blog) requests for wp-cron.php will close prior to the processing of events inline with the behaviour for sites using PHP FPM.

New filters

wp_read_audio_metadata

Next to wp_read_image_metadata (added 15 years ago) and wp_read_video_metadata (added 5 years ago), Media component gets another metadata hook, wp_read_audio_metadata, which will allow filtering data extracted from uploaded audio file. Read more in #55828.

pre_option 

Although a pre_option_{$option} filter already exists, this change adds a more general pre_option filter that will run on every get_option call. This brings the control flow into similar flow as update_option. Read more in #37930.

ajax_term_search_results

Taxonomy component get another addition in ajax_term_search_results hook, which can be used to filter the term search results returned by the AJAX term query. Read more in #55606.

get_header_image

Themes that support 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. Image feature can now modify header image URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org returned by get_header_image() using the new get_header_image filter. Read more in #56180.

wp_list_table_class_name

As list tables are very widely used by extenders, a new filter wp_list_table_class_name will allow them to modify the list table returned for custom screens. Next to this, the private delegation is removed from the following classes and function:

  • WP_List_Table
  • WP_Application_Passwords_List_Table
  • WP_Comments_List_Table
  • WP_Links_List_Table
  • WP_Media_List_Table
  • WP_MS_Sites_List_Table
  • WP_MS_Themes_List_Table
  • WP_MS_Users_List_Table
  • WP_Plugin_Install_List_Table
  • WP_Plugins_List_Table
  • WP_Post_Comments_List_Table
  • WP_Posts_List_Table
  • WP_Terms_List_Table
  • WP_Theme_Install_List_Table
  • WP_Themes_List_Table
  • WP_Users_List_Table
  • _get_list_table()

Read more in #18449.

lost_password_html_link

On the login page, the “Register” link for new users has been filterable for some time. Now, with lost_password_html_link hook, we have the ability to filter the “Lost your password?” link as well. Read more in #55388.

wp_send_new_user_notification_to_admin and wp_send_new_user_notification_to_user

New filters in Users component allow conditional suppression of the email notifications that are sent when a new user account is registered. Read more in #54874.

Pass $action to nonce_life filter

WP 6.1 contextualizes the usage of nonce_life filter by passing the $action parameter. It allows to alterate the default lifespan of nonces on a case by case basis. Read more in #35188.

New filters for wp_list_authors() and wp_list_users()

The following three filters allow to customize the wp_list_authors() and wp_list_users() output:

  • wp_list_authors_args: Filters the query arguments for the list of all authors of the site.
  • pre_wp_list_authors_post_counts_query: Filters whether to short-circuit performing the query for author post counts. This may be useful to account for custom post types or post statuses.
  • wp_list_users_args: Filters the query arguments for the list of all users of the site.

Read more in #17025.

New set of fine-grained filters for the feed_links() function

The previously available set of filters in the feed_links() function to enable or disable display of various feed links was quite limited:

  • feed_links_show_posts_feed to control the main feed
  • feed_links_show_comments_feed to control both the global comments feed and the comment feed for singular posts.

In order to disable the other feeds (post type archive, categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging., 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.), custom taxonomy, author archive, search results), one would have to unhook feed_links_extra() from wp_head, but that would completely remove all of those feeds, as well as the single post comments feed.

To allow for more flexibility, this commit introduces a full set of filters in the feed_links_extra() function to control each one of the feeds independently, including a way to enable/disable the single post comments feed when the global comments feed is disabled/enabled:

  • feed_links_extra_show_post_comments_feed
  • feed_links_extra_show_post_type_archive_feed
  • feed_links_extra_show_category_feed
  • feed_links_extra_show_tag_feed
  • feed_links_extra_show_tax_feed
  • feed_links_extra_show_author_feed
  • feed_links_extra_show_search_feed

All of them default to true, except for feed_links_extra_show_post_comments_feed which defaults to the result of feed_links_show_comments_feed to ensure backward compatibility.

Read more in #55904.

Ability to filter arguments to the_posts_pagination()

A new the_posts_pagination_args filter has been added that allows developers to modify the arguments passed to the_posts_pagination().

A typical case where this new filter can be helpful is creating a child themeChild theme A Child Theme is a customized theme based upon a Parent Theme. It’s considered best practice to create a child theme if you want to modify the CSS of your theme. https://developer.wordpress.org/themes/advanced-topics/child-themes/..  Suppose a template in a parent theme contains something like (such as in Twentyseventeen) :

the_posts_pagination(
    array(
       'prev_text' => parent_theme_get_svg( 'prev' ),
       'next_text' => parent_theme_get_svg( 'next' ),
    )
);

When the author of a child theme wants to use something other than the parent theme’s SVGs for the next/previous links, for example, simple text links so that they can style them similar to other next/previous that are used in the child theme.

Prior to WordPress 6.1, child theme authors needed to copy the parent theme’s template into their child theme and change the arguments passed to the_posts_pagination().

With this new filter, child theme authors can simply do:

add_filter( 'the_posts_pagination_args', 'child_theme_the_posts_pagination_args' );

public function child_theme_the_posts_pagination_args( $args ) {
    $args['prev_text'] = __( 'Previous', 'child-theme' );
    $args['next_text'] = __( 'Next', 'child-theme' );

    return $args;
}

Read more in #53392.

Other changes

New oEmbed provider: Pocket Casts

Pocket Casts is a podcast player with apps for several platforms. The oEmbed 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. provides rich HTML to embed any audio or video episode onto a website. URLs on the pca.st domain can now be embedded automatically.

Read more in #55860.

Thanks to @audrasjb, @pbiron, @johnbillionand @peterwilsoncc for contributing to 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