These two new unit tests document how Block Hooks behave with `first_child` and `last_child` relative positions. The hooked blocks will only get inserted in the case where the parent block has at least one child block present. While it seems like a limitation, in practice, it's hard to think of a case where the template would use a parent block without its children. It's more likely to happen with patterns in general, but in the case of patterns wired with the block theme, it also seems unlikely. The reasoning here is that out of the box, the block theme should produce a fully functional and valid HTML.
Props ockham.
See #59313.
Follow-up [56649].
git-svn-id: https://develop.svn.wordpress.org/trunk@56701 602fd350-edb4-49c9-b593-d223f7449a82
Block Hooks allow a third-party block to specify a position relative to a given block into which it will then be automatically inserted (e.g. a "Like" button block can ask to be inserted after the Post Content block, or an eCommerce shopping cart block can ask to be inserted after the Navigation block).
The underlying idea is to provide an extensibility mechanism for Block Themes, in analogy to WordPress' [https://developer.wordpress.org/plugins/hooks/ Hooks] concept that has allowed extending Classic Themes through filters and actions.
The two core tenets for Block Hooks are:
1. Insertion into the frontend should happen right after a plugin containing a hooked block is activated (i.e. the user isn't required to insert the block manually in the editor first); similarly, disabling the plugin should remove the hooked block from the frontend.
2. The user has the ultimate power to customize that automatic insertion: The hooked block is also visible in the editor, and the user's decision to persist, dismiss (i.e. remove), customize, or move it will be respected (and reflected on the frontend).
To account for both tenets, the **tradeoff** was made to limit automatic block insertion to unmodified templates (and template parts, respectively). The reason for this is that the simplest way of storing the information whether a block has been persisted to (or dismissed from) a given template (or part) is right in the template markup.
To accommodate for that tradeoff, [https://github.com/WordPress/gutenberg/pull/52969 UI controls (toggles)] are being added to increase visibility of hooked blocks, and to allow for their later insertion into templates (or parts) that already have been modified by the user.
For hooked blocks to appear both in the frontend and in the editor (see tenet number 2), they need to be inserted into both the frontend markup and the REST API (templates and patterns endpoints) equally. As a consequence, this means that automatic insertion couldn't (only) be implemented at block ''render'' stage, as for the editor, the ''serialized'' (but ''unrendered'') markup needs to be modified.
Furthermore, hooked blocks also have to be inserted into block patterns. Since practically no filters exist for the patterns registry, this has to be done in the registry's `get_registered` and `get_all_registered` methods.
Props gziolo.
Fixes#59313.
git-svn-id: https://develop.svn.wordpress.org/trunk@56649 602fd350-edb4-49c9-b593-d223f7449a82
During work on #59399, it was discovered that ''sibling'' block insertion wasn't likely going to work the way it was planned, which required devising an alternative solution. This new solution requires some changes to `traverse_and_serialize_block(s)`:
- Change the signature of the existing callback such that:
- the return value is a string that will be prepended to the result of the inner block traversal and serialization;
- the function arguments are: a ''reference'' to the current block (so it can be modified inline, which is important e.g. for `theme` attribute insertion), the parent block, and the previous block (instead of the block index and chunk index).
- Add a second callback argument to `traverse_and_serialize_block(s)`, which is called ''after'' the block is traversed and serialized.
- Its function arguments are a reference to the current block, the parent block, and the next block.
Props gziolo.
Fixes#59412. See #59313.
git-svn-id: https://develop.svn.wordpress.org/trunk@56644 602fd350-edb4-49c9-b593-d223f7449a82
Introduces two new functions `traverse_and_serialize_blocks` and `traverse_and_serialize_block` with the additional `$callback` argument. It is possible to pass parent block, block index, chunk index to the callback argument.
Reverts changes applied to `serialize_blocks` and `serialize_block` in #59327 with [56557].
Props ockham, mukesh27.
See #59313.
git-svn-id: https://develop.svn.wordpress.org/trunk@56620 602fd350-edb4-49c9-b593-d223f7449a82
Allow passing a function callback to serialize_block(s) that is invoked on each node in the tree of parsed blocks as it is traversed for serialization.
A function argument was chosen for passing the callback function as it reflects a pattern familiar from other algorithms that apply a given callback function while traversing a data structure -- most notably PHP's own `array_map()`.
Introducing a filter was considered as an alternative but ultimately dismissed. For a fairly low-level and general-purpose function such as `serialize_block()`, using a filter to pass the callback seemed risky, as it also requires ''removing'' that filter after usage in order to prevent the callback from being accidentally applied when `serialize_block()` is called in an entirely different context.
Introducing a separate function for applying a given operation during tree traversal (i.e. independently of serialization) was also considered but dismissed, as it would unnecessarily duplicate tree traversal.
Props dlh, gziolo.
Fixes#59327. See #59313.
git-svn-id: https://develop.svn.wordpress.org/trunk@56557 602fd350-edb4-49c9-b593-d223f7449a82
Per the[https://developer.wordpress.org/coding-standards/inline-documentation-standards/php/#6-file-headers documentation standards], whenever possible, all WordPress files should contain a header DocBlock, regardless of the file’s contents – this includes files containing classes.
However, this recommendation makes less sense for unit test classes if not applied consistently, and the duplicate tags cause some confusion.
This commit aims to reduce confusion and avoid repeating information by combining the DocBlocks.
Follow-up to [55337].
Props sakibmd, fuadragib, robinwpdeveloper, naeemhaque, seakashdiu, jakariaistauk, hasanmisbah, SergeyBiryukov.
Fixes#57723.
git-svn-id: https://develop.svn.wordpress.org/trunk@55457 602fd350-edb4-49c9-b593-d223f7449a82
Adds a `public` visibility to test fixtures, tests, data providers, and callbacks methods.
Adds a `private` visibility to helper methods within test classes.
Renames callbacks and helpers that previously started with a `_` prefix. Why? For consistency and to leverage using the method visibility. Further naming standardizations is beyond the scope of this commit.
Props costdev, jrf, hellofromTonya.
Fixes#54177.
git-svn-id: https://develop.svn.wordpress.org/trunk@52010 602fd350-edb4-49c9-b593-d223f7449a82
The `serializeAttributes()` function in JavaScript uses `JSON.stringify`, which does not encode slashes and unicode characters by default. This resulted in the PHP serialization through `json_encode()` producing different results.
This also switches from `json_encode()` to `wp_json_encode()` to prevent failures when any non UTF-8 characters are included.
Props kevinfodness, SergeyBiryukov, timothyblynjacobs.
Fixes#53936.
git-svn-id: https://develop.svn.wordpress.org/trunk@51674 602fd350-edb4-49c9-b593-d223f7449a82
