The Query Loop block's `taxQuery` attribute now supports an include/exclude structure for term filtering. This updates the server-side query building to handle both the old format (e.g. `{"category":[4]}`) and the new format (e.g. `{"include":{"category":[4]},"exclude":{"post_tag":[5]}}`).
Props ntsekouras, westonruter, peterwilsoncc, mcsf.
Fixes#64416.
Built from https://develop.svn.wordpress.org/trunk@61650
git-svn-id: http://core.svn.wordpress.org/trunk@60961 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Modifies the `resolve_pattern_blocks` function to include metadata for single-root patterns, allowing the pattern `name`, `description`, categories` metadata to be stored in the block attributes.
This enables identification of patterns within templates in the block editor for the purposes of the pattern editing functionality.
Props ramonopoly, andrewserong, talldanwp, westonruter, scruffian, huzaifaalmesbah, audrasjb.
Fixes #64123.
Built from https://develop.svn.wordpress.org/trunk@61617
git-svn-id: http://core.svn.wordpress.org/trunk@60928 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The work in [61438] for Core-64393 removed the block parser classes from Core, which caused numerous scripts to fail because they were missing. Conditional checks were added in [61492] which left WordPress in an inoperable state.
This patch restores the block parser in Core, in preparation for work to remove it from Gutenberg (in a separate patch).
Ironically, the files were removed because the new build was copying them over from Gutenberg and the intent was to avoid having two sources of truth, but this was previously the existing mechanism, so having done nothing to the parser files would have left the status quo. This patch removes the problems originally created by removing the files. They will not be copied from Gutenberg any more and the only source of truth will be Core.
Until removed from Gutenberg, because of the build changes, any changes made on the Gutenberg side will be lost unless manually copied over.
Developed in: https://github.com/WordPress/wordpress-develop/pull/10761
Discussed in: https://core.trac.wordpress.org/ticket/64521
Follow-up to [61438], [61492].
Props dmsnell, mcsf, mukesh27, youknowriad.
Fixes#64521.
Built from https://develop.svn.wordpress.org/trunk@61504
git-svn-id: http://core.svn.wordpress.org/trunk@60815 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changeset improves the Gutenberg build integration to simplify the developer workflow and reinstore a flow similar to how package dependencies worked before the Gutenberg checkout-and-build approach was introduced.
Key improvements:
* Automatic rebuild on ref change: Adds a new `gutenberg:sync` script that stores a hash of the built ref in `.gutenberg-hash` and only rebuilds when the ref changes.
* Full integration on `npm install`: Running `npm install` now produces a fully working development environment with Gutenberg assets in `src/`.
* Clean Gutenberg checkout: Restores Gutenberg's `package.json` after the build completes.
* Stops copying `.js.map` files to `wp-includes/js/dist` since they reference non-existent paths.
* Remove package.json files from the build folder.
* Avoid closures and use prefixed functions.
* Updates build checks to use `jquery.js` instead of `edit-post.js` as the build indicator.
Props youknowriad, ellatrix, mcsf, dmsnell, ntsekouras, jorgefilipecosta, tobiasbg, peterwilsoncc.
Fixes#64393.
Built from https://develop.svn.wordpress.org/trunk@61492
git-svn-id: http://core.svn.wordpress.org/trunk@60803 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Uses the `wp_script_attributes` filter to add a `data-wp-router-options` directive with a `loadOnClientNavigation: true` property for all the interactive blocks that are compatible with client-side navigation to let the Interactivity API router determine which modules it can safely load during client-side navigation.
Props luisherranz, westonruter.
Fixes#64122.
Built from https://develop.svn.wordpress.org/trunk@61019
git-svn-id: http://core.svn.wordpress.org/trunk@60355 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This brings API parity with `WP_Scripts` by implementing opt-in support for printing in the footer via an `in_footer` argument. This argument can be supplied via the `$args` array passed to `wp_enqueue_script_module()` or `wp_register_script_module()`, alongside the existing `fetchpriority` key introduced in #61734. It can also be set for previously-registered script modules via `WP_Script_Modules::set_in_footer()`. This is not applicable to classic themes since modules are enqueued while blocks are rendered after `wp_head` has completed, so all script modules are printed in the footer anyway; the `importmap` script must be printed after all script modules have been enqueued.
Script modules used for interactive blocks (with the Interactivity API) are automatically printed in the footer. Such script modules should be deprioritized because they are not in the critical rendering path due to interactive blocks using server-side rendering. Script modules remain printed at `wp_head` by default, although this default should be revisited since they have deferred execution (and they are printed in the footer for classic themes already, as previously noted). Moving a script module to the footer ensures that its loading does not contend with the loading of critical resources, such as the LCP element's image resource, and LCP is improved as a result.
This also improves specificity of some PHP types, it ensures that script modules can't be registered with an empty ID, and it prevents printing script modules with empty `src` URLs.
Developed in https://github.com/WordPress/wordpress-develop/pull/9867
Follow-up to [60704].
Props b1ink0, westonruter, jonsurrell, peterwilsoncc, vipulpatil, mindctrl.
See #61734.
Fixes#63486.
Built from https://develop.svn.wordpress.org/trunk@60999
git-svn-id: http://core.svn.wordpress.org/trunk@60335 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Allow scripts and script modules to be registered with a `fetchpriority` of `auto` (default), `high`, `low`:
* When registering a script, add a `fetchpriority` arg to go alongside the `strategy` arg which was added for loading scripts with the `defer` and `async` loading strategies. See #12009.
* For script modules, introduce an `$args` array parameter with a `fetchpriority` key to the `wp_register_script_module()`, and `wp_enqueue_script_module()` functions (and their respective underlying `WP_Script_Modules::register()` and `WP_Script_Modules::enqueue()` methods). This `$args` parameter corresponds with the same parameter used when registering non-module scripts.
* Also for script modules, introduce `WP_Script_Modules::set_fetchpriority()` to override the `fetchpriority` for what was previously registered.
* Emit a `_doing_it_wrong()` warning when an invalid `fetchpriority` value is used, and when `fetchpriority` is added to a script alias.
* Include `fetchpriority` as an attribute on printed `SCRIPT` tags as well as on preload `LINK` tags for static script module dependencies.
* Use a `fetchpriority` of `low` by default for:
* Script modules used with the Interactivity API. For overriding this default in blocks, see [https://github.com/WordPress/gutenberg/issues/71366 Gutenberg#71366].
* The `comment-reply` script.
* Improve type checks and type hints.
Developed in [https://github.com/WordPress/wordpress-develop/pull/8815 GitHub PR], with [https://github.com/WordPress/gutenberg/pull/70173 companion for Gutenberg].
Props westonruter, jonsurrell, swissspidy, luisherranz, kraftbj, audrasjb, dennysdionigi.
Fixes#61734.
Built from https://develop.svn.wordpress.org/trunk@60704
git-svn-id: http://core.svn.wordpress.org/trunk@60040 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Adds explanatory comment indicating why the optimization was added
and guarding against accidental removal.
This is a documentation-only change and should include no functional
or visual changes.
Props audrasjb, dmsnell, joemcgill, sirlouen, westonruter, zunaid321.
Follow-up to [60316].
Fixes#63588.
Built from https://develop.svn.wordpress.org/trunk@60400
git-svn-id: http://core.svn.wordpress.org/trunk@59736 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changeset introduces a development mode for block editor styles. When `SCRIPT_DEBUG` is enabled, block editor styles now use the file modification time as their version, ensuring cache busting during development. This matches the behavior that already exists for block scripts.
Previously, block editor styles only used the version from `block.json`, which doesn't change during development, causing styles to be cached even after changes.
Props helgatheviking, abcd95, gziolo, whaze, audrasjb, sandeepdahiya, rollybueno.
Fixes#63254.
Built from https://develop.svn.wordpress.org/trunk@60355
git-svn-id: http://core.svn.wordpress.org/trunk@59691 1a063a9b-81f0-0310-95a4-ce76da25c4cd
There has been a memory inefficiency inside of `do_blocks()` where it
parses the given content then iterates through each top-level block to
render it. Unfortunately each top-level block can considerably add to
the overall memory use involved, and once moving on to the next
top-level block, all of the allocated memory will be retained until the
end of the call to `do_blocks()`.
In this change, each parsed block sub-tree is freed via reset to `null`
after it has been rendered. All top-level blocks are rendered
independently of each other and so this operation is safe — there are no
data dependencies between them.
For a test post of length 2.3 MB containing 138 top-level blocks, this
brought the minimum memory requirement for the PHP process down from
around 450 MB to around 316 MB. This was “around” since the memory
requirements are non-deterministic and some runs will succeed while
other runs will crash for out-of-memory given the same `memory_limit`.
Impact of this change will be most profound when there exist one or
more top-level blocks which allocate a significant amount of memory
which are not the last top-level-block in a post. This means that
this change might even impact small and typical posts, if the right
blocks are near the start of the post.
Developed in https://github.com/wordpress/wordpress-develop/pull/8999
Discussed in https://core.trac.wordpress.org/ticket/63588
Props dmsnell, joemcgill.
Fixes#63588.
Built from https://develop.svn.wordpress.org/trunk@60316
git-svn-id: http://core.svn.wordpress.org/trunk@59652 1a063a9b-81f0-0310-95a4-ce76da25c4cd
As of [59523], Block Hooks are applied to post content. In order to allow for insertion of a hooked block as `first_child` or `last_child` of the containing Post Content block, we wrap the block's post content (as obtained from the DB) in a temporary `<!-- wp:post-content -->` wrapper block, apply the Block Hooks algorithm to the resulting markup, and remove the wrapper block. (The same technique is applied for the Synced Pattern block -- see [59543] -- as well as the Navigation block.)
However, this caused a problem when a hooked block was marked for insertion before `before` or `after` a Post Content block: The logic that's supposed to remove the temporary wrapper block after the Block Hooks algorithm runs erroneously removed that hooked block's delimiter instead of the wrapper block, producing garbled markup as a result.
This changeset fixes the issue by adding a `hooked_block_types` filter (with `PHP_INT_MAX` priority) that removes any blocks hooked `before` or `after` a Post Content block, ''if'' the current context is a post object. This prevents any blocks hooked that way from being "absorbed" into the corresponding post object's content; it retains the ability to hook blocks `before` and `after` a Post Content block in any other context (e.g. a template). (The same principle is applied to Synced Pattern and Navigation blocks.)
Props obenland, jorbin, gziolo, bernhard-reiter.
Fixes#63287.
Built from https://develop.svn.wordpress.org/trunk@60173
git-svn-id: http://core.svn.wordpress.org/trunk@59509 1a063a9b-81f0-0310-95a4-ce76da25c4cd
[59132] introduced the `wp_register_block_metadata_collection()` function and underlying `WP_Block_Metadata_Registry` class to allow central registration of a block metadata PHP manifest file in favor of parsing individual JSON files. While this improves performance, it only increases the amount of APIs and code that plugin developers need to use to register their block types properly.
This changeset introduces a new function `wp_register_block_types_from_metadata_collection()` that improves the developer experience of registering block types from a single source, by handling it in only a single function call.
Developers that already use a generated block metadata PHP manifest file (e.g. via the `wp-scripts build-blocks-manifest` tool) can now call `wp_register_block_types_from_metadata_collection()` with that file to automatically register all block types from that block metadata collection. Individual calls to `register_block_type()` or `register_block_type_from_metadata()` are no longer necessary when the new function is used.
Props flixos90, gziolo, joemcgill, mreishus, mukesh27, swissspidy.
Fixes#62267.
See #62002.
Built from https://develop.svn.wordpress.org/trunk@59874
git-svn-id: http://core.svn.wordpress.org/trunk@59216 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Introduce a new `ignore` value for the `sticky` query argument. When this value is used, the query will not prepend sticky posts at the top but display them in the natural order.
Props mamaduka, peterwilsoncc, audrasjb, mikinc860, poena, dhruvishah2203, joemcgill.
Fixes#62908.
Built from https://develop.svn.wordpress.org/trunk@59866
git-svn-id: http://core.svn.wordpress.org/trunk@59208 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Introduce a new function, `apply_block_hooks_to_content_from_post_object`, to colocate the logic used to temporarily wrap content in a parent block (with `ignoredHookedBlocks` information fetched from post meta) alongside the call to `apply_block_hooks_to_content`. Fetching that information from post meta is required for all block types that get their content from post objects, i.e. Post Content, Synced Pattern, and Navigation blocks.
Additionally, the newly introduced function contains logic to ensure that insertion of a hooked block into the `first_child` or `last_child` position of a given Post Content block works, even if that block only contains "classic" markup (i.e. no blocks).
Props bernhard-reiter, gziolo, mamaduka.
Fixes#61074, #62716.
Built from https://develop.svn.wordpress.org/trunk@59838
git-svn-id: http://core.svn.wordpress.org/trunk@59180 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Block Hooks were previously only applied to layout elements such as templates, template parts, patterns, and navigation menus -- things that are edited in the Site Editor.
This changeset enables Block Hooks in post content. The parity between frontend and editor is preserved: Blocks inserted by Block Hooks are visible both on the frontend and in the editor, and any customizations made by the user are respected on the frontend.
This is possible thanks to setting the `metadata.ignoredHookedBlocks` attribute on anchor blocks (a technique first introduced in [57594]). For first child and last child insertion into a Post Content block, the corresponding post object's `_wp_ignored_hooked_blocks` post meta is set.
Props bernhard-reiter, gziolo, jonsurrell, karolmanijak, leewillis77.
Fixes#61074.
Built from https://develop.svn.wordpress.org/trunk@59523
git-svn-id: http://core.svn.wordpress.org/trunk@58909 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Ensure that the `$context` arg passed from `update_ignored_hooked_blocks_postmeta` to `apply_block_hooks_to_content` (and from there, to filters such as `hooked_block_types` and `hooked_block`) has the correct type (`WP_Post`).
Filters hooked to `hooked_block_types` etc can typically include checks that conditionally insert a hooked block depending on `$context`. Prior to this changeset, a check like `if ( $context instanceof WP_Post )` would incorrectly fail, as `$context` would be a `stdClass` instance rather than a `WP_Post`. As a consequence, a hooked block inside of a Navigation post object that was modified by the user would not be marked as ignored by `update_ignored_hooked_blocks_postmeta`, and thus be erroneosly re-inserted by the Block Hooks algorithm.
Props bernhard-reiter.
Fixes#62639.
Built from https://develop.svn.wordpress.org/trunk@59482
git-svn-id: http://core.svn.wordpress.org/trunk@58868 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Typically, when registering a new block type, its metadata is read from the provided `block.json` file. The more block types are registered on a site, the more costly becomes this process, as it involves filesystem reads and parsing JSON.
WordPress Core's built-in blocks have in the past worked around that by having a auto-generated PHP manifest file that includes the already parsed JSON data for all blocks. This changeset effectively allows plugins to do the same, by introducing a new API function `wp_register_block_metadata_collection()`. The WordPress Core block manifest is now handled using this API as well, rather than custom logic baked into `register_block_type_from_metadata()`.
The `wp_register_block_metadata_collection()` function requires two parameters:
* `$path`: The base path in which block files for the collection reside.
* `$manifest`: The path to the manifest file for the collection.
Every `block.json` file that is supposed to be part of the collection must reside within the provided `$path`, within its own block-specific directory matching the block name (without the block namespace). For example, for a collection `$path` of `/wp-content/plugins/test-plugin` and a block `test-plugin/testimonial`, the block file could be `/wp-content/plugins/test-plugins/blocks/testimonial/block.json`.
It is recommended that plugins use the new API function for enhanced performance, especially if they register several block types. However, the use of the function is entirely optional. Not using it will not result in any difference in user-facing behavior.
Props mreishus, flixos90, gziolo, spacedmonkey, azaozz, mukesh27.
Fixes#62002.
Built from https://develop.svn.wordpress.org/trunk@59132
git-svn-id: http://core.svn.wordpress.org/trunk@58528 1a063a9b-81f0-0310-95a4-ce76da25c4cd
If a prospective hooked block has its `multiple` block-supports field set to `false` (thus allowing only one instance of the block to be present), ensure that:
1. Only one instance of the block will be inserted if it's not yet present in the current context.
2. 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.
Props bernhard-reiter, jonsurrell, gziolo.
Fixes#61902.
Built from https://develop.svn.wordpress.org/trunk@59124
git-svn-id: http://core.svn.wordpress.org/trunk@58520 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Introduces post format support for both the Query Block with the new parameter `format`. In the `build_query_vars_from_query_block()` function, this is converted to a `post_format` taxonomy query passed to `WP_Query`.
Also introduces the `format` parameter to the REST API's Posts controller to support the feature in the Query block. The parameter type is an enumerated string accepted the post formats supported by each post type.
Props poena, mukesh27, mamaduka, noisysocks, TimothyBlynJacobs.
Fixes#62014.
Built from https://develop.svn.wordpress.org/trunk@59115
git-svn-id: http://core.svn.wordpress.org/trunk@58511 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In the Patterns registry, use `apply_block_hooks_to_content` (introduced in [58291]) instead of the `WP_Block_Patterns_Registry` class's private `get_content` method. (The latter is removed as part of this changeset.)
In a similar vein, use `apply_block_hooks_to_content` in the `_build_block_template_result_from_file` and `_build_block_template_result_from_post` functions, respectively.
For that to work, `apply_block_hooks_to_content` is amended to inject the `theme` attribute into Template Part blocks, even if no hooked blocks are present.
This kind of centralization is required as a preparation for #61902.
Props bernhard-reiter, jonsurrell.
See #61902.
Built from https://develop.svn.wordpress.org/trunk@59101
git-svn-id: http://core.svn.wordpress.org/trunk@58497 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Removes query alteration from `build_comment_query_vars_from_block` by introducing a new way to pass the `$page` as argument to functions handling pagination for the comments.
Props cybr, santosguillamot, bernhard-reiter, gziolo.
Fixes#60806.
Built from https://develop.svn.wordpress.org/trunk@59081
git-svn-id: http://core.svn.wordpress.org/trunk@58477 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously, the `variations` field in a block.json file could be used to provide a static list of the block's variations (i.e., an array). Alternatively, the block's `variation_callback` could be set during server-side block registration to point to a PHP function to generate those variations.
This changeset makes it so that the block.json `variations` field can be alternatively set to a string, which will be interpreted as the filename of a PHP file that generates the variations.
It is loosely modeled after [54132], which introduced the `render` field for `block.json`, as a way to point to a PHP file instead of providing a `render_callback`.
Props bernhard-reiter, gziolo.
Fixes#61280.
Built from https://develop.svn.wordpress.org/trunk@58801
git-svn-id: http://core.svn.wordpress.org/trunk@58197 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The Block Hooks mechanism was previously extended to allow insertion of a block as a Navigation block's first or last child. This was implemented by storing the `ignoredHookedBlocks` array in the corresponding `wp_navigation` post's post meta (instead of a metadata attribute on the anchor block).
This changeset extends that mechanism to Template Part blocks, by storing said metadata in the corresponding `wp_template_part` post's post meta, thus allowing extenders to use Block Hooks to insert a block as a Template Part block's first or last child, respectively.
Props tomjcafferkey, bernhard-reiter.
Fixes#60854.
Built from https://develop.svn.wordpress.org/trunk@58614
git-svn-id: http://core.svn.wordpress.org/trunk@58047 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Prior to this changeset, the function `update_ignored_hooked_blocks_postmeta()` used the core function `update_post_meta()` to write `_wp_ignored_hooked_blocks` data to the database during an operation that is preparing a post to be inserted.
Since we have access to the incoming changes that are being prepared we can remove this database operation in favour of writing the data to the post object provided under `meta_input`.
Doing this means two things:
1. It allows us to store postmeta for new posts that are about to be created since they don't have an `ID` yet (which is information `update_post_meta()` needs).
2. The core controller will take care of updating postmeta in a more predictable pattern.
Props tomjcafferkey, bernhard-reiter.
Fixes#61495.
Built from https://develop.svn.wordpress.org/trunk@58578
git-svn-id: http://core.svn.wordpress.org/trunk@58025 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In a similar vein as [58291], this changeset introduces a new `insert_hooked_blocks_into_rest_response` function and hooks it to the `rest_prepare_wp_navigation` filter.
This is part of an ongoing effort to move Block Hooks related code out of the Navigation block. Specifically, `insert_hooked_blocks_into_rest_response` is based on `block_core_navigation_insert_hooked_blocks_into_rest_response`. Eventually, it will be possible to deprecate the latter.
Follow-up to [58291].
See #60759.
Built from https://develop.svn.wordpress.org/trunk@58292
git-svn-id: http://core.svn.wordpress.org/trunk@57752 1a063a9b-81f0-0310-95a4-ce76da25c4cd
As of [57790], the Templates endpoint uses the `rest_pre_insert_*` filter to inject the `ignoredHookedBlocks` metadata attribute into anchor blocks, prior to persisting a template or template part to the database. The same principle was implemented for the Navigation endpoint (where additionally, first and last child blocks added at the top level are store in the `wp_navigation` post object's post meta). The required logic was added to the Navigation block's code, i.e. inside the Gutenberg code repository, and then synchronized to Core.
In order to harmonize the code between the two endpoints, this changeset introduces a new `update_ignored_hooked_blocks_postmeta` function, which is based on the Navigation block's `block_core_navigation_update_ignore_hooked_blocks_meta`, alongside a few helper functions, and hooks it to the `rest_pre_insert_wp_navigation` filter hook. (The Navigation block has been prepared in [58275] to add an additional conditional to check for the new `update_ignored_hooked_blocks_postmeta` filter so there won't be any collisions.)
Eventually, this will allow to deprecate `block_core_navigation_update_ignore_hooked_blocks_meta` (and some related functions), and remove the relevant code from the Navigation block. It also paves the way for some other future changes, such as inserting a hooked block as a Template Part block's first or last child (#60854).
Props tomjcafferkey, bernhard-reiter.
Fixes#60759.
Built from https://develop.svn.wordpress.org/trunk@58291
git-svn-id: http://core.svn.wordpress.org/trunk@57751 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The Block Hooks UI relies on the `ignoredHookedBlocks` metadata when determining whether to show the toggle in the Site Editor. The problem is that for uncustomized templates we don't add this metadata.
Currently the visitor functions have a default callback of `insert_hooked_blocks` and we only add the metadata when we're writing to the database via an available filter in the template controller.
This changeset creates a new callback which both inserts the hooked blocks and adds the `ignoredHookedBlocks` metadata to the anchor block, and uses this new callback explicitly in the visitor functions that are run upon reading from the database.
We continue to set the `ignoredHookedBlocks` metadata when writing to the database, i.e. this operation happens twice. Although not ideal, this is necessary to cover the following scenarios:
* When the user adds an anchor block within the editor, we still need to add the `ignoredHookedBlocks` meta to it to prevent hooked blocks hooking on to it unexpectedly on the frontend. This is required to keep parity between the frontend and editor.
* When a user writes template data to the database directly through the API (instead of the editor), we need to again ensure we're not inserting hooked blocks unexpectedly.
It is worth noting that with this change, the first hooked block to insert relative to its anchor block will be accepted. Any additional blocks of the same type (e.g. a second `core/loginout` block) trying to hook onto the same anchor block will be ignored, irrespective of the position.
Props tomjcafferkey, bernhard-reiter, gziolo.
Fixes#59574.
Built from https://develop.svn.wordpress.org/trunk@58186
git-svn-id: http://core.svn.wordpress.org/trunk@57649 1a063a9b-81f0-0310-95a4-ce76da25c4cd
