WordPress.org

Make WordPress Core

Opened 8 weeks ago

Last modified 9 hours ago

#53741 new defect (bug)

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

Reported by: mdahlke Owned by:
Milestone: 5.8.2 Priority: normal
Severity: normal Version: 5.8
Component: Script Loader Keywords: needs-testing close has-screenshots
Focuses: Cc:

Description

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">

Attachments (1)

Screen Shot 2021-07-22 at 9.35.38 AM.png (918.4 KB) - added by mdahlke 8 weeks ago.
Element that is affected by common.min.css with full path to file.

Download all attachments as: .zip

Change History (14)

@mdahlke
8 weeks ago

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

#1 follow-up: @sabernhardt
8 weeks ago

  • Keywords close 2nd-opinion added

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?

#2 in reply to: ↑ 1 @mdahlke
8 weeks ago

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

#3 @austinginder
8 weeks ago

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/.

#4 @sabernhardt
8 weeks ago

  • Component changed from General to Script Loader
  • Keywords needs-patch added; close 2nd-opinion removed
  • Milestone changed from Awaiting Review to 5.8.1

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.

#5 @peterwilsoncc
6 weeks ago

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.

#6 @sabernhardt
6 weeks ago

  • Keywords needs-testing added; needs-patch removed

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 noticed a case where one of these is on the front end (without a plugin).

Last edited 5 weeks ago by sabernhardt (previous) (diff)

#7 follow-up: @peterwilsoncc
6 weeks ago

  • Keywords close added
  • Severity changed from critical to normal

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.

This ticket was mentioned in Slack in #core-test by hellofromtonya. View the logs.


5 weeks ago

#9 in reply to: ↑ 7 @desrosj
3 weeks ago

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.

#10 @sabernhardt
2 weeks ago

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.

#11 @desrosj
2 weeks ago

  • Keywords has-screenshots added
  • Milestone changed from 5.8.1 to 5.8.2

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.

#12 @sabernhardt
8 days ago

#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

#13 @desrosj
9 hours ago

#54089 was marked as a duplicate.

Note: See TracTickets for help on using tickets.