wp-admin/css/common.min.css is loading on the front-end

[mdahlke]

The stylesheet wp-admin/css/common.min.css is loading on the front-end. This is overriding styles on the front-end of the site with admin styling.

<link rel="stylesheet" id="forms-css" href="​https://www.domain.com/wp-admin/css/forms.min.css?ver=5.8" type="text/css" media="all">

[mdahlke]

Element that is affected by common.min.css with full path to file.

[sabernhardt]

Hi @mdahlke and welcome to WordPress Core Trac!

I do not see either the 'common' or 'forms' stylesheets on the front end. I checked your site (Home and Recipes pages, without logging in of course), and the styles are not added there. These stylesheets also do not show on the front end when I'm logged in to my local installation.

Could you try deactivating plugins and/or switching themes temporarily to see if one of those enqueues an admin stylesheet?

[mdahlke]

Replying to sabernhardt:

Hi @mdahlke and welcome to WordPress Core Trac!

I do not see either the 'common' or 'forms' stylesheets on the front end. I checked your site (Home and Recipes pages, without logging in of course), and the styles are not added there. These stylesheets also do not show on the front end when I'm logged in to my local installation.

Could you try deactivating plugins and/or switching themes temporarily to see if one of those enqueues an admin stylesheet?

We have dequeued the common styles using:

<?php
if (!is_admin()) {
    function five_dequeue_common_css() {
        wp_deregister_style('common');
    }
    add_action( 'wp_enqueue_scripts', 'five_dequeue_common_css');
}

Here's another person that is suffering from this issue as well:
​https://wordpress.org/support/topic/problems-with-common-min-css-in-5-8/#post-14690274

[austinginder]

Ran into the same issue when upgrading to WordPress 5.8 for a customer. For my site I've isolated the bug to be coming from a plugin called Helpie FAQ. I've reported this as a bug to the plugin author: ​https://wordpress.org/support/topic/wordpress-5-8-compatibility-issue/.

[sabernhardt]

Thanks for mentioning the plugin!

This seems related to changeset:50761. Helpie FAQ gets the common and forms styles on the front end by setting 'wp-edit-blocks' as a dependency of one of their stylesheets. The 'wp-edit-blocks' stylesheet lists dependencies including 'wp-reset-editor-styles', which calls both 'common' and 'forms'.

Moving to 5.8.1 to investigate what changes can and should be made.

[peterwilsoncc]

Just so I am clear, is common.css, etc being enqueued as a dependecy of wp-block-library or wp-block-editor?

If it's the former, wp-block-library, then I see it as a WordPress bug as common.css are admin styles and the library css is intended for the front end.

If it's a dependency of the latter, wp-block-editor, then I see this issue as a theme or plugin bug as they're admin styles that aren't intended to be used on the front end of a site. It's very risky to do so as these styles are intended to change as new markup is added to the dashboard.

[sabernhardt]

Apparently wp-edit-blocks, wp-reset-editor-styles and/or common.css are not dependencies of either wp-block-library or wp-block-editor.

The wp-edit-blocks style adds wp-reset-editor-styles (and therefore common.css) in the following admin contexts: edit-post, edit-widgets, and customize-widgets. Plus the wp_add_iframed_editor_assets_html function lists wp-edit-blocks. However, I have not seen a case where one of these is on the front end.

[peterwilsoncc]

Thanks @sabernhardt -- especially for reading between the lines as I confused names ;)

I'm lowering the severity of this as it seems the issue only occurs if styles intended for the block editor are loaded on the front-end.

As wp-edit-blocks is only intended to be used within the dashboard, I am tempted to close this ticket without a fix. The admin CSS can't be made compatible with themes and plugins on the front-end as it's not possible to avoid selector collisions when the CSS is used out of context.

[desrosj]

Replying to peterwilsoncc:

As wp-edit-blocks is only intended to be used within the dashboard, I am tempted to close this ticket without a fix. The admin CSS can't be made compatible with themes and plugins on the front-end as it's not possible to avoid selector collisions when the CSS is used out of context.

I do tend to agree with this. It's been about a month since 5.8 was released, and there have been no other reports, so I think this is a _doing_it_wrong for that specific plugin.

I did notice that customize-widgets lists wp-edit-blocks as a dependency, though. Wondering if this could potentially cause a similar problem.

@sabernhardt do you know if there is documentation anywhere that details wp-edit-blocks being intended only for admin use? I may be missing something obvious, but I couldn't actually find where the wp-edit-blocks styles are compiled from.

[sabernhardt]

The wp-edit-blocks dependencies are defined in script-loader.php and the stylesheet itself is compiled from ​block-library/src/editor.scss.

For documentation, I only found a ​documentation example suggesting wp-edit-blocks as a dependency on an admin page, which does not specifically discourage other uses. The existing wp- prefix on wp-edit-blocks and wp-reset-editor-styles might be enough to signify that these styles are subject to change.

With the customize-widgets dependencies, the common.css styles could affect content within the Customizer panel (as much as it would change in the block-based Widgets editor), but that does not alter the preview.

[desrosj]

5.8.1 RC is due out in less than 24 hours. Since we're still trying to determine the best way forward here, I'm going to punt this.

[sabernhardt]

#54089 mentions uses in YARPP and WooCommerce.

There's a long list of plugins that mention and probably enqueue the 'wp-edit-blocks' styles for some purpose, whether that should be expected on the front end or not.
​https://wpdirectory.net/search/01FF40FRFMEJAZP4AY1VK0P13Z

[desrosj]

#54089 was marked as a duplicate.

[circlecube]

Since there's no working patch yet and with 5.8.2 RC due out soon, I'm going to punt this to a future release.

It's loading because a plugin or theme is defining a package as a dependency which is only used on the back-end everywhere else, but we don't really give a best practice recommendation on how to not be doing_it_wrong. Defining a best practice would solve this though I believe.