Here are the dev notes Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. for layout-related changes in the editor.
Layout support stabilization and updates
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 for layout has now graduated from experimental to stable. Everything works the same; the only difference is that when adding block support for layout in block.json
, its name is now layout
instead of __experimentalLayout
. Support for the __experimentalLayout
syntax will be maintained for a while, but it is recommended to upgrade any custom blocks using layout to the stable layout
syntax. (#51434)
Code example (in block.json
):
"supports": {
"layout": true
}
Changes in CSS Cascading Style Sheets. specificity for some layout types
The CSS output for the margin
styles of children of constrained
and flow
(default) layout containers has changed. The generic rules used to have a specificity of 0,1,0
for all blocks; they have now changed to 0,0,0
for all blocks with an extra 0,2,0
rule applied only to the first and last blocks in the container.
This fixes the issue of global margin styles for specific blocks being overridden by layout styles (see #43404).
Compound block and layout type classname applied to inner wrapper of layout blocks
As of WP 6.2, layout classnames are added to the block inner wrapper. For most blocks, this is the same as the outer wrapper, but some blocks (e.g. core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Cover) have multiple inner containers. In 6.3, a new classname is added to the inner wrapper of all blocks with layout, comprised of block classname + layout classname, e.g.: .wp-block-cover-is-layout-constrained
. This is the updated Cover block markup:
<div class="wp-block-cover is-light">
<span aria-hidden="true" class="wp-block-cover__background has-tertiary-background-color has-background-dim-100 has-background-dim"></span>
<div class="wp-block-cover__inner-container is-layout-constrained wp-block-cover-is-layout-constrained">
<p class="has-text-align-center has-large-font-size"></p>
</div>
</div>
This makes it possible for blocks with a complex markup structure to support custom spacing styles.
Layout definitions removed from core theme.json
The layout definitions object, which stores base styles for the layout block support, has been removed from the core theme.json
(settings.layout.definitions
) and moved into the internal layout support files. Extending or overriding core layout definitions was never officially supported and including those definitions in a theme theme.json
file resulted in bugs such as #49914.
Create Block Theme plugin 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 generated theme.json
files that included the layout definitions object before the bug A 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. was fixed in #50268, so theme authors are advised to remove any layout definitions that may have been inadvertently included in their theme.json
files in order to prevent buggy behavior.
New Grid layout type
A new grid layout type is available, based on CSS Grid, and defaulting to an auto-fill
approach with configurable column width. It is also possible to set a fixed number of columns, by using the columnCount
property in the layout object. (#49018)
To create a block with a grid layout, the following needs to be added in the supports
object of the block’s block.json
:
"layout": {
"default": {
"type": "grid"
}
}
Layout and block spacing support added to Post Template block
Previously, the Post Template block had custom layout styles that allowed for either a “list” or a “grid” (implemented behind the scenes with CSS flex) layout, with controls living in its parent Query block.
For 6.3, layout and block spacing support have been added to Post Template, and its controls now live in the Post Template toolbar. There is still a choice of “list” and “grid” styles, but “grid” is now implemented with the grid layout type. (#49050)
Spacer block gets orientation from the parent block layout
Spacer blocks inside a flex
type layout block will now use the orientation of the parent layout. It is still possible to pass Spacer an orientation value from the parent block context, but Spacer blocks inside flex layouts will prioritize the flex orientation over the context one. (#49322)
Props for co-editing to @andrewserong and review to @bph and @leonnugraha.
#6-3, #dev-notes, #dev-notes6-3