WordPress editor assets do not all belong in the same place. Interface code for the editor chrome, content styles for the canvas, frontend block styles, dynamic CSS, and block metadata each have different loading contracts. The always-iframed Post Editor in WordPress 7.1 makes a wrong hook much easier to see.
Use this for plugin and theme developers debugging missing editor CSS, styles that leak into wp-admin, frontend-only scripts, duplicate bundles, flashes of unstyled content, or dynamic block styles that disappear in the iframe.
Quick answer
Use `enqueue_block_editor_assets` for editor interface assets. Use `enqueue_block_assets` for assets that style or support block content in both the editor and frontend. Use block metadata and `wp_enqueue_block_style` when ownership is block-specific. For dynamic content styles, add approved CSS through block editor settings. Verify the actual iframe head, outer document, and frontend separately.
What to check first
- List each stylesheet and script with its owner, intended document, required screens, dependencies, version, and whether the public page also needs it.
- Inspect the outer admin head, editor iframe head, and public page head instead of assuming an enqueue call reached every target.
- Move content-facing block assets to `enqueue_block_assets` or block metadata, while keeping sidebar, toolbar, and inspector interface code in `enqueue_block_editor_assets`.
- Test dynamic CSS and design tokens after post load, block insertion, pattern insertion, Global Styles changes, and editor navigation.
- Compare asset request counts and content hashes to catch duplicate bundles, stale cache, missing dependency versions, or a frontend file loaded twice.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Classify every asset | List each stylesheet and script with its owner, intended document, required screens, dependencies, version, and whether the public page also needs it. | The editor iframe contains every required content stylesheet and no unrelated full-site bundle. |
| Inspect all three documents | Inspect the outer admin head, editor iframe head, and public page head instead of assuming an enqueue call reached every target. | The outer admin contains editor interface assets without broad rules that restyle unrelated WordPress controls. |
| Move assets to owned hooks | Move content-facing block assets to `enqueue_block_assets` or block metadata, while keeping sidebar, toolbar, and inspector interface code in `enqueue_block_editor_assets`. | The public page loads the approved block assets once and renders the same fixture without relying on logged-in admin CSS. |
| Test dynamic insertion | Test dynamic CSS and design tokens after post load, block insertion, pattern insertion, Global Styles changes, and editor navigation. | Cache-enabled and cache-bypass tests return the same approved asset versions and no stale combined file. |
Why this usually happens
- A legacy plugin treats all editor styles as admin styles and enqueues them only in the outer document.
- A theme loads a frontend bundle in the iframe but its selectors depend on a body class that exists only on the public page.
- Dynamic styles are printed during an early request and never injected when the editor state changes.
- A CDN or optimization plugin combines files under a cache key that does not vary by WordPress build or editor context.
Field notes
- Record URL, handle, dependency list, response status, response hash, owning document, and winning CSS rule for each tested asset.
- Test a logged-in editor with cache bypass and then with normal production optimization. Both paths matter.
- Check `wp.domReady`, module loading, translations, and dependency globals when a script request succeeds but execution still fails.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
add_action( 'enqueue_block_assets', function () {
wp_enqueue_style(
'acme-block-content',
plugins_url( 'build/content.css', __FILE__ ),
array(),
'2026.08.03'
);
} );
add_action( 'enqueue_block_editor_assets', function () {
wp_enqueue_script( 'acme-editor-sidebar' );
} );
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Classify every asset
- Inspect all three documents
- Move assets to owned hooks
- Test dynamic insertion
- Validate optimized production delivery
Decision rule
A content asset passes only when the iframe and frontend receive the intended version, the outer admin does not receive unwanted content styling, dependencies execute in order, and the block remains correct after dynamic insertion and navigation.
What to tell the client or owner
Share the handle, URL, version, dependency list, intended document, actual document, response hash, winning selector, WordPress build, and a screenshot of the failing component.
Production verification checklist
- The editor iframe contains every required content stylesheet and no unrelated full-site bundle.
- The outer admin contains editor interface assets without broad rules that restyle unrelated WordPress controls.
- The public page loads the approved block assets once and renders the same fixture without relying on logged-in admin CSS.
- Cache-enabled and cache-bypass tests return the same approved asset versions and no stale combined file.
Mistakes to avoid
- Do not solve a missing iframe style by enqueueing an entire theme bundle into wp-admin.
- Do not use request success alone as proof that CSS won the cascade or JavaScript executed.
- Do not omit versions from assets that are cached by a CDN or optimization plugin.
- Do not inline user-controlled values into CSS without validation and escaping.
Questions teams ask during testing
Which hook is for block content in the editor and frontend?
The official guide points to `enqueue_block_assets` for block content assets that should reach both contexts.
Which hook is for an inspector sidebar?
Use the editor interface asset path, commonly `enqueue_block_editor_assets`, because the control belongs to editor chrome.
Can a theme editor stylesheet still work?
Yes, but verify its selectors and delivery in the iframe. Legacy assumptions about the admin document may still break it.
When HandL WP should help
HandL WP can map every block asset to its owning document, fix hook placement, compare editor and frontend CSS, and verify CDN and optimization behavior during a WordPress 7.1 rollout.
If this is active on a production site, audit WordPress editor asset loading.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Test the next browser isolation boundary
WordPress 7.1 developer pages now include runnable Code Reference examples. Use the WordPress runnable Code Reference isolation test to inspect iframe origin, parent access, storage, network requests, workers, and reset behavior before copying the pattern into internal documentation.
Related fixes to check next
WordPress 7.1.1 RC1: Prepare a Plugin and Theme Test: The announced RC1 schedule is September 10. Prepare the baseline now, verify actual availability, and test the candidate without treating it as a final release.
Helpful references