In WordPress 6.3, [https://wordpress.org/documentation/article/reusable-blocks/ Reusable Blocks were renamed to Patterns]. A synced pattern will behave in exactly the same way as a reusable block.
This commit updates some references in DocBlocks and inline comments to use the new name.
Follow-up to [56030].
Props benjaminknox, oglekler, hellofromTonya, marybaum, nicolefurlan.
Fixes#59388.
git-svn-id: https://develop.svn.wordpress.org/trunk@57032 602fd350-edb4-49c9-b593-d223f7449a82
This makes it possible to register a block by passing an array of arguments, without the presence of a `block.json` file.
Follow-up to [48141], [49948].
Props aristath, spacedmonkey, mukesh27, costdev, audrasjb, oglekler, felipeelia, hellofromTonya.
Fixes#56865.
git-svn-id: https://develop.svn.wordpress.org/trunk@57026 602fd350-edb4-49c9-b593-d223f7449a82
Both the `$pre_callback` and `$post_callback` functions that are given as arguments to `traverse_and_serialize_block(s)` receive a reference to the current block as their first argument. However, while any changes that the "pre" callback makes to the block are reflected by the serialized markup, the same wasn't true for the "post" callback: Any changes that it made were only applied ''after'' the block had already been serialized.
This commit changes the behavior such that `$post_callback`'s changes to the current block are also reflected in the serialized markup.
See #59646.
Props gziolo.
Fixes#59669.
git-svn-id: https://develop.svn.wordpress.org/trunk@56970 602fd350-edb4-49c9-b593-d223f7449a82
It was found that Template Part blocks were broken in the Site Editor, showing the `Template part has been deleted or is unavailable` message, due to a missing `theme` attribute.
This bug seems to have been introduced by [56896], whose goal was to only inject that attribute into the markup returned by the templates and patterns REST API endpoints but not on the frontend, in order to improve performance. It has been demonstrated locally that reverting that changeset fixes the bug.
Reverts [56896].
Props mmcalister, swisspidy, thelovelist, hellofromTonya, pbiron, Pauthake015, richtabor, nicolefurlan, huzaifaalmesbah, annezazu, kafleg, aegkr, sunitarai, shresthaaman, andraganescu, onemaggie, gziolo.
Fixes#59629.
git-svn-id: https://develop.svn.wordpress.org/trunk@56960 602fd350-edb4-49c9-b593-d223f7449a82
Having the patterns registry inject the `theme` attribute into all Template Part blocks inside every pattern was found to negatively impact performance. It turns out that it's only required for the editor (i.e. in the REST API) but not on the frontend; there, it's instead possible to fall back to the currently active theme.
The latter change was made to the Pattern and Template Part blocks in https://github.com/WordPress/gutenberg/pull/55217, which was sync'ed to Core in [56849]. Consequently, this changeset removes `theme` attribute insertion from the frontend.
Props flixos90, gziolo, dmsnell, hellofromtonya.
Fixes#59583.
git-svn-id: https://develop.svn.wordpress.org/trunk@56896 602fd350-edb4-49c9-b593-d223f7449a82
Prior to this changeset, `get_hooked_blocks` was called four times ''for every parsed block'' in each template, template part, and pattern. With this changeset applied, `get_hooked_blocks` is called only once per template, template part, or pattern.
Additionally, `get_hooked_blocks` is called only once when returning the list of all registered patterns. (The latter modification brings the implementation closer to its state prior to Block Hooks.)
Finally, when there are no registered hooked blocks or `hooked_block_types` filters, parsing, hooked block insertion, and re-serializing is skipped altogether.
Props gziolo, flixos90, joemcgill, dmsnell, spacedmonkey, hellofromtonya.
Fixes#59383.
git-svn-id: https://develop.svn.wordpress.org/trunk@56805 602fd350-edb4-49c9-b593-d223f7449a82
The `VariableAnalysis` standard is not used by WP Core.
Follow-up to [50958], [51003], [52049], [52051], [52069], [53072], [54132], [55132], [56363], [56738], [56743], [56751], [56752].
Props jrf.
See #59161.
git-svn-id: https://develop.svn.wordpress.org/trunk@56753 602fd350-edb4-49c9-b593-d223f7449a82
In the context of register_block_script_handle, the get_block_asset_url function may return false when an empty string is provided as the input. This behavior is intended to prevent the generation of invalid URLs. However, when the script loading strategy is set to "defer" while passing false, it triggers a "doing it wrong" message.
This situation becomes problematic, especially for scenarios where the scripts haven't been built yet. In such cases, the realpath call returns an empty string because the file doesn't exist. To address this issue, we now perform a simple check to ensure that the script URI is not empty before applying the "defer" loading strategy. This adjustment prevents unnecessary deferral of loading for scripts with empty URIs.
Follow on from [56683] and [56033].
Props kebbet, mukesh27, swissspidy, westonruter, spacedmonkey.
Fixes#59475
git-svn-id: https://develop.svn.wordpress.org/trunk@56744 602fd350-edb4-49c9-b593-d223f7449a82
`_wp_array_get()` is an expensive function, and it's called thousands of times on each page view on the front end. While the function performance was slightly improved in #58376, it is still called more times than it should be.
This commit aims to further optimize its usage:
* In many cases, `_wp_array_get()` can be replaced with a much simpler and faster `isset()` check.
* The `isset()` function is capable of checking nested arrays, so `isset( $foo['a']['b']['c'] )` will return false even if `$foo['a']` is unset, without throwing any errors or warnings.
* When `_wp_array_get()` cannot be directly replaced with `isset()`, it would be good practice to wrap it in an `isset()` function so that `_wp_array_get()` only runs when it needs to.
Original PR from Gutenberg repository:
* [https://github.com/WordPress/gutenberg/pull/51116#51116 Performance improvement: Reduce the use of the _wp_array_get() function]
Follow-up to [55851], [56382].
Props aristath, jrf, spacedmonkey, mukesh27, swissspidy, hellofromTonya.
Fixes#59405.
git-svn-id: https://develop.svn.wordpress.org/trunk@56709 602fd350-edb4-49c9-b593-d223f7449a82
All existing calls of `get_hooked_blocks()` in non-test code are currently wrapped in an extra `array_keys()` call. This changeset absorbs that logic into the function and changes the structure of the return value accordingly.
Furthermore, this allows us to remove the extra `$relative_position` argument (introduced in [56673]) from the function again, as the same data can now be simply fetched via array access.
Props gziolo, spacedmonkey, mukesh27.
See #59383.
git-svn-id: https://develop.svn.wordpress.org/trunk@56704 602fd350-edb4-49c9-b593-d223f7449a82
This commit introduces a valuable utility function, get_block_asset_url, designed to simplify the retrieval of block asset URLs, such as those for CSS and JavaScript files. This utility eliminates redundancy in both register_block_script_handle and register_block_style_handle. Additionally, `get_block_asset_url` incorporates an early exit mechanism to optimize performance.
This update includes comprehensive unit tests, covering various scenarios, including asset registration from core (wp-includes), themes, child themes, plugins, and mu-plugins.
Props spacedmonkey, joemcgill, flixos90, gziolo.
Fixes#58525.
git-svn-id: https://develop.svn.wordpress.org/trunk@56683 602fd350-edb4-49c9-b593-d223f7449a82
In [50761], the block_has_support function was introduced. However, using `property_exists` within this function negatively impacted its performance. This commit replaces the `property_exists` function call with `instanceof WP_Block_Type`, resulting in improved performance.
Props mukesh27, gziolo, spacedmonkey.
Fixes#59441.
git-svn-id: https://develop.svn.wordpress.org/trunk@56678 602fd350-edb4-49c9-b593-d223f7449a82
In [56610], the get_hooked_blocks function was introduced. However, using property_exists within this function negatively impacted its performance. This commit replaces the property_exists function call with instanceof WP_Block_Type, resulting in improved performance.
Props gziolo, spacedmonkey.
See #59383.
git-svn-id: https://develop.svn.wordpress.org/trunk@56677 602fd350-edb4-49c9-b593-d223f7449a82
Per discussion in #59424, there's agreement that the new `hooked_block_types` filter (introduced in [56673]) covers conditional addition and removal of hooked blocks better and at a higher level than the `inject_hooked_block_markup` filter that was originally added in [56649] for that same purpose.
Consequently, this changeset removes the latter filter.
Props gziolo.
Fixes#59439.
git-svn-id: https://develop.svn.wordpress.org/trunk@56674 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
In [56618], three functions (`insert_inner_block`, `prepend_inner_block`, and `append_inner_block`) were introduced. They were meant to be used for insertion of hooked blocks; however, it was discovered that the original idea wouldn't work for sibling insertion. Instead, a different approach will be taken (see #59412), and these functions are no longer needed and can thus be removed.
Reverts [56618].
See #59412, #59385, #59313.
git-svn-id: https://develop.svn.wordpress.org/trunk@56634 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
For #59313, we need to implement functions to insert a given parsed block into another parsed block's inner blocks, and to prepend and append to that array, respectively.
We will use those functions in combination with `traverse_and_serialize_blocks` (see #59327) to implement automatic insertion of hooked blocks into block templates and patterns.
Props gziolo.
Fixes#59385.
git-svn-id: https://develop.svn.wordpress.org/trunk@56618 602fd350-edb4-49c9-b593-d223f7449a82
In order to implement Block Hooks (see #59313), we added block_hooks field to the WP_Block_Type class, as well as to block registration related functions. In this follow-up, new helper function gets introduced that is going to compute the list of hooked blocks by other registered blocks for a given block type.
Extracted from https://github.com/WordPress/wordpress-develop/pull/5158 and covered with unit tests.
Props ockham.
Fixes#59383.
git-svn-id: https://develop.svn.wordpress.org/trunk@56610 602fd350-edb4-49c9-b593-d223f7449a82
In order to implement Block Hooks, we need to add a new `block_hooks` field to the `WP_Block_Type` class, as well as to block registration related functions, the block types REST API controller, etc.
Props gziolo.
Fixes#59346. See #59313.
git-svn-id: https://develop.svn.wordpress.org/trunk@56587 602fd350-edb4-49c9-b593-d223f7449a82
All blocks relevant for the excerpt are already being parsed in `excerpt_remove_blocks()`. Therefore running `do_blocks()` on the post content only to create the excerpt is unnecessary and wasteful from a performance perspective.
Props thekt12, spacedmonkey, mukesh27, joemcgill.
Fixes#58682.
git-svn-id: https://develop.svn.wordpress.org/trunk@56560 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
Previously, in `register_block_script_handle()` the `$script_uri` variable initialized with a `plugins_url()` call that was reported to invoke four times. In this patch the var is initialized as a blank string with a fallback to use the `plugins_url()` if the other intended conditions are not met.
Props mukesh27, daxelrod, adamsilverstein, davidbaumwald.
Fixes#59181.
git-svn-id: https://develop.svn.wordpress.org/trunk@56455 602fd350-edb4-49c9-b593-d223f7449a82
Most block feature checks are for a single feature string, and for such cases it is not intuitive to require an array for the `$feature` parameter of the `block_has_support()` function.
This changeset brings it in line with other functions like `post_type_supports()`, allowing to pass a string for the `$feature`. An array is still supported for more complex cases where support for sub-features needs to be determined. This change furthermore includes a very minor performance tweak by avoiding calls to the `_wp_array_get()` function if a single feature string is being checked for.
Props thekt12, nihar007, mukesh27, swissspidy.
Fixes#58532.
git-svn-id: https://develop.svn.wordpress.org/trunk@56382 602fd350-edb4-49c9-b593-d223f7449a82
Adds the `excerpt_remove_footnotes` function to trim footnote anchors from post excerpts.
Props: ramonopoly, costdev, mukesh27, mcsf, azaozz.
Fixes#58805.
git-svn-id: https://develop.svn.wordpress.org/trunk@56244 602fd350-edb4-49c9-b593-d223f7449a82
This changeset fixes both `register_block_script_handle()` and `register_block_style_handle()` functions, allowing for child themes to access and utilise
blocks defined in parent themes.
Previously these functions could not handle blocks registered in Parent themes. This changeset fixes the issue by determining whether the given asset path
belongs to either of the template or stylesheet directories (Parent and Child themes respectively) as opposed to just checking using
`get_theme_file_path('')`.
Props jacknotman, Levdbas, audrasjb, guillaumeturpin, leprincenoir, whaze, isabel_brison.
Fixes#57566.
--Cette ligne, et les suivantes ci-dessous, seront ignorées--
M trunk/src/wp-includes/blocks.php
git-svn-id: https://develop.svn.wordpress.org/trunk@56183 602fd350-edb4-49c9-b593-d223f7449a82
This changeset adds handler for multiple cases where author data can be passed to the Query Block:
- array: array of author ids
- string: comma separated author ids
- integer: single author id
Props adi3890, costdev, mayur8991, oglekler.
Fixes#58426.
git-svn-id: https://develop.svn.wordpress.org/trunk@56109 602fd350-edb4-49c9-b593-d223f7449a82
In [52069] the function `wp_common_block_scripts_and_styles` was changed load individual theme stylesheets, if the current theme supports block styles and loading separate core block assets. To do this, the function calls many expensive file operation functions, such as `glob`, `file_exists` and `file_get_contents`. This is wasteful, as these functions are loaded on every page request, even request that do not include blocks, like REST API calls. In [56044] all core block styles are registered in a single place. In `register_core_block_style_handles` calls `glob` to get all css styles in block directories. While registering style and editor styles, also register block theme styles, under a new style handle. Example `wp-block-avatar-theme`. If the current theme supports block styles, also request the block to enqueue the theme style on the front end. As these new stylesheets have a path attribute set, the function `wp_maybe_inline_styles` will automatically inline the styles for you.
Props spacedmonkey, flixos90, oandregal, costdev, audrasjb, mukesh27.
Fixes#58560.
git-svn-id: https://develop.svn.wordpress.org/trunk@56064 602fd350-edb4-49c9-b593-d223f7449a82
Register all core blocks in a new function called `register_core_block_style_handles`. This mirrors the function `wp_default_styles` where all core styles are registered in one place. This improves block registration performance, as it avoids expensive file lookups, like realpath in `register_block_style_handle`. The new function `register_core_block_style_handles` uses `glob` to get all css files in the blocks directory. This glob is cached in a transient to save lookups on subsequent requests. The function `register_block_style_handle` now checks to see if the style handle is already registered before trying to register it again.
Props mukesh27, westonruter, flixos90, joemcgill, spacedmonkey.
Fixes#58528.
git-svn-id: https://develop.svn.wordpress.org/trunk@56044 602fd350-edb4-49c9-b593-d223f7449a82
`str_contains()` was introduced in PHP 8.0 to perform a case-sensitive check indicating if the string to search in (haystack) contains the given substring (needle).
WordPress core includes a polyfill for `str_contains()` on PHP < 8.0 as of WordPress 5.9.
This commit replaces `false !== strpos( ... )` with `str_contains()` in core files, making the code more readable and consistent, as well as better aligned with modern development practices.
Follow-up to [55988].
Props spacedmonkey.
See #58220.
git-svn-id: https://develop.svn.wordpress.org/trunk@56021 602fd350-edb4-49c9-b593-d223f7449a82
This changeset fixes a bug where WordPress core's own block editor styles (`wp-block-{$block_name}-editor`) were referencing the same CSS files as their frontend equivalents (`wp-block-{$block_name}`). This would result in incorrect frontend styles potentially being loaded in the block editor.
Tests for the related logic have been added.
Props flixos90, joemcgill, mukesh27, spacedmonkey.
Fixes#58605.
git-svn-id: https://develop.svn.wordpress.org/trunk@56005 602fd350-edb4-49c9-b593-d223f7449a82
`str_contains()` was introduced in PHP 8.0 to perform a case-sensitive check indicating if the string to search in (haystack) contains the given substring (needle).
WordPress core includes a polyfill for `str_contains()` on PHP < 8.0 as of WordPress 5.9.
This commit replaces `false !== strpos( ... )` with `str_contains()` in core files, making the code more readable and consistent, as well as better aligned with modern development practices.
Follow-up to [52039], [52040], [52326], [55703], [55710], [55987].
Props Soean, spacedmonkey, costdev, dingo_d, azaozz, mikeschroder, flixos90, peterwilsoncc, SergeyBiryukov.
Fixes#58206.
git-svn-id: https://develop.svn.wordpress.org/trunk@55988 602fd350-edb4-49c9-b593-d223f7449a82
This changeset replaces `style` with `style_handle` in the description of `$style_properties` to better match `WP_Block_Styles_Registry::register()`.
Follow-up to [46111], [48102].
Props bacoords, dilipbheda, audrasjb.
Fixes#58562.
See #57840.
git-svn-id: https://develop.svn.wordpress.org/trunk@55952 602fd350-edb4-49c9-b593-d223f7449a82
In `register_block_type_from_metadata` function, skip calling `file_exists` on core blocks. Core blocks are part of the codebase and will never not exist. Not calling this function is better for performance, as the file lookup can be expensive.
Props spacedmonkey, joemcgill.
Fixes#58385.
git-svn-id: https://develop.svn.wordpress.org/trunk@55910 602fd350-edb4-49c9-b593-d223f7449a82
Ensures that the block delimiter comments are of a valid form: opening with `<!--` and closing with `-->`.
Props xknown, isabel_brison, peterwilsoncc.
git-svn-id: https://develop.svn.wordpress.org/trunk@55762 602fd350-edb4-49c9-b593-d223f7449a82
`str_starts_with()` was introduced in PHP 8.0 to perform a case-sensitive check indicating if the string to search in (haystack) begins with the given substring (needle).
WordPress core includes a polyfill for `str_starts_with()` on PHP < 8.0 as of WordPress 5.9.
This commit replaces `0 === strpos( ... )` with `str_starts_with()` in core files, making the code more readable and consistent, as well as improving performance.
While `strpos()` is slightly faster than the polyfill on PHP < 8.0, `str_starts_with()` is noticeably faster on PHP 8.0+, as it is optimized to avoid unnecessarily searching along the whole haystack if it does not find the needle.
Follow-up to [52039], [52040], [52326].
Props spacedmonkey, costdev, sabernhardt, mukesh27, desrosj, jorbin, TobiasBg, ayeshrajans, lgadzhev, SergeyBiryukov.
Fixes#58012.
git-svn-id: https://develop.svn.wordpress.org/trunk@55703 602fd350-edb4-49c9-b593-d223f7449a82
Adds support for the new selectors property for block types. It adds it to the allowed metadata when registering a block type, makes the WP_Block_Type class aware of it, exposes it through the block types REST API, and the get_block_editor_server_block_settings function.
Corresponding work in the Gutenberg plugin: https://github.com/WordPress/gutenberg/pull/46496.
Fixes#57585.
Props aaronrobertshaw, hellofromTonya.
git-svn-id: https://develop.svn.wordpress.org/trunk@55673 602fd350-edb4-49c9-b593-d223f7449a82
Per [https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/#writing-include-require-statements WordPress PHP coding standards], it is ''strongly recommended'' to use `require[_once]` for unconditional includes. When using `include[_once]`, PHP will throw a warning when the file is not found but will continue execution, which will almost certainly lead to other errors/warnings/notices being thrown if your application depends on the file loaded, potentially leading to security leaks. For that reason, `require[_once]` is generally the better choice as it will throw a `Fatal Error` if the file cannot be found.
Follow-up to [1674], [1812], [1964], [6779], [8540], [10521], [11005], [11911], [16065], [16149], [25421], [25466], [25823], [37714], [42981], [45448], [47198], [54276], [55633].
Props kausaralm, SergeyBiryukov.
See #57839.
git-svn-id: https://develop.svn.wordpress.org/trunk@55641 602fd350-edb4-49c9-b593-d223f7449a82
Sergey Biryukov