With Gutenberg out, everyone’s starting to use the shiny new color settings.
That’s great, but if you also are building your own blocks using Advanced Custom Fields (ACF), the color picker you see there probably doesn’t include your custom colors, which is not the best user experience. The default colors at the bottom here don’t really correspond to anything; they’re just primary colors, which is probably not what you want your users picking if you’re building a theme:
Luckily, it’s possible to put them into sync, and it’s not particularly difficult.
I looked all over the place, and couldn’t find anyone with a tutorial about it. I haven’t seen this method used anywhere else all together just yet, but I’m drawing on a number of guides in pulling together the functionality to completely automate this process.
- Tutorials from ACF and from Bill Erickson on building ACF Gutenberg blocks
- Rich Tabor’s guide to implementing Gutenberg’s color palette
- ACF’s guide on their color picker, along with ACF’s guide to their javascript hooks (scroll to “color_picker_args” near the bottom)
- Kristin Faulkner on adding custom colors to Iris
So here are the basic tasks we need to accomplish:
- Registering some colors in our functions file (this should always be done in a theme) to get Gutenberg colors up and running
- Automatically extracting those colors and getting them into a format that will work for adding them to the ACF color picker (could be done in a theme or plugin as appropriate)
- Hooking in automatically to all instances of the ACF color picker and adding the colors (could be done in a theme or plugin as appropriate)
Registering the colors
Just about everyone’s written about how to register colors in your theme, and Genesis even does this automatically in their base theme. Basically, in our functions.php file, we just add them like so:
Simple enough, right? Just plug in in your colors, make sure to give them names, and use your own textdomain.
Getting the colors in a usable format
What’s next is getting those colors into a format that is usable (we peeked at the form used by ACF’s javascript integration). That looks something like this:
['#333333', '#222222', '#111111']So, we’re going to get the array of colors, then loop through it to build the markup above.
Adding the default colors into the ACF color picker
Now, we’re going to hook into ACF’s javascript integration and use the function we’ve just created to add the colors.
That’s all! Just add those three snippets into your functions file, and you should be all set! For my purposes, (I’m building a plugin which needs this done automatically), I’m including two of them in a plugin, then still allowing the theme to define the colors.
Once added, both the Gutenberg colors and the ACF color picker should be synced up, and they should look something like this:
The Gutenberg color picker 
The ACF color picker
Nice tutorial – I was looking for a way to sync the ACF and Gutenberg color pickers.
It seems to me like there needs to be a separate ACF field type which uses the color picker and palette in the same way as the native Gutenberg paragraph, button etc blocks do.
With them – they return a CSS class like ‘has-primary-background-color’ – which is what I would like my custom ACF (v5.8) Gutenberg Blocks to do. But the standard ACF color picker just returns a HEX value.
Yeah, I completely agree. I’d actually love to see them move to the new color picker entirely. It’s really, really pretty compared with the current ACF picker, and less limiting (if you try adding 20 colors, it starts to break down a bit). I’d love for them to return both values (the name of the color and the hex code) as well, though I don’t think there’s functionality right now to actually label the colors in ACF at all, if I remember right.
It’s pretty handy to allow for the person using the site to pick any color at all, though. I built a little plugin for my own sites that preconfigures several ACF blocks, and it does allow for any background color (or color overlay) to be added, and it’s been nice a few times already to allow a particular section to go off-palette – for example, if I’m overlaying a video background with an overlay at 60% opacity, sometimes my theme-defined color just looks too light over top of the video, so it’s nice to pick a darker version of the color that I don’t necessarily want the client to see as a preset.
Actually, if you wanted a (kind of ugly) way to put those pieces into sync, you probably could use php to get the hex code (as if you were about to output it), then use something pretty similar to output_the_colors() to detect which color corresponds and output the corresponding class instead of the hex code.
The main reason this implementation is ugly is that if you ever changed your color definition for “blue,” for example, then it would no longer stay in sync (because your code would no longer see a corresponding class for the old color hex code where that’s selected): but you could output both the class and the hex code to keep it from breaking too badly.
Great tutorial! I was looking for how to do this. 🙂
Nice solution! Thanks for putting this out there.
Awesome! Works perfectly.
I wish ACF blocks would support the default text and background color palettes from Gutenberg.
Nice piece of code !
I’ll add something similar to my automatic color palette generator. Based on css rules in a css file (using css variables), I’m able to create Gutenberg and ACF palette !
Any way to get this work with the text color in acf wysiwyg?
I haven’t tried this (not a bad idea!), but I think something along these lines would probably get you there:
https://wordpress.stackexchange.com/questions/233450/how-do-you-add-custom-color-swatches-to-all-wysiwyg-editors
Here’s the best writeup I found of how to add the Gutenberg native color picker to ACF blocks: https://www.billerickson.net/color-palette-with-acf-custom-blocks/
Absolutely! Bill’s is a much better option now for most use cases (and the methodology I’ve used here in this old blog post doesn’t actually work with theme.json themes regardless). Here’s an updated approach that works with theme.json, but does not use the native color-picker (yet). In my particular use case shown here, I have older user data to worry about and haven’t tried to update this to use Bill’s superior approach.
https://gist.github.com/jonschr/02a320eb5d8ed5e5917e28fea0c9b1cc