Overlay color controls not toggleable in 6.1+

[snovosel-godaddy]

Description

In previous versions of WP the core color settings are disabled entirely based on the settings object being passed an empty color or gradient array. However, in versions 6.1+ , the color controls panel will still show (even with color controls disabled) for the overlay color. This same panel will not show if color settings are disabled for both background or text colors.

In the case where an empty palette is passed to the settings object, the panel is visible and an empty palette is present as shown in the below photo

Step-by-step reproduction instructions

Set the following settings in the editor:

    settings.colors = [];
    settings.gradients = [];
    settings.disableCustomColors = true;
    settings.disableCustomGradients = true;
    settings.__experimentalFeatures.appearanceTools = false;
    settings.__experimentalFeatures.color.defaultDuotone = false;
    settings.__experimentalFeatures.color.text = false;
    settings.__experimentalFeatures.color.background = false;
    settings.__experimentalFeatures.color.palette.default = [];
    settings.__experimentalFeatures.color.palette.theme = [];
    settings.__experimentalFeatures.color.gradients.default = [];
    settings.__experimentalFeatures.color.gradients.theme = [];

add core/cover block. notice that the color settings panel is still visible in the side bar, however the palette container shows an empty div.

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[Mamaduka]

I can confirm the issue.

Currently, there's no check if returned values from useMultipleOriginColorsAndGradients are truthy, and block-specific color panels are always rendered.

@aaronrobertshaw, I remember you worked on recent refactoring/unification of color panels. What do you think about returning the additional hasColorsOrGradients value from the hook and using it as a condition before rendering these panels?

[aaronrobertshaw]

Thanks for the ping 👍

I don't think we can apply a blanket rule to disable the Color panel if color supports have been disabled. As the panel is rendered via a SlotFill, it could be possible for a theme or plugin to disable the color supports but render their own custom controls into the Color panel.

The catch here with the Cover block is that the overlay and opacity controls are ad hoc controls added to the Color panel slot by Cover block. I've put together #50115 which will only render the overlay and opacity controls if there are colors.

Another contrived example to illustrate color related controls perhaps being desirable even without color support being enabled might be as follows:

• Theme author disables color support
• Sets a uniform overlay color on all Cover blocks
• Still wants to allow users to tweak the overlay's opacity

Screen.Recording.2023-04-27.at.2.55.23.pm.mp4

[Mamaduka]

Thanks for looking into this, @aaronrobertshaw.

I wasn't suggesting a blanket solution; I understand that each block's implementation is different.

My suggestion/plan:

• Return hasColors from useMultipleOriginColorsAndGradients; this will save us repeating checks in every block.
• Like in Cover: Only show overlay controls when color support enabled #50115, check this condition before rendering the custom color settings for Navigation, Featured Image, and Social Links blocks.

We don't have to update all blocks in a single PR, but having a unified way of handling checks would be nice.

Edit: I'll happily handle updates if this method looks good to you.

[aaronrobertshaw]

Thanks for the clarification, I misunderstood.

I can update the hook to return the additional flag. I also still need to update #50115 to fix the failing tests for the Cover block.