mirror of
https://github.com/WordPress/WordPress.git
synced 2024-11-14 22:56:19 +01:00
6bf6244dc7
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. Built from https://develop.svn.wordpress.org/trunk@56649 git-svn-id: http://core.svn.wordpress.org/trunk@56161 1a063a9b-81f0-0310-95a4-ce76da25c4cd
48 lines
938 B
PHP
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.4-alpha-56649';
|
|
|
|
/**
|
|
* Holds the WordPress DB revision, increments when changes are made to the WordPress DB schema.
|
|
*
|
|
* @global int $wp_db_version
|
|
*/
|
|
$wp_db_version = 55853;
|
|
|
|
/**
|
|
* 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';
|