2

After the automatic update to wordpress 5.8 today one of my custom themes displayed wrong styling in the frontend for custom webfonts, colors, font-sizes and other styles. After a quick check in the dev tools I realized that this is caused by common.min.css an automatically generated collection of core styles that hasn't been present in Wordpress 5.7.2 (I quickly reverted the live site from 5.8 to 5.7.2). On localhost I kept the updated (5.8) version to find a solution for the problem. If I deactivate common.min.css in the browser's dev tools everything looks fine again.

Is there a way to deregister this core style on frontend? I have tried to get my grips on deactivating unnecessary styles for hours and days in the past but haven't been successful so far – to be honest.

I have found some possibly related information in this recent wordpress.org blog post: https://make.wordpress.org/core/2021/07/01/block-styles-loading-enhancements-in-wordpress-5-8/#respond but I am not 100 % sure if this relates to my problem and even if so I haven't found a solution in the post.

Ari mentions in the post that block styles (which I suppose are combined into common.min.css) are loaded in the footer using print_late_styles() and that for classic, php-based themes (which my theme is – in contrast to the new block themes) this causes conflicts with the priority of the styles / stylesheets load order.

Any help or advise really appreciated as I need to find a quick solution (and maybe others are facing the same problem?)

3
  • 1
    Short update: after a conversation with Ari (Stathopoulos), the writer of the aforementioned blog post on wordpress.org my problem is unrelated to what is described in the post. The common.min.css I am refering to is an wp-admin css enqueued in the header and "leaking" into my frontend.
    – Vortac
    Jul 21 '21 at 17:07
  • Did you ever figure this out? I think I am having the same issue now.
    – Jared
    Nov 29 '21 at 21:52
  • 1
    In the end it was a problem with my (self-written) custom blocks plugin. Wrapping the wp_enqueue_style function (to enqueue a custom editor.css file in the plugin's main PHP file) in an is_admin() check helped (it actually removed a ton of unnecessary css). If you have a similar setup you can get back to me if this isn't clear. Sorry for late answer.
    – Vortac
    Dec 10 '21 at 9:35

Browse other questions tagged or ask your own question.