Make WordPress Core

Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#55188 closed defect (bug) (fixed)

Block styles should load after global styles in the editor

Reported by: oandregal's profile oandregal Owned by: jorgefilipecosta's profile jorgefilipecosta
Milestone: 5.9.1 Priority: normal
Severity: normal Version: 5.9
Component: Script Loader Keywords: has-patch commit
Focuses: Cc:

Description

Originally reported https://github.com/WordPress/gutenberg/issues/37839 by Andrew Staffell. Copied verbatim below:

In the editor, the style rules from theme.json are being inlined after those from add_editor_style(). This makes it difficult for a block style to override a default at the same level of specificity. As far as I can see you have to artificially increase the specificity, which makes it less flexible.

Step-by-step reproduction instructions

Here's a simple example.

I have a "No gap under" block style for groups so that several colour-background groups can be placed flush against each other, ie. overriding the default bottom margin.

theme.json

{
	"$schema": "https://schemas.wp.org/trunk/theme.json",
	"version": 2,
	"settings": {
	"styles": {
		"blocks": {
			"core/group": {
				"spacing": {
					"margin": {
						"bottom": "2rem"
					}
				}
			}
		}
	}
}

Block style definition

<?php
registerBlockStyle('core/group', {
	name: 'no-gap-under',
	label: 'No gap under',
});

add_editor_style() definition

.is-style-no-gap-under {
	margin-bottom: 0;
}

Result

The block style is ineffectual in the editor: because the theme.json rules are inlined after the editor styles, the block style (which should function as an override) doesn't work, and is overridden by the default instead. (It works fine in the front-end because the block styles are easily loaded after the inlined theme.json styles.)

.editor-styles-wrapper .wp-block-group {
  margin-bottom: 2rem;
}
.editor-styles-wrapper .has-blue-4-background-color {
  background-color: var(--wp--preset--color--blue-4) !important;
}
.editor-styles-wrapper .is-style-no-gap-under{
  margin-bottom: 0; /* not applied because it goes last*/
}

The element being inspected here is:

<div class="block-editor-block-list__block wp-container-0 is-selected wp-block-group is-style-no-gap-under block-editor-block-list__layout">

The first and last rules would ideally be in the opposite order, allowing easy overriding without having to add extra class or tag names to the rule to force it. I've tested just inverting the two corresponding <style> declarations by dragging them into the opposite order in Chrome Dev Tools, and putting the add_editor_style() rules below the theme.json rules instantly fixes the problem.

Change History (5)

This ticket was mentioned in PR #2139 on WordPress/wordpress-develop by oandregal.


2 years ago
#1

  • Keywords has-patch added

Fixes https://core.trac.wordpress.org/ticket/55188
Related Gutenberg PR https://github.com/WordPress/gutenberg/pull/37885

This follows what we do in the front-end, where theme styles are loaded after global styles by default.

## How to test

  • Use empty theme and apply the patch below via git apply <file.patch>:

<details>
<summary>Patch for empty theme</summary>
<p>

diff --git a/emptytheme/functions.php b/emptytheme/functions.php
index 5ee5593..a50baf4 100644
--- a/emptytheme/functions.php
+++ b/emptytheme/functions.php
@@ -6,8 +6,17 @@ if ( ! function_exists( 'emptytheme_support' ) ) :
 		// Adding support for core block visual styles.
 		add_theme_support( 'wp-block-styles' );
 
+		register_block_style(
+			'core/group',
+			array(
+				'name'  => 'background-color-hotpink',
+				'label' => 'BG Hotpink'
+			)
+		);
+
 		// Enqueue editor styles.
 		add_editor_style( 'style.css' );
+
 	}
 	add_action( 'after_setup_theme', 'emptytheme_support' );
 endif;
diff --git a/emptytheme/style.css b/emptytheme/style.css
index c10d92f..0dc53b7 100644
--- a/emptytheme/style.css
+++ b/emptytheme/style.css
@@ -14,3 +14,6 @@ Text Domain: emptytheme
 Emptytheme WordPress Theme, (C) 2021 WordPress.org
 Emptytheme is distributed under the terms of the GNU GPL.
 */
+.is-style-background-color-hotpink {
+    background-color: hotpink;
+}
\ No newline at end of file
diff --git a/emptytheme/theme.json b/emptytheme/theme.json
index 46b0979..1925b81 100644
--- a/emptytheme/theme.json
+++ b/emptytheme/theme.json
@@ -6,5 +6,14 @@
 			"contentSize": "840px",
 			"wideSize": "1100px"
 		}
+	},
+	"styles": {
+		"blocks": {
+			"core/group": {
+				"color": {
+					"background": "green"
+				}
+			}
+		}
 	}
 }

</p>
</details>

  • Go to the editor and create a group block. Verify background color of the block is green.
  • Go to the block sidebar and select the "BG Hotpink" style. Verify the background color of the block is now hotpink.

#2 @jorgefilipecosta
2 years ago

  • Keywords commit added
  • Milestone changed from Awaiting Review to 5.9.1

#3 @jorgefilipecosta
2 years ago

  • Owner set to jorgefilipecosta
  • Resolution set to fixed
  • Status changed from new to closed

In 52752:

Global Styles: Load the global styles before the theme styles in the editor.

This commit makes the site editor follow what we do in the front-end, where theme styles are loaded after global styles by default.

Props oandregal, ntsekouras.
Fixes #55188.

#4 @jorgefilipecosta
2 years ago

In 52753:

Global Styles: Load the global styles before the theme styles in the editor.

This commit makes the site editor follow what we do in the front-end, where theme styles are loaded after global styles by default.

Props oandregal, ntsekouras.
Merges [52752] to the 5.9 branch.
Fixes #55188.

oandregal commented on PR #2139:


2 years ago
#5

I see this has been commited to trunk and backported to 5.9. https://core.trac.wordpress.org/ticket/55188 is now closed, so I'm closing this one as well.

Note: See TracTickets for help on using tickets.