-
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
Support enabling/disabling custom gradients using theme.json #24964
Support enabling/disabling custom gradients using theme.json #24964
Conversation
Size Change: -3 B (0%) Total Size: 1.17 MB
ℹ️ View Unchanged
|
I'm going to accelerate a bit on these PRs as they are all similar and do the same thing for different flags. |
@@ -181,6 +181,9 @@ function ColorGradientControlSelect( props ) { | |||
colorGradientSettings.disableCustomColors = ! useEditorFeature( | |||
'color.custom' | |||
); | |||
colorGradientSettings.disableCustomGradients = ! useEditorFeature( | |||
'gradients.custom' |
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 think this should be gradient.custom
. Fix at #25040
[] | ||
); | ||
const gradients = | ||
useSelect( |
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.
Does it make sense to have a usePreset('gradients')
hook?
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 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 see! I'm only 10 days behind 🏃 💨
@@ -130,6 +130,9 @@ | |||
}, | |||
"color": { | |||
"custom": true | |||
}, |
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.
Food for thought: I'm finding the current format too verbose.
{
"features": {
"typography": {
"dropCap": true
},
"color": {
"custom": true
},
"gradient": {
"custom": true
}
}
}
My expectations were that we'd group the features under typography
and color
sub-families, as we do in the style subtree. If we aren't going to group the features by family I think I'd prefer something a bit more terse, along these lines:
{
"features": {
"dropCap": true,
"customColor": true,
"customGradient": true
}
}
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 agree that at the current state, it doesn't make sense to have the nesting but I also think we'll probably add things under the top level keys. In fact as you see on my linked comment above, I initially was thinking the preset is one of these keys (since the preset also allows to disable the control when you provide an empty one).
I'm not too concerned at the moment but this is something we should revisit once we move all the features.
Related #20588
Similar to #24761 but for custom gradients
The idea of this PR is to support disabling/enabling custom gradients from theme.json while retaining backward compatibility for the disable-custom-gradients theme support flag.
Testing instructions
disable-custom-gradients
gradient.custom
path.