2021-11-08 22:45:58 +01:00
|
|
|
<?php
|
|
|
|
/**
|
|
|
|
* APIs to interact with global settings & styles.
|
|
|
|
*
|
|
|
|
* @package WordPress
|
|
|
|
*/
|
|
|
|
|
|
|
|
/**
|
2022-10-07 14:09:11 +02:00
|
|
|
* Gets the settings resulting of merging core, theme, and user data.
|
2021-11-08 22:45:58 +01:00
|
|
|
*
|
|
|
|
* @since 5.9.0
|
|
|
|
*
|
2021-11-30 01:24:27 +01:00
|
|
|
* @param array $path Path to the specific setting to retrieve. Optional.
|
|
|
|
* If empty, will return all settings.
|
|
|
|
* @param array $context {
|
|
|
|
* Metadata to know where to retrieve the $path from. Optional.
|
|
|
|
*
|
|
|
|
* @type string $block_name Which block to retrieve the settings from.
|
|
|
|
* If empty, it'll return the settings for the global context.
|
|
|
|
* @type string $origin Which origin to take data from.
|
|
|
|
* Valid values are 'all' (core, theme, and user) or 'base' (core and theme).
|
|
|
|
* If empty or unknown, 'all' is used.
|
|
|
|
* }
|
2023-05-03 20:48:22 +02:00
|
|
|
* @return mixed The settings array or individual setting value to retrieve.
|
2021-11-08 22:45:58 +01:00
|
|
|
*/
|
2021-11-30 01:24:27 +01:00
|
|
|
function wp_get_global_settings( $path = array(), $context = array() ) {
|
|
|
|
if ( ! empty( $context['block_name'] ) ) {
|
2023-01-27 23:14:12 +01:00
|
|
|
$new_path = array( 'blocks', $context['block_name'] );
|
|
|
|
foreach ( $path as $subpath ) {
|
|
|
|
$new_path[] = $subpath;
|
|
|
|
}
|
|
|
|
$path = $new_path;
|
2021-11-08 22:45:58 +01:00
|
|
|
}
|
|
|
|
|
2023-01-27 23:14:12 +01:00
|
|
|
/*
|
|
|
|
* This is the default value when no origin is provided or when it is 'all'.
|
|
|
|
*
|
|
|
|
* The $origin is used as part of the cache key. Changes here need to account
|
|
|
|
* for clearing the cache appropriately.
|
|
|
|
*/
|
2021-11-30 01:24:27 +01:00
|
|
|
$origin = 'custom';
|
2023-01-27 23:14:12 +01:00
|
|
|
if (
|
|
|
|
! wp_theme_has_theme_json() ||
|
|
|
|
( isset( $context['origin'] ) && 'base' === $context['origin'] )
|
|
|
|
) {
|
2021-11-08 22:45:58 +01:00
|
|
|
$origin = 'theme';
|
|
|
|
}
|
|
|
|
|
2023-01-27 23:14:12 +01:00
|
|
|
/*
|
|
|
|
* By using the 'theme_json' group, this data is marked to be non-persistent across requests.
|
|
|
|
* See `wp_cache_add_non_persistent_groups` in src/wp-includes/load.php and other places.
|
|
|
|
*
|
|
|
|
* The rationale for this is to make sure 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.).
|
|
|
|
* See some of the existing hooks to modify theme.json behaviour:
|
|
|
|
* https://make.wordpress.org/core/2022/10/10/filters-for-theme-json-data/
|
|
|
|
*
|
|
|
|
* A different alternative considered was to invalidate the cache upon certain
|
|
|
|
* events such as options add/update/delete, user meta, etc.
|
|
|
|
* It was judged not enough, hence this approach.
|
|
|
|
* See https://github.com/WordPress/gutenberg/pull/45372
|
|
|
|
*/
|
|
|
|
$cache_group = 'theme_json';
|
|
|
|
$cache_key = 'wp_get_global_settings_' . $origin;
|
|
|
|
|
|
|
|
/*
|
General: Introduce `WP_DEVELOPMENT_MODE` constant to signify context-specific development mode.
In recent releases, WordPress core added several instances of cache usage around specific files. While those caches are safe to use in a production context, in development certain nuances apply for whether or not those caches make sense to use. Initially, `WP_DEBUG` was used as a temporary workaround, but it was clear that a more granular method to signify a specific development mode was required: For example, caches around `theme.json` should be disabled when working on a theme as otherwise it would disrupt the theme developer's workflow, but when working on a plugin or WordPress core, this consideration does not apply.
This changeset introduces a `WP_DEVELOPMENT_MODE` constant which, for now, can be set to either "core", "plugin", "theme", or an empty string, the latter of which means no development mode, which is also the default. A new function `wp_get_development_mode()` is the recommended way to retrieve that configuration value.
With the new function available, this changeset replaces all existing instances of the aforementioned `WP_DEBUG` workaround to use `wp_get_development_mode()` with a more specific check.
Props azaozz, sergeybiryukov, peterwilsoncc, spacedmonkey.
Fixes #57487.
Built from https://develop.svn.wordpress.org/trunk@56042
git-svn-id: http://core.svn.wordpress.org/trunk@55554 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2023-06-26 21:57:25 +02:00
|
|
|
* Ignore cache when the development mode is set to 'theme', so it doesn't interfere with the theme
|
2023-01-27 23:14:12 +01:00
|
|
|
* developer's workflow.
|
|
|
|
*/
|
General: Introduce `WP_DEVELOPMENT_MODE` constant to signify context-specific development mode.
In recent releases, WordPress core added several instances of cache usage around specific files. While those caches are safe to use in a production context, in development certain nuances apply for whether or not those caches make sense to use. Initially, `WP_DEBUG` was used as a temporary workaround, but it was clear that a more granular method to signify a specific development mode was required: For example, caches around `theme.json` should be disabled when working on a theme as otherwise it would disrupt the theme developer's workflow, but when working on a plugin or WordPress core, this consideration does not apply.
This changeset introduces a `WP_DEVELOPMENT_MODE` constant which, for now, can be set to either "core", "plugin", "theme", or an empty string, the latter of which means no development mode, which is also the default. A new function `wp_get_development_mode()` is the recommended way to retrieve that configuration value.
With the new function available, this changeset replaces all existing instances of the aforementioned `WP_DEBUG` workaround to use `wp_get_development_mode()` with a more specific check.
Props azaozz, sergeybiryukov, peterwilsoncc, spacedmonkey.
Fixes #57487.
Built from https://develop.svn.wordpress.org/trunk@56042
git-svn-id: http://core.svn.wordpress.org/trunk@55554 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2023-06-26 21:57:25 +02:00
|
|
|
$can_use_cached = wp_get_development_mode() !== 'theme';
|
2023-01-27 23:14:12 +01:00
|
|
|
|
|
|
|
$settings = false;
|
|
|
|
if ( $can_use_cached ) {
|
|
|
|
$settings = wp_cache_get( $cache_key, $cache_group );
|
|
|
|
}
|
|
|
|
|
|
|
|
if ( false === $settings ) {
|
|
|
|
$settings = WP_Theme_JSON_Resolver::get_merged_data( $origin )->get_settings();
|
|
|
|
if ( $can_use_cached ) {
|
|
|
|
wp_cache_set( $cache_key, $settings, $cache_group );
|
|
|
|
}
|
|
|
|
}
|
2021-11-08 22:45:58 +01:00
|
|
|
|
|
|
|
return _wp_array_get( $settings, $path, $settings );
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2022-10-07 14:09:11 +02:00
|
|
|
* Gets the styles resulting of merging core, theme, and user data.
|
2021-11-08 22:45:58 +01:00
|
|
|
*
|
|
|
|
* @since 5.9.0
|
2023-06-22 10:44:26 +02:00
|
|
|
* @since 6.3.0 the internal link format "var:preset|color|secondary" is resolved
|
|
|
|
* to "var(--wp--preset--font-size--small)" so consumers don't have to.
|
|
|
|
* @since 6.3.0 `transforms` is now usable in the `context` parameter. In case [`transforms`]['resolve_variables']
|
|
|
|
* is defined, variables are resolved to their value in the styles.
|
2021-11-08 22:45:58 +01:00
|
|
|
*
|
2021-11-30 01:24:27 +01:00
|
|
|
* @param array $path Path to the specific style to retrieve. Optional.
|
|
|
|
* If empty, will return all styles.
|
|
|
|
* @param array $context {
|
|
|
|
* Metadata to know where to retrieve the $path from. Optional.
|
|
|
|
*
|
|
|
|
* @type string $block_name Which block to retrieve the styles from.
|
|
|
|
* If empty, it'll return the styles for the global context.
|
|
|
|
* @type string $origin Which origin to take data from.
|
|
|
|
* Valid values are 'all' (core, theme, and user) or 'base' (core and theme).
|
|
|
|
* If empty or unknown, 'all' is used.
|
2023-06-22 10:44:26 +02:00
|
|
|
* @type array $transforms Which transformation(s) to apply.
|
|
|
|
* Valid value is array( 'resolve-variables' ).
|
|
|
|
* If defined, variables are resolved to their value in the styles.
|
2021-11-30 01:24:27 +01:00
|
|
|
* }
|
2023-05-03 20:48:22 +02:00
|
|
|
* @return mixed The styles array or individual style value to retrieve.
|
2021-11-08 22:45:58 +01:00
|
|
|
*/
|
2021-11-30 01:24:27 +01:00
|
|
|
function wp_get_global_styles( $path = array(), $context = array() ) {
|
|
|
|
if ( ! empty( $context['block_name'] ) ) {
|
|
|
|
$path = array_merge( array( 'blocks', $context['block_name'] ), $path );
|
2021-11-08 22:45:58 +01:00
|
|
|
}
|
|
|
|
|
2021-11-30 01:24:27 +01:00
|
|
|
$origin = 'custom';
|
|
|
|
if ( isset( $context['origin'] ) && 'base' === $context['origin'] ) {
|
2021-11-08 22:45:58 +01:00
|
|
|
$origin = 'theme';
|
|
|
|
}
|
|
|
|
|
2023-06-22 10:44:26 +02:00
|
|
|
$resolve_variables = isset( $context['transforms'] )
|
|
|
|
&& is_array( $context['transforms'] )
|
|
|
|
&& in_array( 'resolve-variables', $context['transforms'], true );
|
|
|
|
|
|
|
|
$merged_data = WP_Theme_JSON_Resolver::get_merged_data( $origin );
|
|
|
|
if ( $resolve_variables ) {
|
|
|
|
$merged_data = WP_Theme_JSON::resolve_variables( $merged_data );
|
|
|
|
}
|
|
|
|
$styles = $merged_data->get_raw_data()['styles'];
|
2021-11-08 22:45:58 +01:00
|
|
|
return _wp_array_get( $styles, $path, $styles );
|
|
|
|
}
|
|
|
|
|
2023-06-22 10:44:26 +02:00
|
|
|
|
2021-11-08 22:45:58 +01:00
|
|
|
/**
|
|
|
|
* Returns the stylesheet resulting of merging core, theme, and user data.
|
|
|
|
*
|
|
|
|
* @since 5.9.0
|
2023-01-26 18:23:15 +01:00
|
|
|
* @since 6.1.0 Added 'base-layout-styles' support.
|
2021-11-08 22:45:58 +01:00
|
|
|
*
|
2023-01-26 18:23:15 +01:00
|
|
|
* @param array $types Optional. Types of styles to load.
|
|
|
|
* It accepts as values 'variables', 'presets', 'styles', 'base-layout-styles'.
|
|
|
|
* If empty, it'll load the following:
|
|
|
|
* - for themes without theme.json: 'variables', 'presets', 'base-layout-styles'.
|
|
|
|
* - for themes with theme.json: 'variables', 'presets', 'styles'.
|
2021-11-08 22:45:58 +01:00
|
|
|
* @return string Stylesheet.
|
|
|
|
*/
|
|
|
|
function wp_get_global_stylesheet( $types = array() ) {
|
2023-01-27 00:03:14 +01:00
|
|
|
/*
|
General: Introduce `WP_DEVELOPMENT_MODE` constant to signify context-specific development mode.
In recent releases, WordPress core added several instances of cache usage around specific files. While those caches are safe to use in a production context, in development certain nuances apply for whether or not those caches make sense to use. Initially, `WP_DEBUG` was used as a temporary workaround, but it was clear that a more granular method to signify a specific development mode was required: For example, caches around `theme.json` should be disabled when working on a theme as otherwise it would disrupt the theme developer's workflow, but when working on a plugin or WordPress core, this consideration does not apply.
This changeset introduces a `WP_DEVELOPMENT_MODE` constant which, for now, can be set to either "core", "plugin", "theme", or an empty string, the latter of which means no development mode, which is also the default. A new function `wp_get_development_mode()` is the recommended way to retrieve that configuration value.
With the new function available, this changeset replaces all existing instances of the aforementioned `WP_DEBUG` workaround to use `wp_get_development_mode()` with a more specific check.
Props azaozz, sergeybiryukov, peterwilsoncc, spacedmonkey.
Fixes #57487.
Built from https://develop.svn.wordpress.org/trunk@56042
git-svn-id: http://core.svn.wordpress.org/trunk@55554 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2023-06-26 21:57:25 +02:00
|
|
|
* Ignore cache when the development mode is set to 'theme', so it doesn't interfere with the theme
|
2023-01-27 00:03:14 +01:00
|
|
|
* developer's workflow.
|
|
|
|
*/
|
General: Introduce `WP_DEVELOPMENT_MODE` constant to signify context-specific development mode.
In recent releases, WordPress core added several instances of cache usage around specific files. While those caches are safe to use in a production context, in development certain nuances apply for whether or not those caches make sense to use. Initially, `WP_DEBUG` was used as a temporary workaround, but it was clear that a more granular method to signify a specific development mode was required: For example, caches around `theme.json` should be disabled when working on a theme as otherwise it would disrupt the theme developer's workflow, but when working on a plugin or WordPress core, this consideration does not apply.
This changeset introduces a `WP_DEVELOPMENT_MODE` constant which, for now, can be set to either "core", "plugin", "theme", or an empty string, the latter of which means no development mode, which is also the default. A new function `wp_get_development_mode()` is the recommended way to retrieve that configuration value.
With the new function available, this changeset replaces all existing instances of the aforementioned `WP_DEBUG` workaround to use `wp_get_development_mode()` with a more specific check.
Props azaozz, sergeybiryukov, peterwilsoncc, spacedmonkey.
Fixes #57487.
Built from https://develop.svn.wordpress.org/trunk@56042
git-svn-id: http://core.svn.wordpress.org/trunk@55554 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2023-06-26 21:57:25 +02:00
|
|
|
$can_use_cached = empty( $types ) && wp_get_development_mode() !== 'theme';
|
2023-01-27 00:03:14 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* By using the 'theme_json' group, this data is marked to be non-persistent across requests.
|
|
|
|
* @see `wp_cache_add_non_persistent_groups()`.
|
|
|
|
*
|
|
|
|
* The rationale for this is to make sure 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.).
|
|
|
|
* See some of the existing hooks to modify theme.json behavior:
|
|
|
|
* @see https://make.wordpress.org/core/2022/10/10/filters-for-theme-json-data/
|
|
|
|
*
|
|
|
|
* A different alternative considered was to invalidate the cache upon certain
|
|
|
|
* events such as options add/update/delete, user meta, etc.
|
|
|
|
* It was judged not enough, hence this approach.
|
|
|
|
* @see https://github.com/WordPress/gutenberg/pull/45372
|
|
|
|
*/
|
|
|
|
$cache_group = 'theme_json';
|
|
|
|
$cache_key = 'wp_get_global_stylesheet';
|
2021-11-08 22:45:58 +01:00
|
|
|
if ( $can_use_cached ) {
|
2023-01-27 00:03:14 +01:00
|
|
|
$cached = wp_cache_get( $cache_key, $cache_group );
|
2021-11-08 22:45:58 +01:00
|
|
|
if ( $cached ) {
|
|
|
|
return $cached;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-02-04 14:52:00 +01:00
|
|
|
$tree = WP_Theme_JSON_Resolver::get_merged_data();
|
|
|
|
|
Themes: Introduce wp_theme_has_theme_json() for public consumption.
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
2023-01-18 12:40:10 +01:00
|
|
|
$supports_theme_json = wp_theme_has_theme_json();
|
2021-11-08 22:45:58 +01:00
|
|
|
if ( empty( $types ) && ! $supports_theme_json ) {
|
Editor: Backport foundation for Layout block support refactor (part 1).
Backports the following changes from the Gutenberg repository:
* [WordPress/gutenberg/40875 gutenberg/40875] Layout: Use semantic classnames, centralize layout definitions, reduce duplication, and fix blockGap in theme.json
* [WordPress/gutenberg/42544 gutenberg/42544] Layout: Add a disable-layout-styles theme supports flag to opt out of all layout styles gutenberg/42544
* [WordPress/gutenberg/42087 gutenberg/42087] Theme.json: Add block support feature level selectors for blocks gutenberg/42087
* [WordPress/gutenberg/43792 gutenberg/43792] Global Styles: Split root layout rules into a different function gutenberg/43792
* [WordPress/gutenberg/42544 gutenberg/42544] Layout: Add a disable-layout-styles theme supports flag to opt out of all layout styles gutenberg/42544
* [WordPress/gutenberg/42665 gutenberg/42665] Layout: Reduce specificity of fallback blockGap styles gutenberg/42665
* [WordPress/gutenberg/42085 gutenberg/42085] Core CSS support for root padding and alignfull blocks gutenberg/42085
Notes:
* It doesn't entirely port over PR 40875 — the remaining PHP changes for that PR will be explored in a separate PR targeting `layout.php`.
* [54159] was reverted in [54160] due to PHPUnit test failures for tests added by the commit. Later, tests passed when applied on top of `trunk`. There were various outages today of upstream `wp-env` dependencies, which likely were the root cause of the earlier failures. For historical tracking and to make sure, recommitting [54159] but instead on top of current `trunk`. See PR 3205 for more details.
* Giving additional props for those who did a deep dive investigation into the failed tests.
Follow-up to [54160], [54159].
Props andrewserong, aaronrobertshaw, isabel_brison, bernhard-reiter, hellofromTonya.
See #56467.
Built from https://develop.svn.wordpress.org/trunk@54162
git-svn-id: http://core.svn.wordpress.org/trunk@53721 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2022-09-14 20:44:09 +02:00
|
|
|
$types = array( 'variables', 'presets', 'base-layout-styles' );
|
2021-11-08 22:45:58 +01:00
|
|
|
} elseif ( empty( $types ) ) {
|
|
|
|
$types = array( 'variables', 'styles', 'presets' );
|
|
|
|
}
|
|
|
|
|
2022-02-04 15:18:59 +01:00
|
|
|
/*
|
Editor: Add missing `blocks` origin to `theme.json`.
This changeset updates the blocks origin name from core to blocks and adds it to the list of valid origins for `theme.json`.
(See the original fix in [https://github.com//pull/3319 Gutenberg's PR 44363]).
Why?
- This new origin was missing from the list.
- The `core` name is not reflective of what it does, as this data origin is related to block styles, whether they come with WordPress or third-party blocks.
- The existing filter for this piece of data is called `theme_json_blocks`, to reflect it filters "block" data.
- Though `core` origin was used in the past for `default`, this commit reverts it. Why? It was confusing. The goal is to use names that communicate what part of the pipeline are processing (`default > blocks > theme > custom`).
How?
- Renames the string, from `core` to `blocks`.
- Adds `blocks` to the list of valid origins.
- Verifies that the `$theme_json->get_stylesheet()` call uses the proper `$origins` at all times.
Follow-up to [54162], [54251].
Props oandregal, czapla, jorgefilipecosta, scruffian, bernhard-reiter hellofromTonya.
See #56467.
Built from https://develop.svn.wordpress.org/trunk@54408
git-svn-id: http://core.svn.wordpress.org/trunk@53967 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2022-10-07 11:40:13 +02:00
|
|
|
* If variables are part of the stylesheet, then add them.
|
2022-02-04 15:18:59 +01:00
|
|
|
* This is so themes without a theme.json still work as before 5.9:
|
|
|
|
* they can override the default presets.
|
|
|
|
* See https://core.trac.wordpress.org/ticket/54782
|
|
|
|
*/
|
2022-02-04 14:52:00 +01:00
|
|
|
$styles_variables = '';
|
2022-02-04 15:18:59 +01:00
|
|
|
if ( in_array( 'variables', $types, true ) ) {
|
Editor: Add missing `blocks` origin to `theme.json`.
This changeset updates the blocks origin name from core to blocks and adds it to the list of valid origins for `theme.json`.
(See the original fix in [https://github.com//pull/3319 Gutenberg's PR 44363]).
Why?
- This new origin was missing from the list.
- The `core` name is not reflective of what it does, as this data origin is related to block styles, whether they come with WordPress or third-party blocks.
- The existing filter for this piece of data is called `theme_json_blocks`, to reflect it filters "block" data.
- Though `core` origin was used in the past for `default`, this commit reverts it. Why? It was confusing. The goal is to use names that communicate what part of the pipeline are processing (`default > blocks > theme > custom`).
How?
- Renames the string, from `core` to `blocks`.
- Adds `blocks` to the list of valid origins.
- Verifies that the `$theme_json->get_stylesheet()` call uses the proper `$origins` at all times.
Follow-up to [54162], [54251].
Props oandregal, czapla, jorgefilipecosta, scruffian, bernhard-reiter hellofromTonya.
See #56467.
Built from https://develop.svn.wordpress.org/trunk@54408
git-svn-id: http://core.svn.wordpress.org/trunk@53967 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2022-10-07 11:40:13 +02:00
|
|
|
/*
|
|
|
|
* Only use the default, theme, and custom origins. Why?
|
|
|
|
* Because styles for `blocks` origin are added at a later phase
|
|
|
|
* (i.e. in the render cycle). Here, only the ones in use are rendered.
|
|
|
|
* @see wp_add_global_styles_for_blocks
|
|
|
|
*/
|
|
|
|
$origins = array( 'default', 'theme', 'custom' );
|
|
|
|
$styles_variables = $tree->get_stylesheet( array( 'variables' ), $origins );
|
2022-02-04 14:52:00 +01:00
|
|
|
$types = array_diff( $types, array( 'variables' ) );
|
|
|
|
}
|
|
|
|
|
2022-02-04 15:18:59 +01:00
|
|
|
/*
|
|
|
|
* For the remaining types (presets, styles), we do consider origins:
|
|
|
|
*
|
|
|
|
* - themes without theme.json: only the classes for the presets defined by core
|
|
|
|
* - themes with theme.json: the presets and styles classes, both from core and the theme
|
|
|
|
*/
|
2022-02-04 14:52:00 +01:00
|
|
|
$styles_rest = '';
|
|
|
|
if ( ! empty( $types ) ) {
|
Editor: Add missing `blocks` origin to `theme.json`.
This changeset updates the blocks origin name from core to blocks and adds it to the list of valid origins for `theme.json`.
(See the original fix in [https://github.com//pull/3319 Gutenberg's PR 44363]).
Why?
- This new origin was missing from the list.
- The `core` name is not reflective of what it does, as this data origin is related to block styles, whether they come with WordPress or third-party blocks.
- The existing filter for this piece of data is called `theme_json_blocks`, to reflect it filters "block" data.
- Though `core` origin was used in the past for `default`, this commit reverts it. Why? It was confusing. The goal is to use names that communicate what part of the pipeline are processing (`default > blocks > theme > custom`).
How?
- Renames the string, from `core` to `blocks`.
- Adds `blocks` to the list of valid origins.
- Verifies that the `$theme_json->get_stylesheet()` call uses the proper `$origins` at all times.
Follow-up to [54162], [54251].
Props oandregal, czapla, jorgefilipecosta, scruffian, bernhard-reiter hellofromTonya.
See #56467.
Built from https://develop.svn.wordpress.org/trunk@54408
git-svn-id: http://core.svn.wordpress.org/trunk@53967 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2022-10-07 11:40:13 +02:00
|
|
|
/*
|
|
|
|
* Only use the default, theme, and custom origins. Why?
|
|
|
|
* Because styles for `blocks` origin are added at a later phase
|
|
|
|
* (i.e. in the render cycle). Here, only the ones in use are rendered.
|
|
|
|
* @see wp_add_global_styles_for_blocks
|
|
|
|
*/
|
2022-02-04 14:52:00 +01:00
|
|
|
$origins = array( 'default', 'theme', 'custom' );
|
|
|
|
if ( ! $supports_theme_json ) {
|
|
|
|
$origins = array( 'default' );
|
|
|
|
}
|
|
|
|
$styles_rest = $tree->get_stylesheet( $types, $origins );
|
2021-11-08 22:45:58 +01:00
|
|
|
}
|
|
|
|
|
2022-02-04 14:52:00 +01:00
|
|
|
$stylesheet = $styles_variables . $styles_rest;
|
2021-11-08 22:45:58 +01:00
|
|
|
if ( $can_use_cached ) {
|
2023-01-27 00:03:14 +01:00
|
|
|
wp_cache_set( $cache_key, $stylesheet, $cache_group );
|
2021-11-08 22:45:58 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
return $stylesheet;
|
|
|
|
}
|
2022-02-17 17:18:03 +01:00
|
|
|
|
Editor: Add support for custom CSS in global styles.
This changeset introduces functions `wp_get_global_styles_custom_css()` and `wp_enqueue_global_styles_custom_css()`, which allow accessing and enqueuing custom CSS added via global styles.
Custom CSS via global styles is handled separately from custom CSS via the Customizer. If a site uses both features, the custom CSS from both sources will be loaded. The global styles custom CSS is then loaded after the Customizer custom CSS, so if there are any conflicts between the rules, the global styles take precedence.
Similarly to e.g. [55185], the result is cached in a non-persistent cache, except when `WP_DEBUG` is on to avoid interrupting the theme developer's workflow.
Props glendaviesnz, oandregal, ntsekouras, mamaduka, davidbaumwald, hellofromtonya, flixos90.
Fixes #57536.
Built from https://develop.svn.wordpress.org/trunk@55192
git-svn-id: http://core.svn.wordpress.org/trunk@54725 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2023-02-02 19:52:17 +01:00
|
|
|
/**
|
2023-05-03 20:48:22 +02:00
|
|
|
* Gets the global styles custom CSS from theme.json.
|
Editor: Add support for custom CSS in global styles.
This changeset introduces functions `wp_get_global_styles_custom_css()` and `wp_enqueue_global_styles_custom_css()`, which allow accessing and enqueuing custom CSS added via global styles.
Custom CSS via global styles is handled separately from custom CSS via the Customizer. If a site uses both features, the custom CSS from both sources will be loaded. The global styles custom CSS is then loaded after the Customizer custom CSS, so if there are any conflicts between the rules, the global styles take precedence.
Similarly to e.g. [55185], the result is cached in a non-persistent cache, except when `WP_DEBUG` is on to avoid interrupting the theme developer's workflow.
Props glendaviesnz, oandregal, ntsekouras, mamaduka, davidbaumwald, hellofromtonya, flixos90.
Fixes #57536.
Built from https://develop.svn.wordpress.org/trunk@55192
git-svn-id: http://core.svn.wordpress.org/trunk@54725 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2023-02-02 19:52:17 +01:00
|
|
|
*
|
|
|
|
* @since 6.2.0
|
|
|
|
*
|
2023-05-03 20:48:22 +02:00
|
|
|
* @return string The global styles custom CSS.
|
Editor: Add support for custom CSS in global styles.
This changeset introduces functions `wp_get_global_styles_custom_css()` and `wp_enqueue_global_styles_custom_css()`, which allow accessing and enqueuing custom CSS added via global styles.
Custom CSS via global styles is handled separately from custom CSS via the Customizer. If a site uses both features, the custom CSS from both sources will be loaded. The global styles custom CSS is then loaded after the Customizer custom CSS, so if there are any conflicts between the rules, the global styles take precedence.
Similarly to e.g. [55185], the result is cached in a non-persistent cache, except when `WP_DEBUG` is on to avoid interrupting the theme developer's workflow.
Props glendaviesnz, oandregal, ntsekouras, mamaduka, davidbaumwald, hellofromtonya, flixos90.
Fixes #57536.
Built from https://develop.svn.wordpress.org/trunk@55192
git-svn-id: http://core.svn.wordpress.org/trunk@54725 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2023-02-02 19:52:17 +01:00
|
|
|
*/
|
|
|
|
function wp_get_global_styles_custom_css() {
|
|
|
|
if ( ! wp_theme_has_theme_json() ) {
|
|
|
|
return '';
|
|
|
|
}
|
|
|
|
/*
|
General: Introduce `WP_DEVELOPMENT_MODE` constant to signify context-specific development mode.
In recent releases, WordPress core added several instances of cache usage around specific files. While those caches are safe to use in a production context, in development certain nuances apply for whether or not those caches make sense to use. Initially, `WP_DEBUG` was used as a temporary workaround, but it was clear that a more granular method to signify a specific development mode was required: For example, caches around `theme.json` should be disabled when working on a theme as otherwise it would disrupt the theme developer's workflow, but when working on a plugin or WordPress core, this consideration does not apply.
This changeset introduces a `WP_DEVELOPMENT_MODE` constant which, for now, can be set to either "core", "plugin", "theme", or an empty string, the latter of which means no development mode, which is also the default. A new function `wp_get_development_mode()` is the recommended way to retrieve that configuration value.
With the new function available, this changeset replaces all existing instances of the aforementioned `WP_DEBUG` workaround to use `wp_get_development_mode()` with a more specific check.
Props azaozz, sergeybiryukov, peterwilsoncc, spacedmonkey.
Fixes #57487.
Built from https://develop.svn.wordpress.org/trunk@56042
git-svn-id: http://core.svn.wordpress.org/trunk@55554 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2023-06-26 21:57:25 +02:00
|
|
|
* Ignore cache when the development mode is set to 'theme', so it doesn't interfere with the theme
|
Editor: Add support for custom CSS in global styles.
This changeset introduces functions `wp_get_global_styles_custom_css()` and `wp_enqueue_global_styles_custom_css()`, which allow accessing and enqueuing custom CSS added via global styles.
Custom CSS via global styles is handled separately from custom CSS via the Customizer. If a site uses both features, the custom CSS from both sources will be loaded. The global styles custom CSS is then loaded after the Customizer custom CSS, so if there are any conflicts between the rules, the global styles take precedence.
Similarly to e.g. [55185], the result is cached in a non-persistent cache, except when `WP_DEBUG` is on to avoid interrupting the theme developer's workflow.
Props glendaviesnz, oandregal, ntsekouras, mamaduka, davidbaumwald, hellofromtonya, flixos90.
Fixes #57536.
Built from https://develop.svn.wordpress.org/trunk@55192
git-svn-id: http://core.svn.wordpress.org/trunk@54725 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2023-02-02 19:52:17 +01:00
|
|
|
* developer's workflow.
|
|
|
|
*/
|
General: Introduce `WP_DEVELOPMENT_MODE` constant to signify context-specific development mode.
In recent releases, WordPress core added several instances of cache usage around specific files. While those caches are safe to use in a production context, in development certain nuances apply for whether or not those caches make sense to use. Initially, `WP_DEBUG` was used as a temporary workaround, but it was clear that a more granular method to signify a specific development mode was required: For example, caches around `theme.json` should be disabled when working on a theme as otherwise it would disrupt the theme developer's workflow, but when working on a plugin or WordPress core, this consideration does not apply.
This changeset introduces a `WP_DEVELOPMENT_MODE` constant which, for now, can be set to either "core", "plugin", "theme", or an empty string, the latter of which means no development mode, which is also the default. A new function `wp_get_development_mode()` is the recommended way to retrieve that configuration value.
With the new function available, this changeset replaces all existing instances of the aforementioned `WP_DEBUG` workaround to use `wp_get_development_mode()` with a more specific check.
Props azaozz, sergeybiryukov, peterwilsoncc, spacedmonkey.
Fixes #57487.
Built from https://develop.svn.wordpress.org/trunk@56042
git-svn-id: http://core.svn.wordpress.org/trunk@55554 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2023-06-26 21:57:25 +02:00
|
|
|
$can_use_cached = wp_get_development_mode() !== 'theme';
|
Editor: Add support for custom CSS in global styles.
This changeset introduces functions `wp_get_global_styles_custom_css()` and `wp_enqueue_global_styles_custom_css()`, which allow accessing and enqueuing custom CSS added via global styles.
Custom CSS via global styles is handled separately from custom CSS via the Customizer. If a site uses both features, the custom CSS from both sources will be loaded. The global styles custom CSS is then loaded after the Customizer custom CSS, so if there are any conflicts between the rules, the global styles take precedence.
Similarly to e.g. [55185], the result is cached in a non-persistent cache, except when `WP_DEBUG` is on to avoid interrupting the theme developer's workflow.
Props glendaviesnz, oandregal, ntsekouras, mamaduka, davidbaumwald, hellofromtonya, flixos90.
Fixes #57536.
Built from https://develop.svn.wordpress.org/trunk@55192
git-svn-id: http://core.svn.wordpress.org/trunk@54725 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2023-02-02 19:52:17 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* By using the 'theme_json' group, this data is marked to be non-persistent across requests.
|
|
|
|
* @see `wp_cache_add_non_persistent_groups()`.
|
|
|
|
*
|
|
|
|
* The rationale for this is to make sure 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.).
|
|
|
|
* See some of the existing hooks to modify theme.json behavior:
|
|
|
|
* @see https://make.wordpress.org/core/2022/10/10/filters-for-theme-json-data/
|
|
|
|
*
|
|
|
|
* A different alternative considered was to invalidate the cache upon certain
|
|
|
|
* events such as options add/update/delete, user meta, etc.
|
|
|
|
* It was judged not enough, hence this approach.
|
|
|
|
* @see https://github.com/WordPress/gutenberg/pull/45372
|
|
|
|
*/
|
|
|
|
$cache_key = 'wp_get_global_styles_custom_css';
|
|
|
|
$cache_group = 'theme_json';
|
|
|
|
if ( $can_use_cached ) {
|
|
|
|
$cached = wp_cache_get( $cache_key, $cache_group );
|
|
|
|
if ( $cached ) {
|
|
|
|
return $cached;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
$tree = WP_Theme_JSON_Resolver::get_merged_data();
|
|
|
|
$stylesheet = $tree->get_custom_css();
|
|
|
|
|
|
|
|
if ( $can_use_cached ) {
|
|
|
|
wp_cache_set( $cache_key, $stylesheet, $cache_group );
|
|
|
|
}
|
|
|
|
|
|
|
|
return $stylesheet;
|
|
|
|
}
|
|
|
|
|
2022-02-17 17:18:03 +01:00
|
|
|
/**
|
|
|
|
* Returns a string containing the SVGs to be referenced as filters (duotone).
|
|
|
|
*
|
|
|
|
* @since 5.9.1
|
|
|
|
*
|
|
|
|
* @return string
|
|
|
|
*/
|
|
|
|
function wp_get_global_styles_svg_filters() {
|
2023-02-01 23:59:13 +01:00
|
|
|
/*
|
General: Introduce `WP_DEVELOPMENT_MODE` constant to signify context-specific development mode.
In recent releases, WordPress core added several instances of cache usage around specific files. While those caches are safe to use in a production context, in development certain nuances apply for whether or not those caches make sense to use. Initially, `WP_DEBUG` was used as a temporary workaround, but it was clear that a more granular method to signify a specific development mode was required: For example, caches around `theme.json` should be disabled when working on a theme as otherwise it would disrupt the theme developer's workflow, but when working on a plugin or WordPress core, this consideration does not apply.
This changeset introduces a `WP_DEVELOPMENT_MODE` constant which, for now, can be set to either "core", "plugin", "theme", or an empty string, the latter of which means no development mode, which is also the default. A new function `wp_get_development_mode()` is the recommended way to retrieve that configuration value.
With the new function available, this changeset replaces all existing instances of the aforementioned `WP_DEBUG` workaround to use `wp_get_development_mode()` with a more specific check.
Props azaozz, sergeybiryukov, peterwilsoncc, spacedmonkey.
Fixes #57487.
Built from https://develop.svn.wordpress.org/trunk@56042
git-svn-id: http://core.svn.wordpress.org/trunk@55554 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2023-06-26 21:57:25 +02:00
|
|
|
* Ignore cache when the development mode is set to 'theme', so it doesn't interfere with the theme
|
2023-02-01 23:59:13 +01:00
|
|
|
* developer's workflow.
|
|
|
|
*/
|
General: Introduce `WP_DEVELOPMENT_MODE` constant to signify context-specific development mode.
In recent releases, WordPress core added several instances of cache usage around specific files. While those caches are safe to use in a production context, in development certain nuances apply for whether or not those caches make sense to use. Initially, `WP_DEBUG` was used as a temporary workaround, but it was clear that a more granular method to signify a specific development mode was required: For example, caches around `theme.json` should be disabled when working on a theme as otherwise it would disrupt the theme developer's workflow, but when working on a plugin or WordPress core, this consideration does not apply.
This changeset introduces a `WP_DEVELOPMENT_MODE` constant which, for now, can be set to either "core", "plugin", "theme", or an empty string, the latter of which means no development mode, which is also the default. A new function `wp_get_development_mode()` is the recommended way to retrieve that configuration value.
With the new function available, this changeset replaces all existing instances of the aforementioned `WP_DEBUG` workaround to use `wp_get_development_mode()` with a more specific check.
Props azaozz, sergeybiryukov, peterwilsoncc, spacedmonkey.
Fixes #57487.
Built from https://develop.svn.wordpress.org/trunk@56042
git-svn-id: http://core.svn.wordpress.org/trunk@55554 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2023-06-26 21:57:25 +02:00
|
|
|
$can_use_cached = wp_get_development_mode() !== 'theme';
|
2023-02-01 23:59:13 +01:00
|
|
|
$cache_group = 'theme_json';
|
|
|
|
$cache_key = 'wp_get_global_styles_svg_filters';
|
2022-02-17 17:18:03 +01:00
|
|
|
if ( $can_use_cached ) {
|
2023-02-01 23:59:13 +01:00
|
|
|
$cached = wp_cache_get( $cache_key, $cache_group );
|
2022-02-17 17:18:03 +01:00
|
|
|
if ( $cached ) {
|
|
|
|
return $cached;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Themes: Introduce wp_theme_has_theme_json() for public consumption.
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
2023-01-18 12:40:10 +01:00
|
|
|
$supports_theme_json = wp_theme_has_theme_json();
|
2022-02-17 17:18:03 +01:00
|
|
|
|
|
|
|
$origins = array( 'default', 'theme', 'custom' );
|
|
|
|
if ( ! $supports_theme_json ) {
|
|
|
|
$origins = array( 'default' );
|
|
|
|
}
|
|
|
|
|
|
|
|
$tree = WP_Theme_JSON_Resolver::get_merged_data();
|
|
|
|
$svgs = $tree->get_svg_filters( $origins );
|
|
|
|
|
|
|
|
if ( $can_use_cached ) {
|
2023-02-01 23:59:13 +01:00
|
|
|
wp_cache_set( $cache_key, $svgs, $cache_group );
|
2022-02-17 17:18:03 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
return $svgs;
|
|
|
|
}
|
2022-09-10 14:38:12 +02:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Adds global style rules to the inline style for each block.
|
|
|
|
*
|
|
|
|
* @since 6.1.0
|
|
|
|
*/
|
|
|
|
function wp_add_global_styles_for_blocks() {
|
|
|
|
$tree = WP_Theme_JSON_Resolver::get_merged_data();
|
|
|
|
$block_nodes = $tree->get_styles_block_nodes();
|
|
|
|
foreach ( $block_nodes as $metadata ) {
|
|
|
|
$block_css = $tree->get_styles_for_block( $metadata );
|
|
|
|
|
Editor: Add missing `blocks` origin to `theme.json`.
This changeset updates the blocks origin name from core to blocks and adds it to the list of valid origins for `theme.json`.
(See the original fix in [https://github.com//pull/3319 Gutenberg's PR 44363]).
Why?
- This new origin was missing from the list.
- The `core` name is not reflective of what it does, as this data origin is related to block styles, whether they come with WordPress or third-party blocks.
- The existing filter for this piece of data is called `theme_json_blocks`, to reflect it filters "block" data.
- Though `core` origin was used in the past for `default`, this commit reverts it. Why? It was confusing. The goal is to use names that communicate what part of the pipeline are processing (`default > blocks > theme > custom`).
How?
- Renames the string, from `core` to `blocks`.
- Adds `blocks` to the list of valid origins.
- Verifies that the `$theme_json->get_stylesheet()` call uses the proper `$origins` at all times.
Follow-up to [54162], [54251].
Props oandregal, czapla, jorgefilipecosta, scruffian, bernhard-reiter hellofromTonya.
See #56467.
Built from https://develop.svn.wordpress.org/trunk@54408
git-svn-id: http://core.svn.wordpress.org/trunk@53967 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2022-10-07 11:40:13 +02:00
|
|
|
if ( ! wp_should_load_separate_core_block_assets() ) {
|
|
|
|
wp_add_inline_style( 'global-styles', $block_css );
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
Editor: Ensure global styles are rendered for third-party blocks.
This change ensures custom styles for all third-party blocks are rendered on the front end if assets are set to be loaded on a per-block basis. Additionally, this change includes new unit tests to help prevent a similar bug in the future.
Props scruffian, aristath, poena, wildworks, ajlende, andraganescu, ndiego, gigitux, cbravobernal, ramonopoly, andrewserong, oandregal, hellofromTonya, bernhard-reiter.
Fixes #56915.
Built from https://develop.svn.wordpress.org/trunk@54703
git-svn-id: http://core.svn.wordpress.org/trunk@54255 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2022-10-27 17:41:12 +02:00
|
|
|
$stylesheet_handle = 'global-styles';
|
2022-09-10 14:38:12 +02:00
|
|
|
if ( isset( $metadata['name'] ) ) {
|
|
|
|
/*
|
|
|
|
* These block styles are added on block_render.
|
|
|
|
* This hooks inline CSS to them so that they are loaded conditionally
|
|
|
|
* based on whether or not the block is used on the page.
|
|
|
|
*/
|
Editor: Ensure global styles are rendered for third-party blocks.
This change ensures custom styles for all third-party blocks are rendered on the front end if assets are set to be loaded on a per-block basis. Additionally, this change includes new unit tests to help prevent a similar bug in the future.
Props scruffian, aristath, poena, wildworks, ajlende, andraganescu, ndiego, gigitux, cbravobernal, ramonopoly, andrewserong, oandregal, hellofromTonya, bernhard-reiter.
Fixes #56915.
Built from https://develop.svn.wordpress.org/trunk@54703
git-svn-id: http://core.svn.wordpress.org/trunk@54255 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2022-10-27 17:41:12 +02:00
|
|
|
if ( str_starts_with( $metadata['name'], 'core/' ) ) {
|
|
|
|
$block_name = str_replace( 'core/', '', $metadata['name'] );
|
|
|
|
$stylesheet_handle = 'wp-block-' . $block_name;
|
|
|
|
}
|
|
|
|
wp_add_inline_style( $stylesheet_handle, $block_css );
|
2022-09-10 14:38:12 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
// The likes of block element styles from theme.json do not have $metadata['name'] set.
|
|
|
|
if ( ! isset( $metadata['name'] ) && ! empty( $metadata['path'] ) ) {
|
|
|
|
$result = array_values(
|
|
|
|
array_filter(
|
|
|
|
$metadata['path'],
|
2023-06-26 19:00:25 +02:00
|
|
|
static function ( $item ) {
|
Code Modernization: Replace usage of `strpos()` with `str_contains()`.
`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.
Built from https://develop.svn.wordpress.org/trunk@55988
git-svn-id: http://core.svn.wordpress.org/trunk@55500 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2023-06-22 16:36:26 +02:00
|
|
|
if ( str_contains( $item, 'core/' ) ) {
|
2022-09-10 14:38:12 +02:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
)
|
|
|
|
);
|
|
|
|
if ( isset( $result[0] ) ) {
|
Editor: Ensure global styles are rendered for third-party blocks.
This change ensures custom styles for all third-party blocks are rendered on the front end if assets are set to be loaded on a per-block basis. Additionally, this change includes new unit tests to help prevent a similar bug in the future.
Props scruffian, aristath, poena, wildworks, ajlende, andraganescu, ndiego, gigitux, cbravobernal, ramonopoly, andrewserong, oandregal, hellofromTonya, bernhard-reiter.
Fixes #56915.
Built from https://develop.svn.wordpress.org/trunk@54703
git-svn-id: http://core.svn.wordpress.org/trunk@54255 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2022-10-27 17:41:12 +02:00
|
|
|
if ( str_starts_with( $result[0], 'core/' ) ) {
|
|
|
|
$block_name = str_replace( 'core/', '', $result[0] );
|
|
|
|
$stylesheet_handle = 'wp-block-' . $block_name;
|
|
|
|
}
|
|
|
|
wp_add_inline_style( $stylesheet_handle, $block_css );
|
2022-09-10 14:38:12 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
Themes: Introduce wp_theme_has_theme_json() for public consumption.
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
2023-01-18 12:40:10 +01:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Checks whether a theme or its parent has a theme.json file.
|
|
|
|
*
|
|
|
|
* @since 6.2.0
|
|
|
|
*
|
|
|
|
* @return bool Returns true if theme or its parent has a theme.json file, false otherwise.
|
|
|
|
*/
|
|
|
|
function wp_theme_has_theme_json() {
|
Themes: Add static cache variable to wp_theme_has_theme_json().
For performance, a static variable is added to `wp_theme_has_theme_json()` to cache the boolean result of determining if a theme (or its parent) has a `theme.json` file.
This cache avoids the overhead of calling `get_stylesheet_directory()` and `get_template_directory()` each time `wp_theme_has_theme_json()` is invoked.
The cache is lean, non-persistent, and encapsulated within the function (i.e. function scope and not available externally).
The cache is ignored when:
* `WP_DEBUG` is on to avoid interrupting theme developer's workflow and for extender automated test suites.
* `WP_RUN_CORE_TESTS` is on to ensure each Core test exercises the checking code.
Follow-up to [55092], [55086].
Props oandregal, azaozz, costdev, dmsnell, flixos90, hellofromTonya, Otto42, spacedmonkey.
Fixes #56975.
Built from https://develop.svn.wordpress.org/trunk@55138
git-svn-id: http://core.svn.wordpress.org/trunk@54671 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2023-01-25 20:38:14 +01:00
|
|
|
static $theme_has_support = null;
|
|
|
|
|
|
|
|
if (
|
|
|
|
null !== $theme_has_support &&
|
|
|
|
/*
|
General: Introduce `WP_DEVELOPMENT_MODE` constant to signify context-specific development mode.
In recent releases, WordPress core added several instances of cache usage around specific files. While those caches are safe to use in a production context, in development certain nuances apply for whether or not those caches make sense to use. Initially, `WP_DEBUG` was used as a temporary workaround, but it was clear that a more granular method to signify a specific development mode was required: For example, caches around `theme.json` should be disabled when working on a theme as otherwise it would disrupt the theme developer's workflow, but when working on a plugin or WordPress core, this consideration does not apply.
This changeset introduces a `WP_DEVELOPMENT_MODE` constant which, for now, can be set to either "core", "plugin", "theme", or an empty string, the latter of which means no development mode, which is also the default. A new function `wp_get_development_mode()` is the recommended way to retrieve that configuration value.
With the new function available, this changeset replaces all existing instances of the aforementioned `WP_DEBUG` workaround to use `wp_get_development_mode()` with a more specific check.
Props azaozz, sergeybiryukov, peterwilsoncc, spacedmonkey.
Fixes #57487.
Built from https://develop.svn.wordpress.org/trunk@56042
git-svn-id: http://core.svn.wordpress.org/trunk@55554 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2023-06-26 21:57:25 +02:00
|
|
|
* Ignore static cache when the development mode is set to 'theme', to avoid interfering with
|
Themes: Add static cache variable to wp_theme_has_theme_json().
For performance, a static variable is added to `wp_theme_has_theme_json()` to cache the boolean result of determining if a theme (or its parent) has a `theme.json` file.
This cache avoids the overhead of calling `get_stylesheet_directory()` and `get_template_directory()` each time `wp_theme_has_theme_json()` is invoked.
The cache is lean, non-persistent, and encapsulated within the function (i.e. function scope and not available externally).
The cache is ignored when:
* `WP_DEBUG` is on to avoid interrupting theme developer's workflow and for extender automated test suites.
* `WP_RUN_CORE_TESTS` is on to ensure each Core test exercises the checking code.
Follow-up to [55092], [55086].
Props oandregal, azaozz, costdev, dmsnell, flixos90, hellofromTonya, Otto42, spacedmonkey.
Fixes #56975.
Built from https://develop.svn.wordpress.org/trunk@55138
git-svn-id: http://core.svn.wordpress.org/trunk@54671 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2023-01-25 20:38:14 +01:00
|
|
|
* the theme developer's workflow.
|
|
|
|
*/
|
General: Introduce `WP_DEVELOPMENT_MODE` constant to signify context-specific development mode.
In recent releases, WordPress core added several instances of cache usage around specific files. While those caches are safe to use in a production context, in development certain nuances apply for whether or not those caches make sense to use. Initially, `WP_DEBUG` was used as a temporary workaround, but it was clear that a more granular method to signify a specific development mode was required: For example, caches around `theme.json` should be disabled when working on a theme as otherwise it would disrupt the theme developer's workflow, but when working on a plugin or WordPress core, this consideration does not apply.
This changeset introduces a `WP_DEVELOPMENT_MODE` constant which, for now, can be set to either "core", "plugin", "theme", or an empty string, the latter of which means no development mode, which is also the default. A new function `wp_get_development_mode()` is the recommended way to retrieve that configuration value.
With the new function available, this changeset replaces all existing instances of the aforementioned `WP_DEBUG` workaround to use `wp_get_development_mode()` with a more specific check.
Props azaozz, sergeybiryukov, peterwilsoncc, spacedmonkey.
Fixes #57487.
Built from https://develop.svn.wordpress.org/trunk@56042
git-svn-id: http://core.svn.wordpress.org/trunk@55554 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2023-06-26 21:57:25 +02:00
|
|
|
wp_get_development_mode() !== 'theme' &&
|
Themes: Add static cache variable to wp_theme_has_theme_json().
For performance, a static variable is added to `wp_theme_has_theme_json()` to cache the boolean result of determining if a theme (or its parent) has a `theme.json` file.
This cache avoids the overhead of calling `get_stylesheet_directory()` and `get_template_directory()` each time `wp_theme_has_theme_json()` is invoked.
The cache is lean, non-persistent, and encapsulated within the function (i.e. function scope and not available externally).
The cache is ignored when:
* `WP_DEBUG` is on to avoid interrupting theme developer's workflow and for extender automated test suites.
* `WP_RUN_CORE_TESTS` is on to ensure each Core test exercises the checking code.
Follow-up to [55092], [55086].
Props oandregal, azaozz, costdev, dmsnell, flixos90, hellofromTonya, Otto42, spacedmonkey.
Fixes #56975.
Built from https://develop.svn.wordpress.org/trunk@55138
git-svn-id: http://core.svn.wordpress.org/trunk@54671 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2023-01-25 20:38:14 +01:00
|
|
|
/*
|
|
|
|
* Ignore cache when automated test suites are running. Why? To ensure
|
|
|
|
* the static cache is reset between each test.
|
|
|
|
*/
|
|
|
|
! ( defined( 'WP_RUN_CORE_TESTS' ) && WP_RUN_CORE_TESTS )
|
|
|
|
) {
|
|
|
|
return $theme_has_support;
|
|
|
|
}
|
|
|
|
|
2023-06-28 07:57:28 +02:00
|
|
|
// This is the same as get_theme_file_path(), which isn't available in load-styles.php context
|
|
|
|
if ( file_exists( get_stylesheet_directory() . '/theme.json' ) ) {
|
|
|
|
$path = get_stylesheet_directory() . '/theme.json';
|
|
|
|
} else {
|
|
|
|
$path = get_template_directory() . '/theme.json';
|
|
|
|
}
|
|
|
|
|
|
|
|
/** This filter is documented in wp-includes/link-template.php */
|
|
|
|
$path = apply_filters( 'theme_file_path', $path, 'theme.json' );
|
|
|
|
|
|
|
|
if ( file_exists( $path ) ) {
|
|
|
|
$theme_has_support = true;
|
|
|
|
} else {
|
|
|
|
$theme_has_support = false;
|
|
|
|
}
|
Themes: Introduce wp_theme_has_theme_json() for public consumption.
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
2023-01-18 12:40:10 +01:00
|
|
|
|
2023-01-18 22:59:13 +01:00
|
|
|
return $theme_has_support;
|
Themes: Introduce wp_theme_has_theme_json() for public consumption.
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
2023-01-18 12:40:10 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Cleans the caches under the theme_json group.
|
|
|
|
*
|
|
|
|
* @since 6.2.0
|
|
|
|
*/
|
|
|
|
function wp_clean_theme_json_cache() {
|
2023-01-27 00:03:14 +01:00
|
|
|
wp_cache_delete( 'wp_get_global_stylesheet', 'theme_json' );
|
2023-02-01 23:59:13 +01:00
|
|
|
wp_cache_delete( 'wp_get_global_styles_svg_filters', 'theme_json' );
|
2023-01-27 23:14:12 +01:00
|
|
|
wp_cache_delete( 'wp_get_global_settings_custom', 'theme_json' );
|
|
|
|
wp_cache_delete( 'wp_get_global_settings_theme', 'theme_json' );
|
Editor: Add support for custom CSS in global styles.
This changeset introduces functions `wp_get_global_styles_custom_css()` and `wp_enqueue_global_styles_custom_css()`, which allow accessing and enqueuing custom CSS added via global styles.
Custom CSS via global styles is handled separately from custom CSS via the Customizer. If a site uses both features, the custom CSS from both sources will be loaded. The global styles custom CSS is then loaded after the Customizer custom CSS, so if there are any conflicts between the rules, the global styles take precedence.
Similarly to e.g. [55185], the result is cached in a non-persistent cache, except when `WP_DEBUG` is on to avoid interrupting the theme developer's workflow.
Props glendaviesnz, oandregal, ntsekouras, mamaduka, davidbaumwald, hellofromtonya, flixos90.
Fixes #57536.
Built from https://develop.svn.wordpress.org/trunk@55192
git-svn-id: http://core.svn.wordpress.org/trunk@54725 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2023-02-02 19:52:17 +01:00
|
|
|
wp_cache_delete( 'wp_get_global_styles_custom_css', 'theme_json' );
|
Themes: Introduce wp_theme_has_theme_json() for public consumption.
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
2023-01-18 12:40:10 +01:00
|
|
|
WP_Theme_JSON_Resolver::clean_cached_data();
|
|
|
|
}
|
2023-06-16 10:08:23 +02:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Returns the current theme's wanted patterns (slugs) to be
|
|
|
|
* registered from Pattern Directory.
|
|
|
|
*
|
|
|
|
* @since 6.3.0
|
|
|
|
*
|
|
|
|
* @return string[]
|
|
|
|
*/
|
2023-06-22 09:16:19 +02:00
|
|
|
function wp_get_theme_directory_pattern_slugs() {
|
2023-06-16 10:08:23 +02:00
|
|
|
return WP_Theme_JSON_Resolver::get_theme_data( array(), array( 'with_supports' => false ) )->get_patterns();
|
|
|
|
}
|
2023-06-27 10:48:24 +02:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Determines the CSS selector for the block type and property provided,
|
|
|
|
* returning it if available.
|
|
|
|
*
|
|
|
|
* @since 6.3.0
|
|
|
|
*
|
|
|
|
* @param WP_Block_Type $block_type The block's type.
|
|
|
|
* @param string|array $target The desired selector's target, `root` or array path.
|
|
|
|
* @param boolean $fallback Whether to fall back to broader selector.
|
|
|
|
*
|
|
|
|
* @return string|null CSS selector or `null` if no selector available.
|
|
|
|
*/
|
|
|
|
function wp_get_block_css_selector( $block_type, $target = 'root', $fallback = false ) {
|
|
|
|
if ( empty( $target ) ) {
|
|
|
|
return null;
|
|
|
|
}
|
|
|
|
|
|
|
|
$has_selectors = ! empty( $block_type->selectors );
|
|
|
|
|
|
|
|
// Root Selector.
|
|
|
|
|
|
|
|
// Calculated before returning as it can be used as fallback for
|
|
|
|
// feature selectors later on.
|
|
|
|
$root_selector = null;
|
|
|
|
|
|
|
|
if ( $has_selectors && isset( $block_type->selectors['root'] ) ) {
|
|
|
|
// Use the selectors API if available.
|
|
|
|
$root_selector = $block_type->selectors['root'];
|
|
|
|
} elseif ( isset( $block_type->supports['__experimentalSelector'] ) && is_string( $block_type->supports['__experimentalSelector'] ) ) {
|
|
|
|
// Use the old experimental selector supports property if set.
|
|
|
|
$root_selector = $block_type->supports['__experimentalSelector'];
|
|
|
|
} else {
|
|
|
|
// If no root selector found, generate default block class selector.
|
|
|
|
$block_name = str_replace( '/', '-', str_replace( 'core/', '', $block_type->name ) );
|
|
|
|
$root_selector = ".wp-block-{$block_name}";
|
|
|
|
}
|
|
|
|
|
|
|
|
// Return selector if it's the root target we are looking for.
|
|
|
|
if ( 'root' === $target ) {
|
|
|
|
return $root_selector;
|
|
|
|
}
|
|
|
|
|
|
|
|
// If target is not `root` we have a feature or subfeature as the target.
|
|
|
|
// If the target is a string convert to an array.
|
|
|
|
if ( is_string( $target ) ) {
|
|
|
|
$target = explode( '.', $target );
|
|
|
|
}
|
|
|
|
|
|
|
|
// Feature Selectors ( May fallback to root selector ).
|
|
|
|
if ( 1 === count( $target ) ) {
|
|
|
|
$fallback_selector = $fallback ? $root_selector : null;
|
|
|
|
|
|
|
|
// Prefer the selectors API if available.
|
|
|
|
if ( $has_selectors ) {
|
|
|
|
// Look for selector under `feature.root`.
|
|
|
|
$path = array_merge( $target, array( 'root' ) );
|
|
|
|
$feature_selector = _wp_array_get( $block_type->selectors, $path, null );
|
|
|
|
|
|
|
|
if ( $feature_selector ) {
|
|
|
|
return $feature_selector;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Check if feature selector is set via shorthand.
|
|
|
|
$feature_selector = _wp_array_get( $block_type->selectors, $target, null );
|
|
|
|
|
|
|
|
return is_string( $feature_selector ) ? $feature_selector : $fallback_selector;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Try getting old experimental supports selector value.
|
|
|
|
$path = array_merge( $target, array( '__experimentalSelector' ) );
|
|
|
|
$feature_selector = _wp_array_get( $block_type->supports, $path, null );
|
|
|
|
|
|
|
|
// Nothing to work with, provide fallback or null.
|
|
|
|
if ( null === $feature_selector ) {
|
|
|
|
return $fallback_selector;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Scope the feature selector by the block's root selector.
|
|
|
|
return WP_Theme_JSON::scope_selector( $root_selector, $feature_selector );
|
|
|
|
}
|
|
|
|
|
|
|
|
// Subfeature selector
|
|
|
|
// This may fallback either to parent feature or root selector.
|
|
|
|
$subfeature_selector = null;
|
|
|
|
|
|
|
|
// Use selectors API if available.
|
|
|
|
if ( $has_selectors ) {
|
|
|
|
$subfeature_selector = _wp_array_get( $block_type->selectors, $target, null );
|
|
|
|
}
|
|
|
|
|
|
|
|
// Only return if we have a subfeature selector.
|
|
|
|
if ( $subfeature_selector ) {
|
|
|
|
return $subfeature_selector;
|
|
|
|
}
|
|
|
|
|
|
|
|
// To this point we don't have a subfeature selector. If a fallback
|
|
|
|
// has been requested, remove subfeature from target path and return
|
|
|
|
// results of a call for the parent feature's selector.
|
|
|
|
if ( $fallback ) {
|
|
|
|
return wp_get_block_css_selector( $block_type, $target[0], $fallback );
|
|
|
|
}
|
|
|
|
|
|
|
|
return null;
|
|
|
|
}
|