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.
In this post, you will find dev notesdev 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. for smaller changes to the editor in WordPress 6.5.
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. Supports
Background image block support additional features for size, repeat, and position
In WordPress 6.5, the background image block support receives new controls related to the size of the background image: size, repeat, and position.
For blocks that use the background image block support (currently, the Group block is the only coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. block to use this support), these optional controls can now be displayed. They are hidden by default behind the tools panel menu in the Background controls on the inspector 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..
How to add backgroundSize support to a theme
There are two ways to add support for backgroundSize and the related size, as well as repeat and position control to a block theme. The simplest one is to opt into the appearanceTools setting, which automatically enables a number of design tools (read more in the developer handbook).
For themes that wish to have more granular control over which UIUIUser interface tools are enabled, the backgroundSize support can be opted into by setting settings.background.backgroundSize to true in theme.json. For example:
Note that as of WordPress 6.4 and WordPress 6.5, the backgroundImage, backgroundSize, and related supports are only available at the individual block level, not in global styles or at the site root. These features will be explored in subsequent releases, with progress tracked in this GithubGitHubGitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ issue: #54336.
Props to @andrewserongfor writing the 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..
Aspect ratio block support
A new aspect ratio block support has been added in WordPress 6.5, with the Cover block opted-in by default. For themes using the appearanceTools feature in theme.json, the control will be available in the inspector controls under Dimensions.
The feature allows users to set an aspect ratio for the Cover block, and is mutually exclusive with min-height rules. If an aspect ratio is set, then min-height is unset to ensure that height rules do not conflictconflictA conflict occurs when a patch changes code that was modified after the patch was created. These patches are considered stale, and will require a refresh of the changes before it can be applied, or the conflicts will need to be resolved. with the aspect ratio. The aspect ratio rules will be output at render-time for the block via an inline style applied to the block’s wrapper.
Note that themes or blocks that add width or height rules to a block will need to take care in testing compatibility with aspect-ratio if they are to opt-in to aspect ratio support. The aspect ratio tends to work most flexibly when width or height rules are not set.
How to add aspectRatio support to a theme
There are two ways to add support for aspectRatio to a block theme. The simplest is to opt into the appearanceTools setting, which automatically enables a number of design tools (read more in the developer handbook).
For themes that wish to have more granular control over which UI tools are enabled, the aspectRatio support can be opted into by setting settings.dimensions.aspectRatio to true in theme.json. For example:
The Quote block has blockGap support in WordPress 6.5. It also changes the default spacing between the quote and the citation in block themes that have blockGap enabled, to be consistent with all other blocks that use the layout support. The default spacing will now use the layout spacing rules defined by a theme’s styles.spacing.blockGap value in theme.json.
For themes that use blockGap but wish to use a different gap between the quote and the citation, they can set a spacing.blockGap value for the block directly.
Add padding and margin support to the Pullquote block
Pullquote block now supports padding and margin. At the same time, the browser default margin applied to the blockquote element inside the block has been reset to zero to ensure that padding values are applied accurately inside the block. Depending on themes, this effect may result in visual changes and the need to adjust padding or margin.
In WordPress version 6.5, footnotes are now supported on any custom post typeCustom Post TypeWordPress can hold and display many different types of content. A single item of such a content is generally called a post, although post is also a specific post type. Custom Post Types gives your site the ability to have templated posts, to simplify the concept. that fulfills certain requirements. To be eligible for footnotes, a custom post type must have capabilitiescapabilityA capability is permission to perform one or more types of task. Checking if a user has a capability is performed by the current_user_can function. Each user of a WordPress site might have some permissions but not others, depending on their role. For example, users who have the Author role usually have permission to edit their own posts (the “edit_posts” capability), but not permission to edit other users’ posts (the “edit_others_posts” capability). like 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/., custom fields, revisionsRevisionsThe WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision., and editor support. If a post type meets these requirements, footnotes should be available by default without requiring any changes from the developer.
However, if a developer wants to remove footnotes support in a specific condition, for example, in a particular post type, they can use the block 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. like any other block. The following code sample demonstrates how we can remove footnotes support from the “post” post type:
Props to @jorgefilipecosta for writing the dev note.
DependencyExtractionWebpackPlugin: Drop webpack4 and node<18
As webpack4 doesn’t support modules that blocks require to work, and that webpack5 was released more than three years ago, the support for webpack4 is dropped in WordPress 6.5.
In addition, the support for Node.js version 17 or older is dropped, as Node.js 18 is currently the oldest maintained version.
@wordpress/scripts version 17 has dropped official support for unmaintained Node.js versions. The oldest supported Node.js version is now Node.js 18.
@wordpress/dependency-extraction-webpack-plugin version 5 has dropped official support for unmaintained Node.js versions. The oldest supported Node.js version is now Node.js 18.
@wordpress/dependency-extraction-webpack-plugin version 5 has dropped support for webpack versions less than 5. Users should either upgrade to webpack v5 or continue to use v4 of 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. Version 4 will not be maintained going forward. If you’re using @wordpress/dependency-extraction-webpack-plugin via @wordpress/scripts, the webpack change should not affect you.
Stabilization of the block editor’s RecursionProvider API
Context
Originally implemented as an experimental hook named __experimentalUseNoRecursiveRenders in early 2021, then improved and repackaged in 2022 as the pair __experimentalRecursionProvider and __experimentalUseHasRecursion, the purpose of these APIs is to prevent certain advanced block types from accidentally triggering infinite rendering loops inside the block editor. For example, the Template block must guard against these loops:
If a user adds an instance of the Template block into the contents of that same template (linear recursion);
If Template A contains Template B, which then contains Template A (mutual recursion).
As of today, the following core block types use the RecursionProvider API:
core/block
core/navigation
core/post-content
core/template-part.
Changes with WordPress 6.5
The API has been promoted to stable, thereby shedding the __experimental prefix. Consumers should now use the API by importing RecursionProvider and useHasRecursion from @wordpress/block-editor, or via the WP global as wp.blockEditor.RecursionProvider and wp.blockEditor.useHasRecursion.
For more details and a working example, see the component’s README.md document.
Before
After
wp.blockEditor.__experimentalRecursionProvider
wp.blockEditorRecursionProvider
wp.blockEditor.__experimentalUseHasRecursion
wp.blockEditor.useHasRecursion
Backwards compatibility
The former identifiers — __experimentalRecursionProvider and __experimentalUseHasRecursion — are now deprecated. This means that they are still accessible, but their use will trigger a warning in the browser console.
WordPress 6.5 adds support for the new allowedBlocks field in the block.json file. It lets block developers specify which block types can be inserted as children of the given block. It’s a companion to the existing parent and ancestor fields that have a similar function, namely specifying allowed parent block types. Example of usage in a block.json file:
One of the main advantages of the block.json field is that it can be modified by plugins. For example, you can create a block that acts as a custom list item and extend the Core List block so that your custom block can be inserted as its child:
This new API replaces the allowedBlocks option that can be passed to the useInnerBlocksProps hook inside the block’s edit function. This option was previously used to implement the same check, but it wasn’t extensibleExtensibleThis is the ability to add additional functionality to the code. Plugins extend the WordPress core software.: the list of allowed blocks was hardcoded in the block’s edit function and couldn’t be modified.
The allowedBlocks option on the useInnerBlocksProps hook is still supported and is not deprecated, but you should use it only for specialized use cases. Like when the list of allowed blocks is dynamically calculated for each block: from its attributes, or from its surrounding environment (the parent block etc.).
Introducing the block_core_navigation_listable_blocksfilterFilterFilters 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.
WordPress 6.5 introduces a new filter, block_core_navigation_listable_blocks which is designed to provide control over the accessible rendering of child blocks used within the Navigation block.
Historically, the Navigation block has conditionally wrapped particular blocks in <li> tags to ensure accessible markup on the front of the site.
With the introduction of the new allowedBlocks API, which technically allows any block to be added as valid children of the Navigation block, developers require a means to indicate which blocks need to be wrapped.
The block_core_navigation_listable_blocks filter allows developers to determine whether a specific block should be wrapped in an <li>tagtagA 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.), thereby aiding in adherence to 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) standards and the creation of valid markup.
The example below shows the mycustomblock/icon block opting into being wrapped in an <li> tag:
Two new selectors have been introduced to Block Editor’s Core Data API to fetch revisions and single revisions for post types that support revisions, for example, posts and pages, templates, and global styles.
getRevisions( kind, name, recordKey, query ) – fetches a post’s revisions where recordKey is the id of the parent post.
getRevision(kind, name, recordKey, revisionKey, query) – fetches a single post revision, where revisionKey is the id of the individual revision.
The functions use similar arguments to existing core data entity functions, such as getEntityRecords with the addition of recordKey (post parent id) and revisionKey (single revision id).
Example usage:
// Returns a collection of revisions.
// `parentGlobalStylesId` is the id (int) of the parent post.
wp.data.select( 'core' ).getRevisions( 'root', 'globalStyles', parentGlobalStylesId, { per_page: -1 } );
// Paginated results.
// `parentId` is the id (int) of the parent post.
wp.data.select( 'core' ).getRevisions( 'postType', 'post', parentId, { per_page: 3, page: 2 } )
// Get a single revision object.
// `parentId` is the id (int) of the parent post.
// `revisionId` is the id (int) of the individual revision post.
wp.data.select( 'core' ).getRevision( 'postType', 'post', parentId, revisionId );
// Get a single revision with only the id, parent and date fields.
// `parentId` is the id (int) of the parent post.
// `revisionId` is the id (int) of the individual revision post.
wp.data.select( 'core' ).getRevision( 'postType', 'post', parentId, revisionId, { _fields: 'id,parent,date' } );
getRevisions and getRevision can also be used via useSelect in ReactReactReact is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. components:
import { useSelect } from '@wordpress/data';
import { store as coreStore } from '@wordpress/core-data';
function MyComponent() {
const pageRevisions = useSelect(
( select ) =>
select( coreStore ).getRevisions( 'postType', 'page', pageId ),
[ pageId ]
);
// Do something with pageRevisions...
}
In the background, these selectors’ corresponding resolvers call revisions REST API endpoints.
New useSettings hook for reading block instance settings
When trying to improve the block editor’s performance for WordPress 6.5, one of the identified issues was related to the useSetting hook that is used by block instances to read various settings provided by the environment they are in: parent blocks, the theme, the block editor itself. It turns out that it’s inefficient to read multiple settings with separate useSetting calls:
That’s why WordPress 6.5 introduces this new hook. The useSetting (singular) hook is now deprecated (using it will trigger a console warning), because reading even a single setting is very easy with the useSettings (plural) hook:
The only change is that the useSettings hook always returns an array, and the array needs to be destructured to read the single value. Supporting two APIs for performing the same task is therefore not justified.
Introduction of the PluginPostExcerpt Slot Component
This update introduces a new PluginPostExcerpt slot component within the GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ editor. This enhancementenhancementEnhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. allows for the extension of the 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. panel, allowing developers to customize this area for their needs.
What’s New?
The component enables the addition of custom content within the Post Excerpt panel. This is particularly useful for plugins looking to add extra functionality or information specific to their use case.
Usage
To utilize this new feature, developers can now insert their custom content into the Post Excerpt panel by creating a component that leverages the slot. This allows for a seamless integration of custom functionalities directly within the editor.
The following example shows adding custom content to the post excerpt panel.
Changes to the underlying Composite component implementation
WordPress 6.5 no longer includes the Reakit package, as it does not support React beyond v16. The __unstable*Composite component was built on this library, so it has been internally refactored.
What does this mean for consumers?
The primary API has not changed, and can still be imported with no changes. For typical usage patterns, there should be no differences, and in most cases, no action is required from consumers of the package.
However, composite state props must now be generated by the useCompositeState hook; they can no longer be provided by independent state logic. Composite state arguments have not changed, though, and will continue to work as before.
import {
__unstableComposite: Composite,
__unstableCompositeGroup: CompositeGroup,
__unstableCompositeItem: CompositeItem,
__unstableUseCompositeState: useCompositeState
} from '@wordpress/components';
const state = useCompositeState({ ... });
// ✅ This will continue to work
...( <Composite { ...state } /> );
// ⛔️ This will no longer work
...( <Composite { ...state } currentId={ ... } /> );
Consumers can continue to either spread the state or pass as a single state prop.
// ✅ Used by spreading the state
...(
<Composite { ...state }>
<CompositeGroup { ...state }>
<CompositeItem { ...state }>
{ ... }
</CompositeItem>
</CompositeGroup>
</Composite>
);
// ✅ Or with a single `state` prop
...(
<Composite state={ state }>
<CompositeGroup state={ state }>
<CompositeItem state={ state }>
{ ... }
</CompositeItem>
</CompositeGroup>
</Composite>
);
Because the shape of the returned composite state has changed, consumers can also now no longer destructure specific state props from useCompositeState.
// ✅ This will continue to work
const state = useCompositeState({ ... });
// ⛔️ This will no longer work
const { groups, items } = useCompositeState({ ... });
What’s next?
We anticipate a new stable Composite component to be released in WordPress 6.6, along with the deprecation of this unstable version.
The isPressed prop on the Button component implicitly sets aria-pressed, with no way to override it. But sometimes Button is used for roles other than button, such as option and checkbox, where aria-pressed is not appropriate, and workarounds are required to add the correct semantics.
In an effort to move away from custom props that have native HTMLHTMLHyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. equivalents, and to allow greater flexibility in component usage, aria-pressed is now supported as a first-class prop, taking precedence over isPressed.
A number of UI components currently ship with styles that give them top and/or bottom margins. This can make it hard to reuse them in arbitrary layouts, where you want different amounts of gap or margin between components. To better suit modern layout needs, we are in the process of deprecating these outer margins
A few releases ago, we deprecated the outer margins on a number of components and introduced transitional props so consumers could opt into these new styles before they become the default:
AnglePickerControl: __nextHasNoMarginBottom
CustomGradientPicker: __nextHasNoMargin
FontSizePicker: __nextHasNoMarginBottom
GradientPicker: __nextHasNoMargin
In WordPress 6.5, these margin-free styles have become the default. Any use of these props can be safely removed.
CustomSelectControl used to have a hard-coded width, which was inconsistent with our other form components. In WordPress 6.1, we deprecated this unconstrained width, and introduced the transitional __nextUnconstrainedWidth prop so consumers could opt into these new styles before they become the default.
In WordPress 6.5, these unconstrained width styles have become the default. Any use of the __nextUnconstrainedWidth prop can be safely removed.
Remove deprecation warnings for __next36pxDefaultSize
A few releases ago, we introduced a __next36pxDefaultSize prop on several components, meant to coordiate the transition to a new default sizing scheme (36px height). Due to some changes in our design direction, we eventually dropped this prop in favor of the __next40pxDefaultSize prop (40px height), making all existing opt-ins to the __next36pxDefaultSize prop act as an opt-in to the 40px one.
After receiving developer feedback about this ahead of WordPress 6.5, we will no longer throw a deprecation warning for usages of the __next36pxDefaultSize prop, informing consumers of this change. Do note, however, that it will trigger the new 40px size rather than the 36px size, despite the prop name.
Remove unused buttonBehavior attribute from the Search block
The Search block had a buttonBehavior attribute, which was referenced internally to determine the display variations of the block. However, this attribute was removed because it could not be changed from the user interface, and the default value was always referenced.
With this change, this attribute will no longer be referenced even if it has been added manually.
Similar to the setting that allows disabling layout controls in WP 6.4, this allows only the content and wide size controls for a constrained layout to be disabled from the 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, globally or at a per-block level.
To disable the control globally for all blocks, add the following in theme.json under settings.layout:
"allowCustomContentAndWideSize": false
To disable at the block level, add the following in theme.json under settings.blocks:
