Low-contrast overlay when editing TEC events in block editor

Hi Dan,

Can you provide an admin login so we can check the issue in the editor?

Can you share your site’s login link and username?

Hi Dan,

Could you provide the full login URL? It seems we did not receive the reset email.

In WP 7.0, CSS added in the Customizer is automatically enqueued in the Block Editor.

That means any CSS intended only for the frontend may also be applied inside the editor. In this case, the background color issue you’re seeing in the editor is likely caused by Customizer CSS being applied there.

One workaround is to prevent that CSS from being enqueued in the editor by adding this PHP snippet:

add_filter( 'block_editor_settings_all', function ( $settings ) {
    if ( empty( $settings['styles'] ) || ! is_array( $settings['styles'] ) ) {
        return $settings;
    }
    $settings['styles'] = array_values(
        array_filter(
            $settings['styles'],
            static function ( $style ) {
                if ( ! is_array( $style ) ) {
                    return true;
                }
                return ! (
                    isset( $style['__unstableType'], $style['isGlobalStyles'] )
                    && 'user' === $style['__unstableType']
                    && false === $style['isGlobalStyles']
                );
            }
        )
    );
    return $settings;
}, 20 );

That should resolve the issue.

It’s related to the new Additional Custom CSS feature added to individual core blocks in WP 7.0:

https://make.wordpress.org/core/2026/03/15/custom-css-for-individual-block-instances-in-wordpress-7-0/

It looks like it may be absorbing the Customizer CSS, which does make sense.

And yes, tracking down which CSS in the Customizer is affecting the editor, then scoping it so it only applies on the frontend, is probably the better approach.

Because when you switch to other themes, the additional CSS field is empty.

Hi Dan,

The piece that explains the mismatch you’re seeing in DevTools is the alpha channel on that color: rgba(51,102,204,0.62). The 0.62 makes it semi-transparent, so whatever sits behind it shows through and blends. That’s why the rendered color never matches the literal value you inspect — DevTools shows you the rgba() value, but what you see on screen is that blue composited over whatever is behind it. There’s no hidden “scrim”; it’s the transparency doing the blending.

In WP 7.0 the editor canvas now inherits the Customizer body background, so that semi-transparent blue is being applied inside the editor. Your white fix for events works because the body there carries the tribe_events class, but it only covers events — regular posts and pages still get the blue, which is what you’re seeing on the non-event screen.

Two ways to clear it up:

1. The simplest is to set the body background to a solid color in the Customizer — drop the alpha. If you want that same blue, use #3366cc. A semi-transparent body background is what’s bleeding into the editor, so removing the transparency fixes it everywhere at once.
2. If you need the transparency on the frontend, broaden your editor override so it isn’t limited to events:

.editor-styles-wrapper {
    background-color: #ffffff !important;
}

That gives every post type a clean white editing canvas while leaving your frontend untouched. If you go this route, you can delete your existing .post-type-tribe_events .editor-styles-wrapper rule — this one covers events and everything else.

One small aside on that old rule: there’s a space between .post-type-tribe_events and .editor-styles-wrapper, which makes it a descendant selector (an .editor-styles-wrapper inside a .post-type-tribe_events element) rather than one element with both classes. It happens to match on the event screen because the editor body carries both classes, but it’s worth knowing in case you reuse the pattern elsewhere.

This is expected WP 7.0 behavior combined with the semi-transparent color, so no bug on our end.

Ok, Dan, let us know how it goes!