You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Warn when editor-only block assets are enqueued via enqueue_block_assets #1360
I've seen some plugins enqueue Gutenberg/block editor scripts via the enqueue_block_assets hook even though the scripts in question are only needed in the block editor and should be enqueued via enqueue_block_editor_assets. One example I remember is this changeset in plugin trac (line 12-14)
This can cause editor-related scripts, including their dependencies, to be loaded on the frontend as well, hurting page speed.
I have seen this in multiple plugins. I think it's because either AI coding agents just get this wrong, or the hook names themselves are easy to confuse.
A check could help by detecting assets enqueued via enqueue_block_assets that depend on editor-only scripts. If a script depends on packages such as wp-block-editor, or similar editor-specific dependencies, it is likely not meant to be loaded on the frontend.
The approach I took was to add a runtime check that inspects scripts loaded on the frontend and warns when a plugin script depends on known editor-only packages such as wp-block-editor, wp-editor, wp-edit-post, or wp-edit-site, which may indicate that the assets were enqueued via enqueue_block_assets instead of enqueue_block_editor_assets.
The check reports each script only once to avoid duplicate warnings across URLs. I’ve also added positive and negative test fixtures along with PHPUnit coverage.
Using a runtime check like this will run in the context of a user being authenticated, no? There could potentially be editor-only dependencies loaded on the frontend for the sake of frontend editing or even using the block editor in comments (as seen on the forums). So I'm not sure this is going to be always reliable as some scripts may be intentionally enqueued.
@westonruter Thank you, that's a good point. My assumption was that since the check only inspects scripts that actually end up being loaded while traversing frontend URLs, it would be a reasonable signal for catching assets unintentionally exposed via enqueue_block_assets.
Activity
ishitaj34 commentedon Jun 18, 2026
Opened a PR for this.
The approach I took was to add a runtime check that inspects scripts loaded on the frontend and warns when a plugin script depends on known editor-only packages such as
wp-block-editor,wp-editor,wp-edit-post, orwp-edit-site, which may indicate that the assets were enqueued viaenqueue_block_assetsinstead ofenqueue_block_editor_assets.The check reports each script only once to avoid duplicate warnings across URLs. I’ve also added positive and negative test fixtures along with PHPUnit coverage.
westonruter commentedon Jun 18, 2026
Using a runtime check like this will run in the context of a user being authenticated, no? There could potentially be editor-only dependencies loaded on the frontend for the sake of frontend editing or even using the block editor in comments (as seen on the forums). So I'm not sure this is going to be always reliable as some scripts may be intentionally enqueued.
Related: #526
ishitaj34 commentedon Jun 19, 2026
@westonruter Thank you, that's a good point. My assumption was that since the check only inspects scripts that actually end up being loaded while traversing frontend URLs, it would be a reasonable signal for catching assets unintentionally exposed via
enqueue_block_assets.