Quadrat: Add color customization #3856
Conversation
I wholeheartedly agree. That makes those two properties "universal" so it's a solid step. |
|
Oh, man this PR has been a LOT of fun to tinker with. Thank you so much! A couple of things I now realize: This CPT IS where the global styles store user data. I see that now and it would be trivial (ish) to pull/push those values from After tinkering with this I also don't believe that we should be storing any of these customization in theme_mod but instead rely completely on the CPT for storing the user's preference. The "merging" conversation regarding |
|
Currently it seems that custom variables aren't coming through (at least that's my guess) The site title size isn't correct and all of the button styles have gone away. I suspect there's more and that it's all related to the same something.
I thought it might have been from a previous incarnation of user customized theme.json values so to be sure I recreated the environment and have the same result. From what I can tell it's the call to |
|
I can confirm seeing the same as @pbking. |
|
Thanks for testing. I've now fixed that issue. |
|
I've banged around a lot on this. Love the real-time preview. I haven't been able to get it to do anything other than what I expected so in that I think it's pretty solid. I'm super-tickled to have a mechanism by which to manipulate the user-controlled theme.json! Really appreciate you making this work for real! To finalize this we should still account for more colors beyond just foreground/background, and that those colors should also be stored in the CPT in the "custom" space. I realize that won't be editable in the FSE but as color management tooling it just not complete for what Quadrat needs. I've seen some usage of color picking tooling that included custom palette colors. Would it be possible to add that in (and to expand Quadrat's descriptive palette to include some of the alternate colors in the figma)? |
| /** | ||
| * Add Global Styles Variables | ||
| */ | ||
| require get_template_directory() . '/inc/global-styles-variables.php'; |
There was a problem hiding this comment.
I would be keen for this (and related) changes (moving foreground/background variable consumption from custom to generated variables) into trunk sooner than later (even without the color changing bits). Definitely a good change.
There was a problem hiding this comment.
Yeah I agree. I'll make a PR for this.
|
I poked around a bit and if you remove this condition from global styles, you get your color customizations in the post editor too! |
Is that still necessary if we add a file in block-templates/index.html? |
|
No but if we add a |
quadrat/inc/customization.php
Outdated
| array( | ||
| 'name' => __( 'Foreground Color' ), | ||
| 'type' => 'color', | ||
| 'default' => $this->get_color( $theme_json['styles']['color']['text'], $color_palette ), |
There was a problem hiding this comment.
I just ran into an issue:
- I change the foreground and background colors on this PR
- Switched to a different PR, the color customizations persisted
- Switched back to this PR to change the colors back to default
- Clicking default in the color picker didn't work as expected — instead it just returned them to whatever custom color they were last set to.
Do you know why that would happen?
|
Closing in favour of #4090 |
This is a different approach to #3817.
The general approach is to replicate the functionality of Global Styles in the Customizer. This means that we modify the custom post type, so that the data can be shared between both environments.
To simplify this I have also removed the custom background and custom foreground colors and implemented new variables for these, which can be referenced in the CSS.
I have also added a preview to the Customizer which just injects some CSS to target the relevant selectors and also modifies the variables.
The code is written to be extendable so it should be trivial to add support for custom link colors too.