Archived topic
Add theme support editor-color-palette
26 replies · Started by Simone on November 4, 2019
Great. GP is my crush!
Meeting GP, was what made me decide to leave another cms behind after 15 years and move to Wordpress.
(and with Generateblock and WP Show Post even better)
Thats great to hear - thanks for the feedback - really appreciated!
All of this has stopped working. This is the code I have in my theme, and it no longer works. GP's bad default colors are the only ones available in the block editor and Customizer. Do I need to downgrade?
/* Custom color palette */
add_filter( 'generate_default_color_palettes', 'brkthru_custom_colors' );
function brkthru_custom_colors( $palettes ) {
$palettes = array(
'#ffffff', // white
'#000000', // black
'#3f9ffd', // blue
'#2191ff', // dark blue
'#dbedff', // light blue
'#f4efe9', // tan
'#d6d6d6', // gray
'#dfdfdf', // gray 2
);
return $palettes;
}
add_action( 'after_setup_theme', 'brkthru_block_colors' );
function brkthru_block_colors() {
add_theme_support( 'disable-custom-colors' );
add_theme_support( 'editor-color-palette', array(
array(
'name' => __( 'White', 'brkthru' ),
'slug' => 'white',
'color' => '#ffffff',
),
array(
'name' => __( 'Black', 'brkthru' ),
'slug' => 'black',
'color' => '#000000',
),
array(
'name' => __( 'Blue', 'brkthru' ),
'slug' => 'blue',
'color' => '#3f9ffd',
),
array(
'name' => __( 'Dark Blue', 'brkthru' ),
'slug' => 'dark-blue',
'color' => '#2191ff',
),
array(
'name' => __( 'Light Blue', 'brkthru' ),
'slug' => 'light-blue',
'color' => '#dbedff',
),
array(
'name' => __( 'Tan', 'brkthru' ),
'slug' => 'tan',
'color' => '#f4efe9',
),
array(
'name' => __( 'Gray', 'brkthru' ),
'slug' => 'gray',
'color' => '#d6d6d6',
),
array(
'name' => __( 'Gray 2', 'brkthru' ),
'slug' => 'gray2',
'color' => '#dfdfdf',
),
) );
}
Hi Greg,
You can keep the latest version, we just need to bump the priority of the hooks.
Example:
On this line on your code,
add_filter( 'generate_default_color_palettes', 'brkthru_custom_colors' );
Try changing it to this: add_filter( 'generate_default_color_palettes', 'brkthru_custom_colors', 99 );
And on this line:
add_action( 'after_setup_theme', 'brkthru_block_colors' );
Try changing it to this:
add_action( 'after_setup_theme', 'brkthru_block_colors', 99 );
Ok. It does not override the colors in Customizer > Colors > Global Colors, but it does override them in Customizer color selects and the block editor. Thanks!
Hi there,
with the new Global Colors you don't require the PHP any more.
As you can now edit the Global Color palette in the Customizer, and any of those colors are available in the editor.
It of course works best when building a new site as an existing site may require some updating to use the new global colors
with the new Global Colors you don’t require the PHP any more.
As you can now edit the Global Color palette in the Customizer, and any of those colors are available in the editor
But I want to use PHP. I want the colors specified in code, and I don't want to have to set them manually. How can I get this to work again? I have the brand colors set in code, but they don't appear anywhere in Customizer—not as Global Colors, and not in the color picker.
Per your current documentation (https://docs.generatepress.com/article/generate_default_color_palettes/) and the suggestion from Elvin to run it late:
add_filter( 'generate_default_color_palettes', function( $palettes ) {
$palettes = array(
'#33658A', // dk blue headings/header
'#4E7C9F', // lt blue headings/footer
'#5AB1BB', // lt green
'#757575', // body text
'#343434', // dk text
'#000000', // black
'#ffffff', // white
'#eeeeee', // off white
);
return $palettes;
}, 99 );
You can use the generate_option_defaults filter and the global_colors array.
See here fore an example:
So generate_option_defaults is undocumented, and the current documentation for generate_default_color_palettes is wrong?
I would say that is a reasonable observation.
I will pass it on to the team for them to add docs for this.
Did the above links work for you ?
I'm concerned that this functionality, too, might be removed in an update. If documented features are removed while the docs remain, it seems prudent not to use undocumented features, which are even less solid.
We do need to update those docs.
But i would not be concerned of it changing in the future. Those filters are here to stay.