While there is no shortage of articles published about adding general support for a theme’s color palette within the Gutenberg editor, I’m going to focus on the color class changes deployed in Gutenberg 2.8.
Gutenberg includes a default color palette component for blocks to utilize, although it’s relatively easy for a WordPress theme to provide a more suitable palette to empower users.
Add support for color palettes
To add color palettes to the block editor, the first step is to add a call to add_theme_support in a WordPress theme’s functions.php file, referencing the editor-color-palette feature. Next, hook it in via after_theme_setup.
<?php
/**
* Add support for custom color palettes in Gutenberg.
*/
function tabor_gutenberg_color_palette() {
add_theme_support(
'editor-color-palette', array(
array(
'name' => esc_html__( 'Black', '@@textdomain' ),
'slug' => 'black',
'color' => '#2a2a2a',
),
array(
'name' => esc_html__( 'Gray', '@@textdomain' ),
'slug' => 'gray',
'color' => '#727477',
)
)
);
}
add_action( 'after_setup_theme', 'tabor_gutenberg_color_palette' );If you’re familiar with WordPress theme development, this is no different than any other opt-in feature that WordPress themes may support. Below you’ll find an example of how WordPress themes may add support for custom Gutenberg color palettes, and how I’ve deployed them within Tabor:
The two colors, black and gray, will be shown in the order they are added, as pictured in the screenshot below.
It’s also important to note that while there is no limit to how many colors can be defined, don’t go overboard. The point is to make a clear and cohesive color palette that will empower users, not confuse them.
If you’ve already updated your WordPress theme with a custom Gutenberg color palette, you’ve probably noticed a few slight differences in the example above from what you’ve deployed. Here’s how WordPress theme developers previously added custom color palettes, prior to Gutenberg 2.8—and consequently, what needs updating:
<?php
// Adds support for editor color palette.
add_theme_support( 'editor-color-palette',
'#2a2a2a',
'#7a7a7a',
);Gutenberg 2.8 introduces support for color classes, which allow colors to be assigned via classes, instead of inline styling. The new functionality makes total sense, albeit making custom palettes slightly more difficult to implement.
So let’s add support for our new color classes.
Add support for color classes
Adding the actual color palette is only the first step for WordPress themes to fully support custom color palettes.
Now that themes are responsible for establishing the styling associated with custom colors, developers are required to add all contextual style classes for each custom color added via the add_theme_support( 'editor-color-palette' ) function.
Referring back to the tabor_gutenberg_color_palette() example function above, I’ve added support for our two custom colors, black and gray. We’ll need to add appropriate color classes for those colors within the WordPress theme’s primary stylesheet and the theme’s Gutenberg stylesheet.
For reference, core blocks use color and background-color contexts, so we’ll do the same. The color class is defined with has appended to the color, followed by the color name using kebab case and ending with the context:
.has-black-background-color {
background-color: #2a2a2a;
}
.has-black-color {
background-color: #2a2a2a;
}
.has-gray-background-color {
background-color: #7a7a7a;
}
.has-gray-color {
color: #7a7a7a;
}Again, these color classes should be added to your theme’s primary stylesheet, as well as within Gutenberg, so that color selections are established on the front end and previewed in real-time within the editor.
I recently published a primer, covering how to add WordPress theme styles to Gutenberg, if you need a refresher.
Now that we’ve added the custom colors to Gutenberg via add_theme_support( 'editor-color-palette' ), created color classes with appropriate contexts to reference our colors, and loaded those classes into Gutenberg, your theme’s custom color palettes should be good to go. When a user selects the gray color for a text color option from Gutenberg’s color palette, the .has-gray-color class is added to the corresponding element, therefore setting the color attribute to #7a7a7a. And when the user views the page on the front end, the .has-gray-color color class is assigned to that element as well, instead of an inline style.
I like where Gutenberg is headed, and I appreciate the forward-thinking approach of using utility classes instead of forcing inline styling everywhere. Sure, it’s a bit more comprehensive for WordPress theme developers and Gutenberg block developers, though at the end of the day, color classes are much more sustainable — and cleaner.
Leave a Reply