Site Editor: Remove styles reset as script dependency

[creativecoder]

Description

Prevent loading the editor styles reset in the Site Editor.

Related to #33204. Removes the reset from wp-edit-blocks dependencies when the site editor loads, for better compatibility with asset concatenation plugins (for example, https://wordpress.org/plugins/page-optimize/).

Fixes a problem when some Global styles settings do not appear to work in the editor with such plugins because wp-reset-editor-styles is concatenated and and then loaded in the Site Editor iframe with along with all concatenated scripts.

How has this been tested?

• With a block based theme activated, load the site editor
• Verify that wp-reset-editor-styles is not loaded, by searching the page markup for the stylesheet id (wp-reset-editor-styles-css) and/or checking to make sure the styles are not applied to .editor-styles-wrapper within the iframe
• Also load the post editor to make sure the styles reset continues to load there

Screenshots

Types of changes

Update to existing feature

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• I've tested my changes with keyboard and screen readers.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.
• I've updated all React Native files affected by any refactorings/renamings in this PR (please manually search all *.native.js files for terms that need renaming or removal).

[jeyip]

Hmmm...I had trouble getting this working to test.

Whenever I activate the page-optimize plugin to try and confirm the stylesheet concatenation bug, everything borks (with or without this branch applied). Did you do anything special to test this locally @creativecoder?

[jeyip]

Can we get rid of the patch here as well?

gutenberg/packages/block-editor/src/components/iframe/index.js

Lines 58 to 63 in 17898a2

	// Don't try to add the reset styles, which were removed as a dependency
	// from `edit-blocks` for the iframe since we don't need to reset admin
	// styles.
	if ( ownerNode.id === 'wp-reset-editor-styles-css' ) {
	return;
	}

[youknowriad]

I think @ellatrix has an alternative PR for this. Basically, that dependency need to be removed whenever the editor is rendered in an iframe because the "reset" is only needed to reset WP-Admin styles in the editor canvas, and since iframe styles are sandboxes, that's not needed.

[creativecoder]

Can we get rid of the patch here as well? (

gutenberg/packages/block-editor/src/components/iframe/index.js

Lines 58 to 63 in 17898a2

	// Don't try to add the reset styles, which were removed as a dependency
	// from `edit-blocks` for the iframe since we don't need to reset admin
	// styles.
	if ( ownerNode.id === 'wp-reset-editor-styles-css' ) {
	return;
	}

)

@jeyip We probably could, though I left it alone thinking it would be good to keep as a fallback, in case wp-reset-editor-styles is re-introduced as a dependency by a plugin.

[creativecoder]

FYI I've updated the PR description to explain the reason for this change a little better (mainly better compatibility with asset concatenation plugins).

[ellatrix]

Are the common and forms stylesheets still omitted from the iframe?

[jeyip]

Testing

Requirements

• Verify that wp-reset-editor-styles is not loaded, by searching the edit site page markup for the stylesheet id
• Verify that wp-reset-editor-styles is loaded, by searching the post editor page markup for the stylesheet id

Browsers

• Chrome

Notes

• I'll test and see if common and forms stylesheets are still omitted. I can confirm that I don't see forms-cssor common-css style <link /> tags in the iframe head element with this branch applied.

[jeyip]

Friendly ping @ellatrix. Curious if you have further thoughts on this approach.

[ellatrix]

• I can confirm that I don't see forms-cssor common-css style <link /> tags in the iframe head element with this branch applied.

If I read the code correctly, the dependency is only removed from the site editor and not from the template editor (page editor => and then edit the template). This template editor is also iframed. Additionally all previews will be iframed soon for the post editor, and at some point the post editor itself.

[creativecoder]

@ellatrix Thanks for the feedback!

I've modified the PR to keep asset loading as is for the Template editor, but additionally remove wp-reset-editor-styles as a dependency when loading the Site editor. This prevents the problem with Global styles settings not appearing to not work when the styles reset is concatenated and inadvertently loaded into the Site Editor iframe.

I don't see a way to do the same dependency manipulation for the Template editor because of how it's loaded dynamically inside the Post editor... but I'd anticipate this will eventually resolve itself if/when the Post editor is iframed.