WordPress/wp-includes/version.php
Bernhard Reiter 798991a0ff Block Hooks: Allow traversal callbacks to modify parent block.
The callbacks returned by `make_before_block_visitor` and `make_after_block_visitor`, respectively, (which are passed as arguments to `traverse_and_serialize_block(s)`) currently accept three arguments, all of which are block arrays (i.e. with properties `blockName`, `attrs`, etc.):
- A ''reference'' to the block they're currently visiting, `&$block`;
- the block's `$parent_block`; and
- the `$prev`ious block (for `make_before_block_visitor`), or the `$next` block (for `make_after_block_visitor`), respectively.

Those arguments are passed to the "block visitor" callbacks by `traverse_and_serialize_block(s)` during traversal. The block that the callback is currently visiting is passed ''by reference'' to allow modifying it, which is e.g. used to inject the `theme` attribute into Template Part blocks.

One major limitation of Block Hooks is that they currently only work with templates, parts, and patterns that ''don't have any user modifications'' (i.e. that come straight from the corresponding theme files, rather than from the database). For WordPress 6.5, it is planned to change that to make Block Hooks work for templates, parts, and patterns that ''do'' have user modifications: #59646.

This will be implemented by storing an attribute on the "anchor" block. While working on that feature, it was found that the aforementioned callbacks will need to modify not only the currently visited `$block`, but also the `$parent_block` -- i.e. that the latter argument needs to be passed by reference as well. This is consistent with the requirement of adding an attribute to an anchor block, as it's not only the currently visited block that can serve as an anchor block (in the case of `before` or `after` sibling insertion), but also its parent (for `first_child` and `last_child` insertion).

If the `$parent_block` argument were to be changed to become a reference in a later WordPress version, this could be considered a backwards-compatibility breaking change. For this reason, this change is instead proposed for 6.4 already, which is the cycle during which the relevant functions were first introduced. This should have no impact on existing code, since nothing currently relies on `$parent_block` remaining unmodified by the respective callback, nor is anything currently modifying that argument.

Props hellofromTonya.
Fixes #59776.
Built from https://develop.svn.wordpress.org/trunk@57038


git-svn-id: http://core.svn.wordpress.org/trunk@56549 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2023-10-31 19:25:19 +00:00

48 lines
938 B
PHP

<?php
/**
* WordPress Version
*
* Contains version information for the current WordPress release.
*
* @package WordPress
* @since 1.2.0
*/
/**
* The WordPress version string.
*
* Holds the current version number for WordPress core. Used to bust caches
* and to enable development mode for scripts when running from the /src directory.
*
* @global string $wp_version
*/
$wp_version = '6.5-alpha-57038';
/**
* Holds the WordPress DB revision, increments when changes are made to the WordPress DB schema.
*
* @global int $wp_db_version
*/
$wp_db_version = 56657;
/**
* Holds the TinyMCE version.
*
* @global string $tinymce_version
*/
$tinymce_version = '49110-20201110';
/**
* Holds the required PHP version.
*
* @global string $required_php_version
*/
$required_php_version = '7.0.0';
/**
* Holds the required MySQL version.
*
* @global string $required_mysql_version
*/
$required_mysql_version = '5.0';