-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove usage of get_default_block_editor_settings #46112
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@spacedmonkey The idea here makes total sense to me, however I think there's a more efficient approach to it. This PR would introduce much duplicate code. I left my alternative suggestion below.
If we go with that, we won't be able to do it purely in Gutenberg since the function is only in WP core, but I think that's okay. If you agree, let's open a Trac ticket to enhance that function to allow granular field computation for only what is needed.
Then we can already fix this in core, and Gutenberg will only need a tiny PR to pass the new parameter. (It will be backward compatible since when the function doesn't support the new parameter it'll just be slower, but not broken.)
$gradient_presets = current( (array) get_theme_support( 'editor-gradient-presets' ) ); | ||
if ( false !== $gradient_presets ) { | ||
$editor_settings['gradients'] = $gradient_presets; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All of the new code here is now a bit of a duplicate code from what is already in get_default_block_editor_settings()
. I think we can solve the problem in a more efficient way by enhancing that function.
|
||
/* | ||
* We want the presets and settings declared in theme.json | ||
* to override the ones declared via theme supports. | ||
* So we take theme supports, transform it to theme.json shape | ||
* and merge the static::$theme upon that. | ||
*/ | ||
$theme_support_data = WP_Theme_JSON_Gutenberg::get_from_editor_settings( get_default_block_editor_settings() ); | ||
$theme_support_data = WP_Theme_JSON_Gutenberg::get_from_editor_settings( $editor_settings ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I would suggest is the following:
- Add an optional
$fields
parameter (array of strings) to theget_default_block_editor_settings()
function. - Change the function internals to only compute the properties which are requested.
- Pass the new parameter here so that only the above actually needed properties are computed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Basically so that we can do something like:
$theme_support_data = WP_Theme_JSON_Gutenberg::get_from_editor_settings(
get_default_block_editor_settings(
array(
'disableCustomColors',
'disableCustomFontSizes',
'disableCustomGradients',
'disableLayoutStyles',
'enableCustomLineHeight',
'enableCustomSpacing',
'enableCustomUnits',
'colors',
'fontSizes',
'gradients',
)
)
);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Broken it up into it's own function with a comment. b0a9764
Where I understand where you are coming from here. I am not sure I agree. Using block settings functions was always wrong here. These are not block settings, these are theme feature detection. This function gives you the data but doesn't really describe what is happening here. If we add fields or a flag as a param, to function, that just makes things more confusing and the logic harder to follow. I think a better way forward, might be to add a function, like |
@@ -16,103 +16,6 @@ | |||
* @access private | |||
*/ | |||
class WP_Theme_JSON_Resolver_Gutenberg extends WP_Theme_JSON_Resolver_6_2 { | |||
/** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's something in this file that still needs to live in the experimental folder: the call to gutenberg_add_registered_webfonts_to_theme_json
.
This is in my list of things to look at to give it some clarity and improve the developer experience. Given that the change required here is a one-liner (get_default_block_editor_settings
to gutenberg_get_block_theme_supports
) and we need to look at this separately, would you mind making your changes in this file directly instead of moving it to 6.2?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Clarified in this slack thread.
* | ||
* @return array | ||
*/ | ||
function gutenberg_get_block_theme_supports() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would you consider a name such as gutenberg_get_legacy_theme_supports_for_theme_json
? Or something along that vein. It's more in line with what this code is used for. The current naming may imply that it returns all theme supports, and may mislead people.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Orignally was in experimental, but it would mean, that this code would do nothing in the plugin - 999b258
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I follow. Perhaps you meant to comment on this other thread? https://github.com/WordPress/gutenberg/pull/46112/files#r1037282457
If so, how does it do nothing if this code stays in lib/experimental
? The whole Gutenberg uses the class WP_Theme_JSON_Resolver_Gutenberg
defined in this file.
*/ | ||
function gutenberg_get_block_theme_supports() { | ||
$theme_settings = array( | ||
'disableCustomColors' => get_theme_support( 'disable-custom-colors' ), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at the code that uses this data (I didn't find a more recent definition of this code in Gutenberg), we need:
disableCustomColors
disableCustomGradients
disableCustomFontSizes
enableCustomLineHeight
enableCustomUnits
enableCustomSpacing
It seems we can get rid of disableLayoutStyles
in this method?
@@ -184,6 +184,41 @@ function gutenberg_get_global_settings( $path = array(), $context = array() ) { | |||
} | |||
|
|||
/** | |||
* Repeated logic from `get_default_block_editor_settings` function. When implemented into core, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It should also be ok to have two functions in core: get_default_block_editor_settings
and the very specific get_legacy_theme_supports_for_theme_json
.
Co-authored-by: André <583546+oandregal@users.noreply.github.com>
* | ||
* @return array | ||
*/ | ||
function gutenberg_get_legacy_theme_supports_for_theme_json() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, sorry for the confusion. This code should live in lib/compat/wordpress-6.2
or lib/compat/wordpress-6.1
, depending on the version we aim to backport it to. I only mentioned the resolver in my comment about the experimental folder.
@@ -73,7 +81,7 @@ public static function get_theme_data( $deprecated = array(), $settings = array( | |||
* So we take theme supports, transform it to theme.json shape | |||
* and merge the static::$theme upon that. | |||
*/ | |||
$theme_support_data = WP_Theme_JSON_Gutenberg::get_from_editor_settings( get_default_block_editor_settings() ); | |||
$theme_support_data = WP_Theme_JSON_Gutenberg::get_from_editor_settings( gutenberg_get_legacy_theme_supports_for_theme_json() ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Other than this line, is any other change necessary?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They are part of core. I will do that in another PR.
* Remove usage of get_default_block_editor_settings`. * Remove to it's own function. * Fix lints. * Move to 6.2 class. * WP_Theme_JSON -> WP_Theme_JSON_Gutenberg. * Update lib/compat/wordpress-6.2/class-wp-theme-json-resolver-6-2.php Co-authored-by: André <583546+oandregal@users.noreply.github.com> * Move functionality around again. * Fix merge conflict * Fix more issues. * More moving. * Revert changes. * More reverts. Co-authored-by: André <583546+oandregal@users.noreply.github.com>
… inheriting per WordPress version (#46750) * Backport WP_Theme_JSON_Resolver from core as it is * Substitute WP_Theme_JSON by WP_Theme_JSON_Gutenberg * Substitute WP_Theme_JSON_Data by WP_Theme_JSON_Data_Gutenberg * Rename WP_Theme_JSON_Resolver to WP_Theme_JSON_Resolver_Base The goal is to use it as base to inherit from, until we are able to remove all the children. * Make WP_Theme_JSON_Resolver_6_1 inherit from WP_Theme_JSON_Resolver_Base * 6.1: remove field already defined in base class * 6.1: remove translate, it is equal to base method * 6.1: remove get_core_data, it does not have base changes * 6.1: remove get_user_data Missed core changes and does not do anything differently from core. * 6.1: remove get_user_data_from_wp_global_styles It misses core changes and does not do anything differently. * 6.2: inherit from WP_Theme_JSON_Resolver_Base instead of 6.1 This makes the WP_Theme_JSON_Resover_6_1 class unused. * 6.1: remove class no longer in use * 6.2: deprecate theme_has_support #45380 * 6.2: substitute WP_Theme_JSON_Resolver::theme_has_support by wp_theme_has_theme_json() #45168 * 6.2: port changes to get_user_data_from_wp_global_styles #46043 * 6.2: update get_merged_data #45969 * 6.2: remove get_user_data Same code as core. There's a check for detecting whether the class is an instance of WP_Theme_JSON_Gutenberg that was not ported. This check was introduced to make sure the cache of the core class didn't interfere with the cache of the Gutenberg class, so it's no longer necessary. See #42756 * experimental: make it inherit from WP_Theme_JSON_Resolver_Base * 6.2: remove class no longer in use * experimental: delete remove_json_comments It's already part of the base class. * experimental: remove get_block_data It's already part of the base class and it didn't have the changes from core. * experimental: appearanceTools Port changes to the base class that were meant to be part of 6.1. See #43337 * experimental: port webfonts (experimental API) see #37140 * experimental: use gutenberg_get_legacy_theme_supports_for_theme_json #46112 * experimental: get_theme_data, all code is in the base class * experimental: remove empty class * Rename WP_Theme_JSON_Resolver_Base to WP_Theme_JSON_Resolver_Gutenberg * Fix lint issue: rename class-wp-theme-json-resolver.php to class-wp-theme-json-resolver-gutenberg.php * Move theme.json to unversioned lib/ * Move theme-i18n.json to unversioned lib/
… inheriting per WordPress version (#46750) * Backport WP_Theme_JSON_Resolver from core as it is * Substitute WP_Theme_JSON by WP_Theme_JSON_Gutenberg * Substitute WP_Theme_JSON_Data by WP_Theme_JSON_Data_Gutenberg * Rename WP_Theme_JSON_Resolver to WP_Theme_JSON_Resolver_Base The goal is to use it as base to inherit from, until we are able to remove all the children. * Make WP_Theme_JSON_Resolver_6_1 inherit from WP_Theme_JSON_Resolver_Base * 6.1: remove field already defined in base class * 6.1: remove translate, it is equal to base method * 6.1: remove get_core_data, it does not have base changes * 6.1: remove get_user_data Missed core changes and does not do anything differently from core. * 6.1: remove get_user_data_from_wp_global_styles It misses core changes and does not do anything differently. * 6.2: inherit from WP_Theme_JSON_Resolver_Base instead of 6.1 This makes the WP_Theme_JSON_Resover_6_1 class unused. * 6.1: remove class no longer in use * 6.2: deprecate theme_has_support #45380 * 6.2: substitute WP_Theme_JSON_Resolver::theme_has_support by wp_theme_has_theme_json() #45168 * 6.2: port changes to get_user_data_from_wp_global_styles #46043 * 6.2: update get_merged_data #45969 * 6.2: remove get_user_data Same code as core. There's a check for detecting whether the class is an instance of WP_Theme_JSON_Gutenberg that was not ported. This check was introduced to make sure the cache of the core class didn't interfere with the cache of the Gutenberg class, so it's no longer necessary. See #42756 * experimental: make it inherit from WP_Theme_JSON_Resolver_Base * 6.2: remove class no longer in use * experimental: delete remove_json_comments It's already part of the base class. * experimental: remove get_block_data It's already part of the base class and it didn't have the changes from core. * experimental: appearanceTools Port changes to the base class that were meant to be part of 6.1. See #43337 * experimental: port webfonts (experimental API) see #37140 * experimental: use gutenberg_get_legacy_theme_supports_for_theme_json #46112 * experimental: get_theme_data, all code is in the base class * experimental: remove empty class * Rename WP_Theme_JSON_Resolver_Base to WP_Theme_JSON_Resolver_Gutenberg * Fix lint issue: rename class-wp-theme-json-resolver.php to class-wp-theme-json-resolver-gutenberg.php * Move theme.json to unversioned lib/ * Move theme-i18n.json to unversioned lib/
Backport: WordPress/wordpress-develop#3902 |
What?
For context #57077
This fix, fixes a very serious performance issue, that results in calling get_optiion 2700-4000 times per page load.
The issue, is that the function get_default_block_editor_settings is called. This function returns an array of data, including lots of information needed for the editor. But in this context, json resolved is getting lots of data is that is never used. As this method is call 200-500 times per page load, it results in all these calls to
get_option
,is_rtl
andget_allowed_mime_types
, data is never used. This functions have serious overhead, as all of them have filters and some even database queries attached to them. As this function is called on the front end, this results in 11-15% of extra page load.This PR is simple, just pick the parts of
get_default_block_editor_settings
that are needed.Why?
How?
Testing Instructions
Screenshots or screencast
Code path.
Before
After