The WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Found a bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.?Create a ticket in the bug tracker.
A custom CSS input box has been added to the Global Styles settings in the Site Editor. This provides similar functionality to the custom CSS input available in CustomizerCustomizerTool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. for classic themes. This option appears under the global styles actions menu: (#46141)
Ideally, this input should be seen as a last resort fallback to add styling that can not yet be implemented with the other editor design tools. Some other important things to note are:
This custom CSS does not use the same custom_css CPT as the Customizer custom CSS, but instead is part of the existing Global Styles wp_global_styles CPT
As with the other user custom global styles, the custom CSS is specific to the current theme
To support custom CSS as part of Global Styles a new property has been added to theme.jsonJSONJSON, 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. – styles.css
While the addition of the styles.css property to theme.json does allow theme authors to use it to include custom CSS strings in their themes, as with the user input for this property ideally themes should only use this as a last resort fallback to add styling that can’t yet be implemented with the other editor design tools
Theme authors should note that users’ custom CSS can completely override or remove any theme custom CSS set in the theme.json, so in cases where theme authors do not want users to easily wipe custom CSS they should consider including it via the existing style sheet enqueuing methods
Because the standard global styles flow is for user data to override theme data, it would be possible for users to inadvertently override a key theme custom CSS setting, eg. add a custom image background to a group and in the process wipe a background that the theme was adding to headings. For this reason, when a user first edits the custom CSS the theme CSS is shown in the input box to allow the user to selectively and knowingly override/remove any theme custom CSS
Per BlockBlockBlock 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. Custom CSS
When a theme that has support for the Site Editor is activated, users do not have easy access to adding additional CSS via the Customizer. In WordPress 6.2, there are two new ways to add per-block custom CSS: Via the Styles interface in the Site Editor and theme.json. (#46571)
To add CSS via the interface:
open the Styles sidebarSidebarA 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. in the Site Editor
Next, open the blocks panel and
select a block
Click on Additional block CSS to open the block CSS panel
CSS added in this panel applies to all occurrences of the block. In this panel, you can also see if the active theme adds CSS using theme.json:
You can add per-block custom CSS in theme.json as a string in styles.blocks.block.css. Basic example:
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:
Thanks to @AlanP57 for reporting, @hellofromtonya and @sergeybiryukov for reverting the patchpatchA 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.
WordPress 6.1 introduces several new BlockBlockBlock 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.APIAPIAn 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.
PHPPHPThe 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 JavaScriptJavaScriptJavaScript 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:
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-typesREST APIREST APIThe 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 coreCoreCore 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();
WordPress 6.1 comes with content-only editing for blocks, patterns, and templates, as well as a template lock inheritance for the Column blockBlockBlock 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 coreCoreCore 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 sidebarSidebarA 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.
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.
The @wordpress/core-dataJavaScriptJavaScriptJavaScript 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 ReactReactReact is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/.hooksHooksIn 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 HTTPHTTPHTTP 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 APIAPIAn 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?
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 CSSCSSCascading Style Sheets. cascade. In some cases blocks want to apply settings from Styles to a different property of the blockBlockBlock 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.jsonJSONJSON, 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:
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.
With WordPress 6.1 around the corner, this post brings together the many accessibilityAccessibilityAccessibility (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 SlackSlackSlack 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 blockBlockBlock 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.
Across the many screens in WP Admin, improvements abound. Changes range from improvements in color contrast on the pluginPluginA 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.
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.
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.
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 toolspresent 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 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.
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 APIThe 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.
TracTracAn 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 taxonomyTaxonomyA 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.
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 noteEach 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 multisitemultisiteUsed 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 hooksHooksIn 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 ticketticketCreated for both bug reports and feature development on the bug tracker. holding these changes: #56068.
Improvements to Cache APIAPIAn 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 pluginPluginA 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:
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.
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_attrfilterFilterFilters 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 blockBlockBlock 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.
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.
Performance of WP_List_Table::get_column_info() is improved by adding the primary column to the cached headerHeaderThe 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 metaMetaMeta 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).
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:
TypeScript developers can now build strongly typed data stores with autocompletion and static checks:
Video shows the interaction of an IDEIDEIntegrated 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:
For WordPress 6.1, there was a concerted effort to add design tools consistently to blocks, via blockBlockBlock 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.jsonJSONJSON, 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.
AvatarAvatarAn 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
✅
–
–
–
–
–
HTMLHTMLHyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers.
Post ExcerptExcerptAn 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 imageA 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.
You must be logged in to post a comment.