Allow insertion as first or last child of Template Part 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. (#60854).
Prior to WordPress 6.7, it wasn’t possible to insert a hooked block as a Template Part block’s first or last child, i.e. the following example wouldn’t work:
"blockHooks": {
"core/template-part": "lastChild"
}
This has now been remediated. (The same is of course true when using firstChild
instead of lastChild
.)
The reason why the Template Part block didn’t previously support firstChild
/lastChild
insertion is that it belongs to a special class of blocks whose content isn’t stored as part of the serialized block markup, but obtained from a different source. In case of the Template Part block, that source is either the corresponding wp_template_part
post object in the database, or the underlying Block Theme’s template part file.
The Template Part block is the second such “special” block to support firstChild
/lastChild
insertion of hooked blocks, alongside with the Navigation block, which has been supported since version 6.5.
Respect "multiple": false
in hooked blocks (#61902).
A block can set the multiple
block-supports property in its block.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. file to false
, indicating that only one instance of that block should be present in a given post. This is used e.g. in Core Core is the set of software required to run WordPress. The Core Development Team builds WordPress.’s “More” and Footnotes blocks; it is enforced in the editor by disabling the block in the inserter once an instance of it is already present.
However, this setting hasn’t been previously supported by Block Hooks 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.. Instead, a hooked block would be inserted in every location that matched its specified anchor block and relative position with no limit imposed on the number of allowed instances, even if it had ”multiple”: false
set in its block.json. This would sometimes prompt extenders to use a hooked_block_types
filter in order to check if the prospective hooked block was already present. Since these checks would run on every block encountered (as a potential anchor block), they could impact performance negatively.
As of WordPress 6.7, the “multiple”: false
setting is now respected by Block Hooks, freeing extenders from making those checks themselves. Specifically:
- Only one instance of the block will be inserted if it’s not yet present in the current context.
- The block will not be inserted at all if an instance of it is already present in the current context.
As always in Block Hooks parlance, “context” denotes the containing template, template part, pattern, or navigation post that a hooked block is supposed to be inserted into.
The markup of a webpage that uses a Block Theme typically comprises a number of such contexts — one template and any number of template parts, patterns, and navigation posts. Note that the limitation imposed by this changeset only applies on a per-context basis, so it’s still possible that the resulting page contains more than one instance of a hooked block with "multiple": false
set, as each context could contribute up to one such instance.
Leave a Reply