-
Notifications
You must be signed in to change notification settings - Fork 356
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
Blockbase: Add support for custom palettes customization #4098
Blockbase: Add support for custom palettes customization #4098
Conversation
@kjellr if you have any input on this UI, I would appreciate your 👀 |
I think this looks good to merge, but it would be good to have some more eyes on it. |
'colors' => $default_palette_setting, | ||
); | ||
|
||
$custom_palettes = $theme_json['settings']['custom']['colorPalettes']; |
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 getting an error here w/ Quadrat due to there being no palette's currently defined in theme.json
Likely the Quadrat palette options weren't included in the change (yet).
But seems reasonable that a BB child might not ship with any customizations so probably a relevant use-case.
Notice: Undefined index: colorPalettes in /var/www/html/wp-content/themes/themes/blockbase/inc/wp-customize-color-palettes.php on line 33 Warning: Invalid argument supplied for foreach() in /var/www/html/wp-content/themes/themes/blockbase/inc/wp-customize-color-palettes.php on line 34
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.
yeah, that fixed disappeared on a conflict, let me get it back
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.
should be fine now
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.
Pushed this small change to only render these controls if there are alternatives to default to show. Also addressed that error that seemed to stick around despite the recent change.
I'm of the opinion that the alternative palettes should be BUTTONS instead of RADIO BUTTONS. The action feels more like "apply these colors to my color pickers" rather than "select these colors to use" and BUTTON rather than RADIO BUTTON seems to reflect that better. Otherwise we will invite the situation where an option might be chosen and then customized. In this situation the RADIO BUTTON would need to be unselected (no option selected) otherwise that option couldn't be returned to without selecting something else and returning. If we do keep it as a RADIO BUTTON then I suggest another stylistic mechanism to signify that that option is selected (It's difficult to see.) That's just an opinionated nit-pick. Otherwise this looks FANTASTIC and I would be happy to ship as-is and iterate. |
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.
Tested in all four themes and it is a thing of beauty 👏
I did run into an issue with Quadrat. Because of the way our merge / build step works for child theme, the colorPalettes
from blockbase are added, which results in the following error after I build Quadrat's theme.json:
If I provide a new palette with only the three colors per palette using the same palette slug (e.g. featured-1
) and run build, I still get the above error because the merge appends the values to the colors. In this instance, I think what needs to happen is that the entire key colorPalettes
object is replaced with the child-theme.json
value, rather than the recursive merge.
@@ -116,6 +116,38 @@ | |||
"secondary": "var(--wp--preset--color--secondary)", | |||
"selection": "var(--wp--preset--color--selection)" | |||
}, | |||
"colorPalettes": { | |||
"palette-1": { | |||
"label": "Featured", |
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 there is a mechanism now for labels for presets to get translated, but is there a way yet to mark that a custom variable needs to be translated?
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 we do it like this. Since we haven't done this for any of the strings that we have (such as the template parts) I think this merits its own separate PR
I wonder if this means we should switch to using an array... |
I think we kind of have to, it's what's consistent with what we've done for other variables like this |
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.
c135fe6
to
28f033b
Compare
I think this is because the Global Styles settings weren't populating back into the customizer. I had to put back the settings file I removed because I couldn't find a way to set a dirty value. |
Changes proposed in this Pull Request:
This is a WIP. The goal is to give the user optional palettes provided by the theme's designers. Right now I'm using the code from https://github.com/HardeepAsrani/o2 as a starting point but this is a list of what I hope this will be able to do: