Previously, the content for all registered patterns would get loaded on each request when the patterns are registered. Instead, this stores the path the pattern file during registration and reads the content the first time the pattern is used, which is a performance optimization.
Props thekt12, spacedmonkey, gziolo, aristath, joemcgill.
Fixes#59532.
Built from https://develop.svn.wordpress.org/trunk@57683
git-svn-id: http://core.svn.wordpress.org/trunk@57184 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This updates the '@since 6.4.0' annotation in `_register_theme_block_patterns` to reference `WP_Theme::get_block_patterns` instead of `_wp_get_block_patterns`, which was changed in [56978].
Props audrasjb, mukesh27, joemcgill.
Fixes#59869.
Built from https://develop.svn.wordpress.org/trunk@57102
git-svn-id: http://core.svn.wordpress.org/trunk@56613 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This fixes a bug during the database upgrade process where a theme's `functions.php` file may not be loaded, leading to potential exceptions if the theme's pattern files use symbols (classes, functions, constants, etc.) that are declared only when the `functions.php` file is loaded. To do so, a check for `wp_get_active_and_valid_themes()` is added early to `_register_theme_block_patterns()`, which returns early if no active or valid themes are returned.
Props fabiankaegy, rajinsharwar, pbiron, huzaifaalmesbah, hellofromTonya, peterwilsoncc, joemcgill.
Fixes#59723.
Built from https://develop.svn.wordpress.org/trunk@57021
git-svn-id: http://core.svn.wordpress.org/trunk@56532 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In [56765], theme block pattern files were cached to a transient as a performance enhancement. However, transients are not easily clearable when caches are flushed on environments not using a persistent cache, which can lead to errors if the theme files are renamed, edited, or moved.
This changes the caching mechanism to use `wp_cache_set()` instead, and caches these values to the global group so they are still persistent on environments using an object cache, and will be cleared by a cache flush.
In addition, the helper `_wp_get_block_patterns` has been moved `WP_Theme::get_block_patterns` for consistency with other block related theme methods and cache helpers for these values, `WP_Theme::get_pattern_cache` and `WP_Theme::set_pattern_cache`, have been made private.
Relevant unit tests updated.
Props: afercia, flixos90, mukesh27, joemcgill.
Fixes#59633. See #59591, #59490.
Built from https://develop.svn.wordpress.org/trunk@56978
git-svn-id: http://core.svn.wordpress.org/trunk@56489 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The `_register_theme_block_patterns` function imposed a significant resource overhead. This issue primarily stems from themes, such as TT4, that register a substantial number of block patterns. These patterns necessitate numerous file operations, including file lookups, file reading into memory, and related processes. To provide an overview, the _register_theme_block_patterns function performed the following file operations:
- is_dir
- is_readable
- file_exists
- glob
- file_get_contents (utilized via get_file_data)
To address these issues, caching using a transient has been added to a new function call `_wp_get_block_patterns`. If theme development mode is disabled and theme exists, the block patterns are saved in a transient cache. This cache is used all requests after that, saving file lookups and reading files into memory. Cache invalidation is done, when themes are switched, deleted or updated. Meaning that block patterns are not stored in the cache incorrectly.
Props flixos90, joemcgill, peterwilsoncc, costdev, swissspidy, aristath, westonruter, spacedmonkey.
Fixes#59490
Built from https://develop.svn.wordpress.org/trunk@56765
git-svn-id: http://core.svn.wordpress.org/trunk@56277 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This removes ignore annotations which are ignoring an error which would not be thrown for that code.
Includes tidying up the format of the ignore annotation:
* Customary one space between the `//` and the start of the comment.
* There should be no spaces in the comma-separated sniff list.
Follow-up to [45607], [47185], [49200], [53152].
Props jrf.
See #59161.
Built from https://develop.svn.wordpress.org/trunk@56738
git-svn-id: http://core.svn.wordpress.org/trunk@56250 1a063a9b-81f0-0310-95a4-ce76da25c4cd
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.
Built from https://develop.svn.wordpress.org/trunk@55173
git-svn-id: http://core.svn.wordpress.org/trunk@54706 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Adds `wp_theme_has_theme_json()` for public consumption, to replace the private internal Core-only `WP_Theme_JSON_Resolver::theme_has_support()` method. This new global function checks if a theme or its parent has a `theme.json` file.
For performance, results are cached as an integer `1` or `0` in the `'theme_json'` group with `'wp_theme_has_theme_json'` key. This is a non-persistent cache. Why? To make the derived data from `theme.json` is always fresh from the potential modifications done via hooks that can use dynamic data (modify the stylesheet depending on some option, settings depending on user permissions, etc.).
Also adds a new public function `wp_clean_theme_json_cache()` to clear the cache on `'switch_theme'` and `start_previewing_theme'`.
References:
* [https://github.com/WordPress/gutenberg/pull/45168 Gutenberg PR 45168] Add `wp_theme_has_theme_json` as a public API to know whether a theme has a `theme.json`.
* [https://github.com/WordPress/gutenberg/pull/45380 Gutenberg PR 45380] Deprecate `WP_Theme_JSON_Resolver:theme_has_support()`.
* [https://github.com/WordPress/gutenberg/pull/46150 Gutenberg PR 46150] Make `theme.json` object caches non-persistent.
* [https://github.com/WordPress/gutenberg/pull/45979 Gutenberg PR 45979] Don't check if constants set by `wp_initial_constants()` are defined.
* [https://github.com/WordPress/gutenberg/pull/45950 Gutenberg PR 45950] Cleaner logic in `wp_theme_has_theme_json`.
Follow-up to [54493], [53282], [52744], [52049], [50959].
Props oandregal, afragen, alexstine, aristath, azaozz, costdev, flixos90, hellofromTonya, mamaduka, mcsf, ocean90, spacedmonkey.
Fixes#56975.
Built from https://develop.svn.wordpress.org/trunk@55086
git-svn-id: http://core.svn.wordpress.org/trunk@54619 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Quoting poena from the ticket: "[...] To make it easier for users to find these
patterns, a new block pattern category should be added. The patterns have
already been built to include the new category, with the slug "footer" [to]
match the existing Headers category"
Props poena.
Fixes#56416.
Built from https://develop.svn.wordpress.org/trunk@53943
git-svn-id: http://core.svn.wordpress.org/trunk@53502 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In 6.0 there is now a functionality that allows to register selected remote patterns (from the Pattern Directory) via `theme.json`. However, it requires to fully enable all core and remote patterns. This can be a blocker for user adoption.
Many theme authors want to have all core and remote patterns disabled by default using `remove_theme_support( 'core-block-patterns' )`. This changeset ensures they are serving only patterns relevant to their theme.
This changeset removes theme support check from the function that registers remote patterns specified in `theme.json`. This allows theme authors to disable core patterns but then selectively register the ones they want from the Pattern Directory. If a theme author intentionally specifies patterns in `theme.json`, they probably intend for them to be present in the pattern inserter and the check is not required.
This change will make the Pattern Directory more appealing/usable from the theme author's perspective.
Props ndiego, ryelle.
Fixes#56112.
Built from https://develop.svn.wordpress.org/trunk@53793
git-svn-id: http://core.svn.wordpress.org/trunk@53352 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Related Gutenberg issue: https://github.com/WordPress/gutenberg/issues/39889.
Backporting changes from the Gutenberg plugin:
- new Block Patterns REST API endpoint
- new Block Pattern Categories REST API endpoint
- updates to Query Loop related patterns
- support for custom taxonomies in Query Loop block
Props hellofromtonya, peterwilsoncc, ntsekouras, zieladam, ironprogrammer, spacedmonkey, timothyblynjacobs, antonvlasenko, jsnajdr.
See #55505.
Built from https://develop.svn.wordpress.org/trunk@53152
git-svn-id: http://core.svn.wordpress.org/trunk@52741 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Remote block patterns from wp.org were to be loaded through a callback hooked into the `current_screen` filter. Within 2 callbacks, i.e. `_load_remote_featured_patterns()` and `_load_remote_block_patterns()`, a guard clause bailed out early if the `$current_screen->is_block_editor` is `false`.
However, the `current_screen` filter is unreliable to detect the block editor. Why? In the block and Site Editor screens, `$current_scren->is_block_editor` is not set until after the filter is executed. Whoopsie.
This commit no longer uses the `current_screen` filter. Instead, it explicitly loads the remote block patterns by invoking both private functions (now not callbacks) directly in the screen files for the block and site editor screens.
With this change, passing `WP_Screen` object into these functions is no longer needed. As the `_load_remote_block_patterns()` function was introduced in 5.8.0, its function parameter is now deprecated and the guard clause retained for backwards compatibility.
Follow-up to [51021], [52377].
Props poena, noisysocks, peterwilsoncc, hellofromTonya, audrasjb.
Fixes#54806.
Built from https://develop.svn.wordpress.org/trunk@52593
git-svn-id: http://core.svn.wordpress.org/trunk@52181 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Because the `__()` translation function was used here, the Query block pattern category string is not translatable. `_x()` is the correct function here as that passes the second parameter as context and not text domain.
Follow up to [50948].
Props walbo.
Fixes#53577.
Built from https://develop.svn.wordpress.org/trunk@51307
git-svn-id: http://core.svn.wordpress.org/trunk@50916 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Add an endpoint for fetching block patterns from WordPress.org, and load the block patterns from this new API. Remove the block patterns that have already been moved to WordPress.org/patterns.
Props ryelle, iandunn, youknowriad, timothyblynjacobs.
Fixes#53246.
Built from https://develop.svn.wordpress.org/trunk@51021
git-svn-id: http://core.svn.wordpress.org/trunk@50630 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This updates the block patterns included by default on WordPress
to give them more personality and to make use of the design tools
that has been added to the editor.
Props onemaggie, melchoyce, kjellr, beafialho, gziolo.
Fixes#52846.
Built from https://develop.svn.wordpress.org/trunk@50794
git-svn-id: http://core.svn.wordpress.org/trunk@50403 1a063a9b-81f0-0310-95a4-ce76da25c4cd
WordPress Core comes by default with a number of block patterns and a frequent request was to be able to opt-out of the Core block patterns.
You can now opt-out using remove_theme_support( 'core-block-patterns' )
Props desrosj, nosolosw.
Fixes#50669.
Built from https://develop.svn.wordpress.org/trunk@48492
git-svn-id: http://core.svn.wordpress.org/trunk@48254 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Joe McGill
youknowriad
Felix Arntz
spacedmonkey
Sergey Biryukov
audrasjb
isabel_brison
oandregal
jorgefilipecosta
hellofromTonya
mcsf
gziolo
desrosj
iandunn
ryelle