Block editor: iframe: add enqueue_block_assets
#49655
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Flaky tests detected in 4cb3181. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/4800287624
|
ellatrix
added
[Type] Plugin Interoperability
This was referenced Apr 7, 2023
ellatrix
force-pushed
the
fix/iframe-enqueuing
branch
from
22f3898
to
9b27075
Compare
ellatrix
force-pushed
the
fix/iframe-enqueuing
branch
from
9b27075
to
75ae529
Compare
ellatrix
removed
the
[Type] New API
|
Ok, I removed the api addition for now and we'll do it in a separate PR. |
|
Documenting what I've learned by looking at the current state of things at Mechanism to load assets via
How block.json and hooks compare to each other:
|
oandregal
reviewed
Apr 24, 2023
oandregal
reviewed
Apr 24, 2023
oandregal
reviewed
Apr 24, 2023
| $wp_scripts = $current_wp_scripts; | ||
|
|
||
| return array( | ||
| 'styles' => $styles, |
There was a problem hiding this comment.
Documenting how we fill this array in core:
styleswp-polyfill- for all registered blocks: the
$script_handles(scriptasset fromblock.jsonas well as any other registered by other means) - all the dependencies of the previous two items (automatically resolved by wp_scripts->do_items)
scriptswp-edit-blockswp-block-library-themeif theme supportswp-block-stylesbut hasn't provided anywp-widgetsandwp-edit-widgetsfor the widgets editor- for all registered blocks: the
$style_handlesand$editor_style_handles(styleandeditorStylesassets fromblock.jsonrespectively, as well as any other registered by other means) - all the dependencies of the previous items (automatically resolved by wp_styles->do_items
wp-reset-editor-styles: avoid enqueuing it in the iframe by adding it to the done queue, so it's ignored
There was a problem hiding this comment.
All of this should be covered, except the widgets stuff as the iframe is not being used there right now. wp-reset-editor-styles is not added.
There was a problem hiding this comment.
I've looked at the assets loaded in the iframe for the post editor using the TwentyTwentyThree theme.
Extra things this PR has that are not present in trunk:
- The assets added via
enqueue_block_assets. This is correct. I've used this test plugin:enqueue_block_assets_style_bodyis for styles without a.wp-blockclassenqueue_block_assets_style_wp_blockis for styles with.wp-blockclass
- The inline styles for emojis, which are not present in trunk. Are these necessary?
Things this PR misses that are present in trunk:
wp-reusable-blocks. I'm a bit surprised about this. It should have been present because it's a dependency ofwp-edit-blocks, which is enqueued. The same issue happens withwp-componentsand we had to declare it as a dependency ofwp-block-editor-contentfor it to be enqueued. It sounds like all dependencies ofwp-edit-blocksare missing. Any ideas why would this happen? 🤔wp-fonts-local. It sounds like these are fonts defined by the theme.
| Post Editor Assets | Trunk | This PR |
|---|---|---|
html.height.auto, body.margin.0 (inline) |
x | x |
img.wp-smiley, img.emoji (inline) |
x | |
dashicons-css |
x | x |
wp-components-css |
x | x |
wp-block-editor-content-css |
x | x |
wp-block-library-css |
x | x |
wp-edit-blocks-css |
x | x |
wp-reusable-blocks-css |
x | |
wp-fonts-local (inline) |
x | |
enqueue_block_assets_style_body-css |
x | |
enqueue_block_assets_style_wp_block-css |
x | x |
enqueue_block_editor_assets_style_wp_block-css |
x | x |
wp-inert-polyfill-js |
x | x |
enqueue_block_assets_script_console-js |
x | |
enqueue_block_assets_wp_api-js |
x | |
wp-polyfill-inert-js |
x | x |
regenerator-runtime-js |
x | x |
wp-polyfill-js |
x | x |
There was a problem hiding this comment.
wp-reusable-blocks is not there because wp-edit-blocks is added through the compat layer. We need to change wp-edit-blocks in a follow up PR so it's not added anymore. wp-reusable-blocks does not contain any styles relevant to the editor content.
wp-fonts-local this is not present in core either. Looks like these are added in the 6.2, but not added to WP core. I don't know why. Since they are not present in core I don't think it's a big deal (see lib/compat/wordpress-6.2/script-loader.php)
There was a problem hiding this comment.
wp-reusable-blocks is not there because wp-edit-blocks is added through the compat layer.
I just checked and that's correct! It can be iterated in a follow-up.
img.wp-smiley, img.emoji (inline)
This is also enqueued in the front, so it's expected.
enqueue_block_assets_style_body-css, enqueue_block_assets_script_console-js, enqueue_block_assets_wp_api-js
What we aimed to get with this PR.
ellatrix
force-pushed
the
fix/iframe-enqueuing
branch
from
62b0103
to
e81da56
Compare
|
Size Change: +2.74 kB (0%) Total Size: 1.37 MB
ℹ️ View Unchanged
|
This was referenced May 3, 2023
arthur791004
reviewed
May 5, 2023
|
|
||
| ob_start(); | ||
| wp_print_styles(); | ||
| wp_print_fonts(); |
There was a problem hiding this comment.
There is an issue using wp_print_fonts since it will do nothing if the handles are empty.
Before, Gutenberg assigned the registered fonts to the queue so $wp_fonts can fallback to the handles in the queue. However, this function doesn't implement that mechanism and it leads to the font styles won't be printed
For example,
- Activate TT3 on your site
- Go to the site editor
- Select Styles > Typography > Text
- Try different fonts, e.g. Arvo, Bodoni Moda
- The selected font is not affected
There was a problem hiding this comment.
@hellofromtonya Is this fixed now since [Fonts API] Relocate which fonts to print from script-loader into wp_print_fonts()? Thanks for looking into it!
There was a problem hiding this comment.
Is this fixed now since #49655 (comment)? Thanks for looking into it!
@ellatrix Yes, it is fixed via PR #49655. That change was cherry-picked for 15.7.1, which will be released today.
mcsf
reviewed
May 9, 2023
| /** | ||
| * Collect the block editor assets that need to be loaded into the editor's iframe. | ||
| * | ||
| * @since 6.0.0 |
There was a problem hiding this comment.
This would be replacing the core function, which was introduced in 6.0.0?
|
@tyxla Could you open a new issue with the steps to reproduce? I opened the site editor and didn't see any errors. |
This is why the PR introduced |
This must have been something unrelated since I'm unable to reproduce it anymore. Will open a new issue if it comes up again. Thanks, Ella! |
|
@ellatrix I noticed that using |
14 tasks
24 tasks
|
@ellatrix @oandregal Does this need a 6.3 backport PR? If not, we should move it to Thanks! |
|
@CreativeDive I'll look into it! |
This was referenced Jul 6, 2023
|
@CreativeDive Btw, this was fixed in #52405. |
This was referenced Aug 17, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
Should be able to fix: #41821, #44945.
Enqueues styles and scripts added though the
enqueue_block_assetsaction (which is for editor and front-end assets1).Introduces another actionenqueue_block_editor_content_assetsfor cases where we want to enqueue scripts/styles for the (iframed) editor content, but not for the front-end.Why?
We need more ways to enqueue scripts and styles. Currently there’s 3 ways to add styles: block.json (for blocks), add_editor_style (for themes) and block editor settings (CSS as a string, which is not easy to use). Scripts can only be added through block.json.
It makes sense to enqueue assets loaded on the front-end in the editor content (iframe) too.
In addition, we need a way to add assets for the editor content (iframe), but without enqueuing on the front-end. We currently have an unstable way of doing this in Gutenberg. This PR adds theenqueue_block_editor_content_assetsso there's an official way of doing it. For example, we need this action for adding content styles in the block editor package, and thewp-componentsdependency.Another good thing is that this simplifies the
_wp_get_iframed_editor_assetsfunction.How?
To put it another way: we are currently hardcoding a bunch of dependency handles in_wp_get_iframed_editor_assets, which can be replaced by callingdo_action( 'enqueue_block_assets' )anddo_action( 'enqueue_block_editor_content_assets' ).Testing Instructions
There should be no missing styles in the editor content (iframe).
Testing Instructions for Keyboard
n/a
Screenshots or screencast