WordPress.org

Make WordPress Core

Opened 7 months ago

#46498 new defect (bug)

Block style attribute issue, when using Custom properties/CSS variables

Reported by: olafklejnstrupjensen Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: General Keywords:
Focuses: ui, docs, administration, coding-standards Cc:
PR Number:

Description

First a little background on the issue

We use Custom properties, also referred to as CSS variables, when creating themes for our clients. This helps us define various color schemes quickly, for each new client and makes our development of new project much quicker.

In WP, we then add theme support for the editor-color-palette setting and add our CSS variables inside the array.

Example

<?php
add_theme_support(
        'editor-color-palette',
        [
                [
                        'name'  => 'color 1',
                        'color' => 'var(--color-1)',
                ],
                [
                        'name'  => 'color 2',
                        'color' => 'var(--color-2)',
                ],
        ]
);

This adds our color scheme to the various block elements, that use the PanelColorSettings, so that our clients can quickly access the colors in their color schemes.

The issue

This works great with admins and super admins, that have the unfiltered html capability, as they are allowed to add any inline style. However, if the user does not have that capability, then the css part is stripped, as part of the safe_style_css function. (https://core.trac.wordpress.org/browser/tags/5.1.1/src/wp-includes/kses.php#L2214)

For our setup, this is not very practical, as all of that functionality is hardcoded and we can not override it, except by giving all contributing user roles, the unfiltered html capability.

But a more unexpected issue is that if an admin with the unfiltered html capability authors a post and chooses a background color for a core paragraph block, the block gets the right style attributes, even with the CSS variable. Later on, a user without that capability adds a correction to that page. When the user save their changes, the style attribute containing the CSS variable, var(--color-1), gets that part stripped. However the block attribute is not removed and as it remains in the block attribute, the block displays correctly in the block editor. The next time an administrator with the unfiltered html capability edits the post, the core paragraph block creates a new paragraph and wraps the existing paragraph inside the new one, thus breaking the block in the block editor.

Fixes

There are a multiple ways of fixing this.

  1. We stop using CSS variables in our editor-color-palette array. However these CSS variable are part of modern web development and very practical.
  2. The block editor also strips attributes that are deemed unsafe in accordance with the users role and capabilites
  3. The safecss_filter_attr function gets another hardcoded exception for CSS variables, var(), that mimics the way the url() exception works.
  4. A hook is introduced in the safecss_filter_attr function allowing developers a chance to override the allowed style attribute values.

I would like to hear if others are affected by this issue and the opinions regarding the above practice and if there are suggestions for best practices for these cases.

I know that this issue is mainly related to the use of Gutenberg, however the safe_style_css that strips the CSS values is part of the core of WordPress, so I think this is more an issue for WordPress.

I am also in doubt if this qualifies as a bug, as the behaviour could be seen as expected behaviour, so some might see it as a feature request or enhancement, however the above example breaks the block editor and could then be seen as a bug.

Change History (0)

Note: See TracTickets for help on using tickets.