-
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
defaultGradients doesn't work properly #41356
Comments
From what I understand, this is the correct behavior. Disabling the default gradients is meant to remove them from the UI. However, it is not necessarily unused CSS. WordPress still delivers the CSS for compatibility so that users do not lose preexisting gradient selections. If you really wanted to remove core's CSS, it's best to dequeue the wp-block-library styles and roll out custom styles. |
I don’t think so. If I want to remove default gradients and added such code, then I want really remove them and not just hide. Otherwise, we need another filter to remove them totally. from my point of view, Wordpress team are concentrated on block logic and conditional assets. For example, if I don’t use group block, then styles of this block is not loading. So, what is the reason to load such big amount of styles if I deactivated them? |
Related: #40183
Right now, the end user needs the styles to be loaded regardless of whether a theme supports the core gradients. For example, let's say the user had Twenty Twenty-Two installed for a while and used those gradients for their blocks. Then, they install a different theme that doesn't support the core gradients. The user might still want their old gradients to appear correctly. Otherwise, their site looks broken. So, the styles are still needed in those cases. The method in which this is handled needs some work. Ideally, Gutenberg/WP would only load those disabled gradient styles if they were in use on a particular page instead of loading them globally when not supported by the theme. Basically, conditional loading. |
Ok. This has a sense. To be truth, it’s not clear what is the reason to load all gradients at once if it’s possible to load gradient which is used for block. Like we have for all other settings: margins, paddings, etc |
I agree that the Core contributors haven't clearly or prominently communicated to developers based on the number of issues that I've seen about this. The ability to only load a certain gradient when it is used on a specific page or block as @justintadlock described is not possible yet; although I'd personally argue that should have been done when gradients were introduced. They do eventually plan to conditionally load the gradients so they only load when they are being used (I cannot find the issue about this at the moment) where you could track the progress of this. Some of the rationale about this is at and at #38299 (comment) and #38681 (comment) |
Description
I want to disable default gradients and register custom.
I tried defaultGradients option set to false in theme.json and add_theme_support( 'editor-gradient-presets', array() );
Problem is that both ways remove default gradient selectors, but still keep loading all gradients styles in wp-block-library-inline-css and global-styles-inline-css styles which are loaded on all pages of site and generates unused css.
Step-by-step reproduction instructions
Screenshots, screen recording, code snippet
No response
Environment info
No response
Please confirm that you have searched existing issues in the repo.
Yes
Please confirm that you have tested with all plugins deactivated except Gutenberg.
Yes
The text was updated successfully, but these errors were encountered: