Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FSE script into iframe insertion needs to be less restrictive on how it determines whether to include a stylesheet #42509

Closed
albanyacademy opened this issue Jul 18, 2022 · 6 comments
Labels
[Feature] Blocks Overall functionality of blocks Needs Technical Feedback Needs testing from a developer perspective. [Package] Block editor /packages/block-editor [Type] Enhancement A suggestion for improvement.

Comments

@albanyacademy
Copy link

albanyacademy commented Jul 18, 2022

Description

In the Site Editor, Block CSS should be included without needing to use wp-block as a CSS selector in the built stylesheet, it should be included in the iframe by virtue of it being registered through enqueue_block_assets.

My suggestion would be to add to enqueue_block_assets a data-attr/some "block asset" identifier to just scan for instead, because whether or not the right selectors are in the stylesheet shouldn't be the sole criteria for including it in the FSE.

Step-by-step reproduction instructions

  1. Build a bunch of blocks with separate editor and generic stylesheets
  2. Don't use ".wp-block" as the main classname/selector for your custom blocks.
  3. Go into FSE and use your custom blocks
  4. Observe that their styles are not included inside the iframe.

Screenshots, screen recording, code snippet

Specifically this section:
https://github.com/WordPress/gutenberg/blob/0a6a23b213c4fe9e3b337c8b71fa87bbf82c4496/packages/block-editor/src/components/iframe/index.js

function matchFromRules( _cssRules ) {
				return Array.from( _cssRules ).find(
					( {
						selectorText,
						conditionText,
						cssRules: __cssRules,
					} ) => {
						// If the rule is conditional then it will not have selector text.
						// Recurse into child CSS ruleset to determine selector eligibility.
						if ( conditionText ) {
							return matchFromRules( __cssRules );
						}

						return (
							selectorText &&
							( selectorText.includes(
								`.${ BODY_CLASS_NAME }`
							) ||
								selectorText.includes( `.${ BLOCK_PREFIX }` ) )
						);
					}
				);
			}

			const isMatch = matchFromRules( cssRules );

Environment info

No response

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

@kathrynwp kathrynwp added [Type] Enhancement A suggestion for improvement. [Feature] Blocks Overall functionality of blocks [Package] Block editor /packages/block-editor Needs Technical Feedback Needs testing from a developer perspective. labels Jul 19, 2022
@albanyacademy
Copy link
Author

Just want to clarify, the exact problem I was experiencing is also the result of my naming of the stylesheets themselves.
the inline section here https://github.com/WordPress/gutenberg/blob/trunk/packages/block-editor/src/components/iframe/index.js#L107 seems to be doing a simple find-replace for "css" within the stylesheet ID, which breaks when you include "css" somewhere in the enqueue handle yourself. so inline stylesheets i was adding weren't showing up either.

either way you can't progress to that specific bug without including wp-block in your main stylesheet somewhere (i've just slapped it in with a dummy variable) ala:
.wp-block {--nothing: none}

this pretty much circumvents the problem above, and not naming your enqueued assets with "css" somewhere in there also helps.

@albanyacademy
Copy link
Author

Update: this is also failing to load custom third party stylesheets, like Google fonts or Typekit. Kinda pressing.

@spacedragn
Copy link

spacedragn commented Jan 19, 2023

Same here. Adobe Fonts/Typekit renders properly on the front-end. But the Block Editor ignores the enqueued CSS file across all browsers (Mac), and Network Inspector confirms no font files are loading.

This plugin loads Typekit via API, which temporarily solved my issue. You can also load Typekit via JS as a potential workaround.

@ellatrix
Copy link
Member

Hi!

The wp-block selector detection is a back compatibility script, in case the stylesheets are not added to the iframe correctly.

We've done lots of work in WP 6.3 to make sure that there are always ways to add stylesheets to the iframe without the compatibility script. Since #49655, you can use the enqueue_block_assets to enqueue assets for the iframe, so your problem should be fixed. Also see this dev note for more information: https://make.wordpress.org/core/2023/07/18/miscellaneous-editor-changes-in-wordpress-6-3/#post-editor-iframed

@spacedragn
Copy link

Thanks for clarifying here. Switched to enqueue_block_assets and can confirm the desired assets are loading in the Site Editor as expected. This includes Adobe Fonts/Typekit CSS files.

@albanyacademy
Copy link
Author

YESSS thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Blocks Overall functionality of blocks Needs Technical Feedback Needs testing from a developer perspective. [Package] Block editor /packages/block-editor [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

No branches or pull requests

4 participants