In this dev 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., you will find a collection of smaller changes to existing features and API 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. updates. For component updates, please see also Updates to user-interface components in WordPress 6.4.
Updated Nov 07, 2023 to add a note on how to retrieve the full Image Light box markup in filters.
Table of Contents
Background image block 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
In WordPress 6.4, a new background image block support has been added, with the Group block opted-in by default. For themes using the appearanceTools feature in theme.json, the control will be available in the inspector controls, under Background.
The feature allows users to set a background image for a Group block. The selected image will be output at render-time for the block via an inline style applied to the block’s wrapper. When a background image is set, the rule background-size: cover is output along with the background-image property. This ensures that any background images adequately cover the block. Ideas for enhancements in future releases are being tracked in this GitHub GitHub 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
How to add backgroundImage support to a theme
There are two ways to add support for backgroundImage to a block theme. The simplest is to opt in to 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 User interface tools are enabled, the backgroundImage support can be opted into by setting settings.background.backgroundImage to true in theme.json. For example:
{
"settings": {
"background": {
"backgroundImage": true
Note that as of WP 6.4, the backgroundImage support is only available at the individual block level, and not in global styles or at the site root.
For context and more information, view #53081.
Props to @andrewserong for the dev note (top)
Filter 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. behavior when using new Expand on Click in Image block
If your image block with `Expand on Click` enabled has Lightbox markup that you can’t seem to access from inside your filter function, below is some extra information you might need.
As of WordPress 6.4, please be aware that a built-in filter for the image block has been applied with priority 15 for images with `Expand on Click`. This means that if your filter has a priority of 15 or lower (the default is 10), then the markup used to create the Lightbox behavior will not be available to your function for processing by default.
Please make sure to use priority of at least 16 when adding filters to process the image block if you need to access the Lightbox markup.
add_filter( 'render_block_core/image', 'my_custom_html', 16 )
More information on this issue.
Props to @artemiosans and @afercia for surfacing the issue and documentation (top)
Fluid typography: configurable minimum and maximum viewport values
WordPress 6.4 introduces configurable minimum and maximum viewport width values to fluid typography settings in theme.json.Theme developers can now define their own default viewport “boundaries” for calculating fluid font sizes. These boundaries determine the browser viewport widths at which any font size clamp values will stop being “fluid”.
For example, given the following theme.json 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. settings:
"settings": {
"typography": {
"fluid": {
"maxViewportWidth": "800px",
"minViewportWidth": "600px"
},
}
}
Between the browser widths of 600px and 800px, a font size will be fluid, and therefore scale up or down according to the current viewport size. If the browser width is narrower than 600px or wider than 800px, the font size will no longer shrink or grow.
Due to the way the Block Editor calculates fluid font size values, maxViewportWidth and minViewportWidth only accept px, rem and em units.
In the case of unsupported values, including CSS Cascading Style Sheets. variables, fallback maxViewportWidth and minViewportWidth are used –1600px and '320px' respectively.
For context and more information, view #53081.
Props to @ramonopoly for the dev note (top)
Disable layout controls from theme.json
With WordPress 6.4, it is now possible to disable layout controls globally for all blocks or on a per-block level from theme.json. This ensures that affected blocks still output their default layout styles, but the controls to edit them won’t be available in the block sidebar 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..
To disable the controls for all blocks, "allowEditing": false should be added to settings.layout, like so:
"settings": {
"layout": {
"allowEditing": false
}
}
To disable the controls for individual blocks, add "allowEditing": false in settings.blocks.[block name].layout, thus:
"settings": {
"blocks": {
"core/cover": {
"layout": {
"allowEditing": false
}
}
}
}
For context and more information, view #53378. (top)
Props to @isabel_brison for above dev note (top)
RichText‘s multiline prop has been deprecated since 6.1 and was scheduled for removal in 6.3. We’re leaving the deprecated prop in place, but its functionality has been simplified internally, so you may experience changes.
Instead of one large rich text field, each line is now its own rich text field. Contributors added a splitting and merging functionality, so the fallback is gracious, but some things like paste may work differently. It’s worth noting that this prop remains deprecated and all block authors are encouraged to use InnerBlocks instead.
For context and more information, view #54310.
Props to @ellatrix for the above dev note (top)
New public hook in the Block Editor API: useBlockEditingMode()
Blocks can set an editing “mode” using the useBlockEditingMode hook. useBlockEditingMode() allows a block to restrict the user interface that is displayed for editing that block and its inner blocks.
The block editing mode can be one of three options:
'disabled': Prevents editing the block entirely, that is, it cannot be selected.'contentOnly': Hides all non-content UI, for example, auxiliary controls in the toolbar, the block movers, block settings.'default': Allows editing the block as normal.
The block editing mode is inherited by all the block’s inner blocks, unless inner blocks have their own modes set.
Usage:
function MyBlock( { attributes, setAttributes } ) {
useBlockEditingMode( 'disabled' );
// MyBlock will be marked as 'disabled' editing mode.
return ;
}
useBlockEditingMode() also returns a block’s current editing mode, which can be utilized to further configure block properties. For example, a component inheriting its parent’s block editing mode:
function ChildComponent( props ) {
const blockEditingMode = useBlockEditingMode();
let text = 'Child component';
if ( blockEditingMode === 'disabled' ) {
// Block is disabled, add custom block properties to indicate disabled mode.
text+= ' is disabled!';
}
if ( blockEditingMode === 'default' ) {
// Block can be edited, show controls or other editing-related settings. \
}
return { text }
;
}
For context and more information, view #52094.
Props to @ramonopoly for above dev note (top)
Stabilized APIs for InnerBlocks
Three experimental APIs were stabilized in WordPress 6.4. That means they should be safe from backward-compatibility issues when you use them in production:
defaultBlockdirectInsertgetDirectInsertBlock
More information on GitHub #52083. The documentation on Nested Blocks reflects the updates.
Props to @smrubenstein for dev note (top)
Introduce SCRIPT_DEBUG to make package compatibile with Webpack 5
This change in WordPress core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. is mostly an internal optimization to send less code to the browser. It could be useful for developers using @wordpress/scripts that it is possible to hide code behind this debug flag.
if ( typeof SCRIPT_DEBUG !== 'undefined' && SCRIPT_DEBUG === true ) {
// This code runs only in the development mode and gets completely removed from the production build.
}
For context and more information, view #50122.
Props to @gziolo for above dev note (top)
Add edits data to the useEntityRecord
Now, the useEntityRecord adds to its output a key called edits containing the nonTransientEdits of an entity record. A code example
const widget = useEntityRecord( 'root', 'widget', 1 );
widget.edit( { hello: 'foo' } );
Expected result:
{ edits: { hello: 'foo' } ... }
For context and more information, view #541673.
Props to @mmaattiiaass for above dev note (top)
Props for review of the full post to @webcommsat and @priethor
#6-4, #dev-notes, #dev-notes-6-4
You must be logged in to post a comment.