WordPress.org

Make WordPress Core

Opened 4 months ago

Last modified 4 weeks ago

#53741 new defect (bug)

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

Reported by: mdahlke Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 5.8
Component: Script Loader Keywords: needs-testing close has-screenshots needs-docs
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 4 months ago.
Element that is affected by common.min.css with full path to file.

Download all attachments as: .zip

Change History (15)

@mdahlke
4 months ago

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

#1 follow-up: @sabernhardt
4 months 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
4 months 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
4 months 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
4 months 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
4 months 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
4 months 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 4 months ago by sabernhardt (previous) (diff)

#7 follow-up: @peterwilsoncc
4 months 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.


4 months ago

#9 in reply to: ↑ 7 @desrosj
3 months 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
3 months 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
3 months 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
3 months 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
3 months ago

#54089 was marked as a duplicate.

#14 @circlecube
4 weeks ago

  • Keywords needs-docs added
  • Milestone changed from 5.8.2 to Future Release

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.

Note: See TracTickets for help on using tickets.