Skip to content

Ensure compat WP 7+ : enqueue assets for shared blocks - #17

Open
julesfell wants to merge 1 commit into
developfrom
compat-wp7
Open

Ensure compat WP 7+ : enqueue assets for shared blocks#17
julesfell wants to merge 1 commit into
developfrom
compat-wp7

Conversation

@julesfell

@julesfell julesfell commented Jul 29, 2026

Copy link
Copy Markdown

Note

Medium Risk
Runs on every full shared-block render and may enqueue extra assets site-wide for matching block classes; behavior is additive to existing dependency enqueuing.

Overview
When a shared block is rendered in full display mode, the consumer page now runs enqueue_embedded_block_assets() on the remote HTML before the existing dependency logic.

That helper walks all registered block types, detects which appear in the markup via their wp-block-* class names, and enqueues style_handles, view_script_handles, and view_script_module_ids—covering front-end styles and interactivity assets that the older use_block_types path only partially addressed via legacy script / style handles.

Reviewed by Cursor Bugbot for commit 11c6a3c. Bugbot is set up for automated code reviews on this repo. Configure here.

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes using default effort and found 2 potential issues.

Fix All in Cursor

❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.

Reviewed by Cursor Bugbot for commit 11c6a3c. Configure here.


// When displaying full content, just return the rendered content.
if ( 'full' === $display ) {
$this->enqueue_embedded_block_assets( $block_data['html'] );

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Skip dependencies filter bypassed

Medium Severity

enqueue_embedded_block_assets runs before multisite_shared_block_skip_block_dependencies is applied, so assets are always enqueued even when that filter returns true. The existing dependency path still honors the filter, so behavior is now inconsistent and the documented opt-out no longer fully works.

Fix in Cursor Fix in Web

Reviewed by Cursor Bugbot for commit 11c6a3c. Configure here.


if ( ! str_contains( $html, $block_class ) ) {
continue;
}

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unreliable HTML block detection

Medium Severity

Block presence is inferred with str_contains on generated wp-block-* class names instead of the accurate use_block_types list already returned by the renderer. Substring matches cause false positives such as wp-block-column inside wp-block-columns, and blocks without the default classname are missed, so view scripts or styles may not load.

Additional Locations (1)
Fix in Cursor Fix in Web

Reviewed by Cursor Bugbot for commit 11c6a3c. Configure here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant