Update/theme support color palette

[webmandesign]

Description

Allowing editor-color-palette theme support setup with a single array of colors. This way only one argument is passed to add_theme_support( 'editor-color-palette', $arg ) instead of multiple arguments for each color.

Fising issue #6425

[samikeijonen]

Makes sense to me.

[gziolo]

It could be also:

add_theme_support( 'editor-color-palette', array(
	'strong magenta' => '#a156b4',
	'light grayish magenta' => '#d0a5db',
	...
) );

[webmandesign]

I've just added the array wrapper there because of @jorgefilipecosta's comment

[gziolo]

Can we map it to an ordered array before it gets exposed to JavaScript?

[webmandesign]

@gziolo
You mean like declaring the theme support with this:

array(
	'color_name_1' => '#color1',
	'color_name_2' => '#color2',
)

and then transform it in PHP to a JS required form of:

array(
	array(
		'name' => 'color_name_1',
		'color' => '#color1',
	),
	array(
		'name' => 'color_name_2',
		'color' => '#color2',
	),
)

?

If so, this is certainly doable. But I'd like some more input on this, more opinions (maybe from @jorgefilipecosta)? You see, current associated array implementation is more self-explanatory in my opinion and could actually serve well in case of future extending of the palette color features.

[gziolo]

Yep, that's what I meant. I don't care as much, I just wanted to make life of theme developers easier and help them save some keystrokes 😃

[jorgefilipecosta]

Hi,
Although I agree that it would be easier for themes to declare support using this syntax:

array(
	'color_name_1' => '#color1',
	'color_name_2' => '#color2',
)

I think it could limit future advances as the color value itself is a string and not an object we can expand.
For example, one possible improvement I was thinking about was to let themes define the contexts in which colors appear (e.g: allow some colors only for background).
In the current syntax, it is a matter of allowing an optimal property:

array(
	array(
		'name' => 'color_name_1',
		'color' => '#color1',
	),
	array(
		'name' => 'color_name_2',
		'color' => '#color2',
		'contexts': => array( 'background' ),
	),
)

[webmandesign]

Just like expected ;)

[jorgefilipecosta]

I think this may be breaking back compatibility with the existing version:

add_theme_support( 'editor-color-palette',
 	'#fff'
 	'#f00'
);

Maybe we should handle some condition to be backcompatible.

[webmandesign]

My question would be, is this required? Gutenberg is still in development and from what I can see the theme support declaration have already changed. (Though, I don't know if it was made backwards compatible.)

Also, is this backwards compatible too?:

add_theme_support( 'editor-color-palette',
	array(
		'name' => 'color_name_1',
		'color' => '#color1',
	),
	array(
		'name' => 'color_name_2',
		'color' => '#color2',
	)
);

If needed, I can surely, edit my code to incorporate backwards compatibility.

[samikeijonen]

In my opinion backwards compatible in this case is not required.

[jorgefilipecosta]

Hi all,
Thank you for sharing your thoughts, and for this contributions.
When changing colors mechanism, we always made efforts to try to be back-compatible in this case being back-compatible does not look very complicated. I think If we add this block:

	// Backcompat for Color Palette set as multiple parameters.
	if ( is_string( $color_palette ) || isset( $color_palette['color'] ) ) {
		$color_palette = get_theme_support( 'editor-color-palette' );
		wp_add_inline_script(
			'wp-edit-post',
			'console.warn( "' .
				__( 'Setting colors using multiple parameters is deprecated. Please pass a single parameter with an array of colors. See https://wordpress.org/gutenberg/handbook/extensibility/theme-support/ for details.', 'gutenberg' ) .
			'");'
		);
	}

Bellow `$color_palette = current( (array) get_theme_support( 'editor-color-palette' ) );``, it should work with both our old versions:

add_theme_support( 'editor-color-palette',
	array(
		'name => 'red'
		'color' => '#ff0',
	),
	array(
		'name => 'green'
		'color' => '#0f0',
	),
	array(
		'name => 'blue'
		'color' => '#00f',
	)
);

and

add_theme_support( 'editor-color-palette',
	'#f00',
	'#0f0',
	'#00f'
);

Would it be possible to rebase this branch so we can test with our latest changes, e.g., the mechanism to hide color palettes if we don't have colors to choose?

@mtias what are your thoughts? In your opinion, should we advance with this changes and set the color palette using a single array parameter instead of the current way (multiple parameters)?

[webmandesign]

@jorgefilipecosta Thank you for the code provided, I have updated my commits with it.

However, please note that this is the first GIT rebase I've ever done. Does feel like I've screwed something (judging by the number of commits). Please check and let me know. I might rather create a new branch again and redo changes for cleaner approach. Thanks!

[webmandesign]

Hi guys,
Just wanted to follow up on this. Wouldn't it be better if we close this PR and I will create a new one instead? This one seems to be messed up by all the code updates I think.

[webmandesign]

I've went ahead and created a new, mess-less pull request containing all the code discussed here. #7025
Closing this one so.