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
[56805] introduced a regression: The `theme` attribute was no longer injected into Template Part blocks inside of patterns. This caused errors on the frontend, where instead of a given template part, an error message such as `Template part has been deleted or is unavailable: header` was seen.
This changeset rectifies that problem, and adds unit test coverage to guard against future regressions.
Follow-up to [56805].
Props scruffian, gziolo.
Fixes#59583.
git-svn-id: https://develop.svn.wordpress.org/trunk@56818 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
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
Includes:
* Adding the `templateTypes` property to the `WP_Block_Patterns_Registry::register()` DocBlock.
* Adding `@since` notes for the `postTypes` and `templateTypes` properties to:
* `_register_theme_block_patterns()`
* `WP_Block_Patterns_Registry::register()`
* Bringing some consistency to the order of properties between:
* `_register_theme_block_patterns()`
* `WP_Block_Patterns_Registry::register()`
* `WP_REST_Block_Patterns_Controller::prepare_item_for_response()`
* `WP_REST_Block_Patterns_Controller::get_item_schema()`
Follow-up to [52943], [53152], [54263], [55168].
See #56792.
git-svn-id: https://develop.svn.wordpress.org/trunk@55173 602fd350-edb4-49c9-b593-d223f7449a82
Dynamic (non-explicitly declared) properties are deprecated as of PHP 8.2 and are expected to become a fatal error in PHP 9.0.
There are a number of ways to mitigate this:
* If it is an accidental typo for a declared property: fix the typo.
* For known properties: declare them on the class.
* For unknown properties: add the magic `__get()`, `__set()`, et al. methods to the class or let the class extend `stdClass` which has highly optimized versions of these magic methods built in.
* For unknown ''use'' of dynamic properties, the `#[AllowDynamicProperties]` attribute can be added to the class. The attribute will automatically be inherited by child classes.
Trac ticket #56034 is open to investigate and handle the third and fourth type of situations, however it has become clear this will need more time and will not be ready in time for WP 6.1.
To reduce “noise” in the meantime, both in the error logs of WP users moving onto PHP 8.2, in the test run logs of WP itself, in test runs of plugins and themes, as well as to prevent duplicate tickets from being opened for the same issue, this commit adds the `#[AllowDynamicProperties]` attribute to all “parent” classes in WP.
The logic used for this commit is as follows:
* If a class already has the attribute: no action needed.
* If a class does not `extend`: add the attribute.
* If a class does `extend`:
- If it extends `stdClass`: no action needed (as `stdClass` supports dynamic properties).
- If it extends a PHP native class: add the attribute.
- If it extends a class from one of WP's external dependencies: add the attribute.
* In all other cases: no action — the attribute should not be needed as child classes inherit from the parent.
Whether or not a class contains magic methods has not been taken into account, as a review of the currently existing magic methods has shown that those are generally not sturdy enough and often even set dynamic properties (which they should not). See the [https://www.youtube.com/watch?v=vDZWepDQQVE live stream from August 16, 2022] for more details.
This commit only affects classes in the `src` directory of WordPress core.
* Tests should not get this attribute, but should be fixed to not use dynamic properties instead. Patches for this are already being committed under ticket #56033.
* While a number bundled themes (2014, 2019, 2020, 2021) contain classes, they are not a part of this commit and may be updated separately.
Reference: [https://wiki.php.net/rfc/deprecate_dynamic_properties PHP RFC: Deprecate dynamic properties].
Follow-up to [53922].
Props jrf, hellofromTonya, markjaquith, peterwilsoncc, costdev, knutsp, aristath.
See #56513, #56034.
git-svn-id: https://develop.svn.wordpress.org/trunk@54133 602fd350-edb4-49c9-b593-d223f7449a82
This fixes an `Equals sign not aligned correctly` WPCS warning.
Additionally, this commit sets the `svn:eol-style` property for the `phpunit/tests/ajax/wpAjaxCropImage.php` file and corrects line endings, so that the output of `composer format` is clean.
Follow-up to [53027], [53217], [53404].
Props hellofromTonya, SergeyBiryukov.
See #55647.
git-svn-id: https://develop.svn.wordpress.org/trunk@53441 602fd350-edb4-49c9-b593-d223f7449a82
Reverts changes from [53155] to ensure backward compatibility.
Companion to Gutenberg changes https://github.com/WordPress/gutenberg/pull/40818. That makes sure that patterns registered with `admin_init` or `current_screen` hooks are not lost.
Props jsnajdr, zieladam, peterwilsoncc, johnstonphilip.
See #55567.
git-svn-id: https://develop.svn.wordpress.org/trunk@53404 602fd350-edb4-49c9-b593-d223f7449a82
Add the optional `blockTypes` argument in the patten properties for `WP_Block_Patterns_Registry::register()`.
Props vlad.olaru.
Fixes#55303.
See #54729.
git-svn-id: https://develop.svn.wordpress.org/trunk@52943 602fd350-edb4-49c9-b593-d223f7449a82
This expands the `@param` tag for the property argument available for the `register()` method in `WP_Block_Patterns_Registry` and `WP_Block_Pattern_Cattegories_Registry`.
See #53399.
git-svn-id: https://develop.svn.wordpress.org/trunk@52219 602fd350-edb4-49c9-b593-d223f7449a82
This brings some consistency with most other calls.
Follow-up to [23378], [25605], [34745], [36219], [44108], [46111], [48156].
See #52627.
git-svn-id: https://develop.svn.wordpress.org/trunk@51154 602fd350-edb4-49c9-b593-d223f7449a82
Adjust some newly introduced strings to remove unnecessary numbered placeholders for consistency.
Follow-up to [42827].
See #51800.
git-svn-id: https://develop.svn.wordpress.org/trunk@50234 602fd350-edb4-49c9-b593-d223f7449a82
