Pattern creator: stop block styles leaking into the editor's outer page#749
Merged
Merged
Conversation
enqueue_block_frontend_styles_for_canvas() (added in #740) enqueues every registered block's frontend style on enqueue_block_assets so they are captured into the iframe canvas. That action also fires on the outer creator page's normal front-end render, where it printed every block stylesheet into <head>. The outer shell renders no blocks, so those styles were pure leakage — and Gutenberg's iframe onLoad cloned each one into the canvas, logging a "<handle> was added to the iframe incorrectly" warning per style (the wporg-* and jetpack-* handles seen in the console; core wp-* styles are exempted). Gate the enqueue to the iframed-asset capture only. Core brackets that capture's enqueue_block_assets dispatch with a should_load_block_editor_scripts_and_styles => __return_false filter, so its presence distinguishes the capture from the outer render. Verified in wp-env: post-fix the style is no longer enqueued on the outer page (no warning) but is still enqueued during the capture (canvas styles preserved, no #740 regression). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
This PR prevents block frontend styles enqueued for the pattern creator’s iframe canvas from also being enqueued on the outer creator page, eliminating Gutenberg “added to the iframe incorrectly” console warnings caused by style leakage.
Changes:
- Adds a runtime gate so
enqueue_block_frontend_styles_for_canvas()runs only during core’s_wp_get_iframed_editor_assets()capture context. - Expands the function’s docblock to explain why the gating is necessary and how the capture context is detected.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
This file contains hidden or 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
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.
Problem
The pattern creator logs a cluster of console warnings in the editor canvas:
…for
wporg-pattern-preview-style,wporg-post-status-style,wporg-copy-button-style,wporg-delete-button-style, plus dependency block styles surfaced through the same path (wporg-ratings-*,wporg-site-breadcrumbs,wporg-link-wrapper,wporg-language-suggest,jetpack-sharing-buttons,wporg-global-header-footer).Root cause
enqueue_block_frontend_styles_for_canvas()(added in #740) hooksenqueue_block_assetsand enqueues every registered block's frontend style so they're captured into the iframe canvas — which core's_wp_get_iframed_editor_assets()doesn't do forstyle_handles, onlyeditor_style_handles.But
enqueue_block_assetsfires twice on a creator request:wp_head()— unwanted. The outer shell renders no blocks, yet every block stylesheet was printed into<head>. Gutenberg's iframeonLoad→getCompatibilityStyles()then clones each head style whose id doesn't start withwp-and whose CSS contains.wp-blockinto the canvas, logging one warning per style. (Thatwp-exemption is why onlywporg-*/jetpack-*handles appear, and why dependency block names showed up — our loop is what enqueued them on the outer page.)Fix
Gate the enqueue to the capture context only. Core brackets its capture dispatch with
add_filter( 'should_load_block_editor_scripts_and_styles', '__return_false' ), so its presence distinguishes the capture from the outer render:Verification (wp-env)
Integration-tested both branches of the gate against a real registered block style:
<head>(warning source)So the warnings are eliminated without regressing #740's canvas-styles fix.
Not addressed (not this repo)
The other console messages on the page originate from dependencies, not our code: the JQMIGRATE notice (jQuery Migrate), the
'root','media'canUserdeprecation (@wordpress/core-data), and the__unstableUseRichTextdeprecation (@wordpress/block-editor).🤖 Generated with Claude Code