* Gets the settings resulting of merging core, theme, and user data.

 * @return mixed The settings array or individual setting value to retrieve.

		$new_path = array( 'blocks', $context['block_name'] );

		foreach ( $path as $subpath ) {

			$new_path[] = $subpath;

		}

		$path = $new_path;

	/*

	 * 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.

	 */

	if (

		! wp_theme_has_theme_json() ||

		( isset( $context['origin'] ) && 'base' === $context['origin'] )

	) {

	/*

	 * 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 behavior:

	 * 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;

	/*

	 * Ignore cache when the development mode is set to 'theme', so it doesn't interfere with the theme

	 * developer's workflow.

	 */

	$can_use_cached = ! wp_is_development_mode( 'theme' );

	$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 );

		}

	}

 * Gets the styles resulting of merging core, theme, and user data.

 * @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.

 *     @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.

 * @return mixed The styles array or individual style value to retrieve.

	$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'];

 * @since 6.1.0 Added 'base-layout-styles' support.

 * @since 6.6.0 Resolves relative paths in theme.json styles to theme absolute paths.

 * @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'.

	/*

	 * Ignore cache when the development mode is set to 'theme', so it doesn't interfere with the theme

	 * developer's workflow.

	 */

	$can_use_cached = empty( $types ) && ! wp_is_development_mode( 'theme' );

	/*

	 * 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';

		$cached = wp_cache_get( $cache_key, $cache_group );

	$tree                = WP_Theme_JSON_Resolver::resolve_theme_file_uris( WP_Theme_JSON_Resolver::get_merged_data() );

	$supports_theme_json = wp_theme_has_theme_json();

		$types = array( 'variables', 'presets', 'base-layout-styles' );

	 * If variables are part of the stylesheet, then add them.

		/*

		 * 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 );

		/*

		 * 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

		 */

		/*

		 * If the theme doesn't have theme.json but supports both appearance tools and color palette,

		 * the 'theme' origin should be included so color palette presets are also output.

		 */

		if ( ! $supports_theme_json && ( current_theme_supports( 'appearance-tools' ) || current_theme_supports( 'border' ) ) && current_theme_supports( 'editor-color-palette' ) ) {

			$origins = array( 'default', 'theme' );

		} elseif ( ! $supports_theme_json ) {

	if ( $can_use_cached ) {

		wp_cache_set( $cache_key, $stylesheet, $cache_group );

	}

	return $stylesheet;

}

/**

 * Gets the global styles custom CSS from theme.json.

 *

 * @since 6.2.0

 *

 * @return string The global styles custom CSS.

 */

function wp_get_global_styles_custom_css() {

	if ( ! wp_theme_has_theme_json() ) {

		return '';

	}

	/*

	 * Ignore cache when the development mode is set to 'theme', so it doesn't interfere with the theme

	 * developer's workflow.

	 */

	$can_use_cached = ! wp_is_development_mode( 'theme' );

	/*

	 * 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();

		wp_cache_set( $cache_key, $stylesheet, $cache_group );

 * Adds global style rules to the inline style for each block.

 *

 * @since 6.1.0

 * @global WP_Styles $wp_styles

 */

function wp_add_global_styles_for_blocks() {

	global $wp_styles;

	$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 );

		if ( ! wp_should_load_separate_core_block_assets() ) {

			wp_add_inline_style( 'global-styles', $block_css );

			continue;

		}

		$stylesheet_handle = 'global-styles';

		/*

		 * When `wp_should_load_separate_core_block_assets()` is true, block styles are

		 * enqueued for each block on the page in class WP_Block's render function.

		 * This means there will be a handle in the styles queue for each of those blocks.

		 * Block-specific global styles should be attached to the global-styles handle, but

		 * only for blocks on the page, thus we check if the block's handle is in the queue

		 * before adding the inline style.

		 * This conditional loading only applies to core blocks.

		 */

		if ( isset( $metadata['name'] ) ) {

			if ( str_starts_with( $metadata['name'], 'core/' ) ) {

				$block_name   = str_replace( 'core/', '', $metadata['name'] );

				$block_handle = 'wp-block-' . $block_name;

				if ( in_array( $block_handle, $wp_styles->queue, true ) ) {

					wp_add_inline_style( $stylesheet_handle, $block_css );

				}

			} else {

				wp_add_inline_style( $stylesheet_handle, $block_css );

			}

		}

		// The likes of block element styles from theme.json do not have  $metadata['name'] set.

		if ( ! isset( $metadata['name'] ) && ! empty( $metadata['path'] ) ) {

			$block_name = wp_get_block_name_from_theme_json_path( $metadata['path'] );

			if ( $block_name ) {

				if ( str_starts_with( $block_name, 'core/' ) ) {

					$block_name   = str_replace( 'core/', '', $block_name );

					$block_handle = 'wp-block-' . $block_name;

					if ( in_array( $block_handle, $wp_styles->queue, true ) ) {

						wp_add_inline_style( $stylesheet_handle, $block_css );

					}

				} else {

					wp_add_inline_style( $stylesheet_handle, $block_css );

				}

			}

		}

	}

}

/**

 * Gets the block name from a given theme.json path.

 * @since 6.3.0

 * @access private

 *

 * @param array $path An array of keys describing the path to a property in theme.json.

 * @return string Identified block name, or empty string if none found.

function wp_get_block_name_from_theme_json_path( $path ) {

	// Block name is expected to be the third item after 'styles' and 'blocks'.

	if (

		count( $path ) >= 3

		&& 'styles' === $path[0]

		&& 'blocks' === $path[1]

		&& str_contains( $path[2], '/' )

	) {

		return $path[2];

	}

	/*

	 * As fallback and for backward compatibility, allow any core block to be

	 * at any position.

	 */

	$result = array_values(

		array_filter(

			$path,

			static function ( $item ) {

				if ( str_contains( $item, 'core/' ) ) {

					return true;

				}

				return false;

			}

		)

	if ( isset( $result[0] ) ) {

		return $result[0];

	}

	return '';

}

/**

 * 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() {

	static $theme_has_support = array();

	$stylesheet = get_stylesheet();

	if (

		isset( $theme_has_support[ $stylesheet ] ) &&

		/*

		 * Ignore static cache when the development mode is set to 'theme', to avoid interfering with

		 * the theme developer's workflow.

		 */

		! wp_is_development_mode( 'theme' )

	) {

		return $theme_has_support[ $stylesheet ];

	}

	$stylesheet_directory = get_stylesheet_directory();