Site Editor: restore block-library editor.css outside canvas

[ellatrix]

What?

In #66544 @t-hamano observed that a bit too many styles have been removed in #66432. Indeed, it should have kept loading editor.css files defined by blocks because they target both content and UI outside the canvas. The remaining styles should still be removed though.

One light problem is that all the styles we want to remove are added as dependencies of wp-edit-blocks. So restoring wp-edit-blocks will add back all the styles we don't want. To fix the issue we can register a separate handle wp-block-library-editor, which exclusively loads the editor styles.

Why?

Fix a regression from #66432.

How?

Testing Instructions

In content only mode, select an image and click the "alternative text" button in the toolbar.

Testing Instructions for Keyboard

Screenshots or screencast

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: ellatrix <[email protected]>
Co-authored-by: t-hamano <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[t-hamano]

This PR works for me.

My only concern is that deleting wp-edit-blocks or changing the handle name would be a breaking change. For example, block developers might apply their own styles to block sidebars, etc. with code like this:

wp_enqueue_style(
	'my-block-common',
	'path/to/block-common.css'
	array( 'wp-edit-blocks' )
);

I searched the WP Directory and it seems that a lot of plugins enqueue styles that depend on the wp-edit-blocks handle.

https://wpdirectory.net/search/01JBC821K2ZBFBMPF7QQSP7W8K

[ellatrix]

@t-hamano

1. Using wp-edit-blocks will still work. It's used in the canvas. So if you add dependencies to wp-edit-blocks, it should still work.
2. Blocks should never add wp-edit-blocks as a dependency. It should be the opposite: wp-edit-blocks should contain all the blocks' style sheets as dependencies.

[ellatrix]

What I mean is: nothing about wp-edit-blocks changes. It's all still there.

[t-hamano]

Using wp-edit-blocks will still work. It's used in the canvas.

If developers are adding a wp-edit-blocks handle to a dependency to enqueue a style outside of the canvas, the style won't be loaded outside of the canvas (root document), right?

Relying on wp-edit-blocks to apply styles outside of the canvas may not be a recommended use case, but I thought some dev notes might be needed.

[ellatrix]

@t-hamano I'm not sure I understand. Do you mean:

• Someone adds wp-edit-blocks as a dependency to their style? Even in trunk, this will not make it load outside the canvas.

Or:

• Someone adds their style as a dependency to wp-edit-blocks? Indeed, then the style will not load. But it's generally hard to to change the dependencies of a handle that you did not create (in this case wp-edit-blocks). How would this be done?

[t-hamano]

Sorry, maybe I misunderstood. I don't think this PR is a breaking change. Let me explain a bit more.

• In trunk, the style with a handle wp-edit-blocks is not loaded outside of the canvas.
• A third-party developer tries to apply a style outside of the canvas via code like this:

  function my_enqueue_block_editor_assets() {
    wp_enqueue_style(
  		'my-block-style',
  		plugin_dir_url( __FILE__ ) . 'style.css',
  		array( 'wp-edit-blocks' )
  	);
  }
  add_action( 'enqueue_block_editor_assets', 'my_enqueue_block_editor_assets' );

  • What I misunderstood: their style will be not loaded outside of the canvas.
  • Actual: Both the styles with the handle wp-edit-blocks and their styles are loaded outside of the canvas.

Is my understanding correct?

Also, if we go ahead with this PR, do we also need a backport PR to core?

[ellatrix]

@t-hamano Ah, in that case, this PR will not make any difference? Because merely adding wp-edit-blocks as a dependency does not cause it to load wherever wp-edit-blocks is enqueued? In other words removing wp-edit-blocks outside the canvas does not change anything for this code.

Yes, I'll add it to WordPress/wordpress-develop#7643 :)

[ellatrix]

In fact, it will actually undo the removal of this PR because the action is called outside the canvas: https://github.com/WordPress/wordpress-develop/blob/695476ea5e51d1c92f389ac236b138ceeaee8a99/src/wp-admin/site-editor.php#L177

[github-actions]

Flaky tests detected in 4c7d42e.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/11578911527
📝 Reported issues:

• [Flaky Test] should be able to create a new tag with ' on the name #38828 in /test/e2e/specs/editor/various/taxonomies.spec.js

[t-hamano]

Thank you for the detailed explanation.

I may not understand everything correctly, but if this PR does not affect backward compatibility, I think it's okay to ship it.

If this PR is shipped, will WordPress/wordpress-develop#7643 be updated?

[t-hamano]

BTW, should this PR be backported to Gutenberg 19.6? It looks like 19.6 RC1 is just about ready.

[ellatrix]

@t-hamano Yes, I'll update the core PR. Thank you for the review!

[ellatrix]

BTW, should this PR be backported to Gutenberg 19.6? It looks like 19.6 RC1 is just about ready.

I'll check with the person doing the release.

[cbravobernal]

I just cherry-picked this PR to the release/19.6 branch to get it included in the next release: 3736840

[Mamaduka]

I think this introduced the following warning in the editors.

Screenshot

[ellatrix]

@Mamaduka Ah, will fix

[ellatrix]

@Mamaduka Fixed in #66628.