WordPress has_block Example: Detect Blocks Before Loading Assets

Last reviewed: April 29, 2026

Many themes and plugins load front-end assets on every page even when only one block actually needs them. has_block() is a practical way to detect block presence and keep scripts, styles, or conditional UI logic aligned with the content that is really on the page.

This guide shows how to use has_block() to load assets only when a given block exists in the current post content.

Conditionally enqueue block-specific CSS

<?php
add_action( 'wp_enqueue_scripts', 'vulnwp_enqueue_gallery_assets' );

function vulnwp_enqueue_gallery_assets() {
	if ( ! is_singular() ) {
		return;
	}

	if ( has_block( 'core/gallery', get_queried_object_id() ) ) {
		wp_enqueue_style(
			'vulnwp-gallery-enhancements',
			get_stylesheet_directory_uri() . '/assets/gallery.css',
			array(),
			null
		);
	}
}

This keeps archive pages and unrelated content from paying for gallery-specific CSS they never use.

Use the canonical block name

The function expects the full block name such as core/gallery or acf/faq. Passing a vague or shortened identifier makes detection fail quietly.

Prefer it for content-aware decisions, not permissions or business rules

has_block() is useful when the rendered content determines whether an asset or wrapper belongs on the page. It should not replace capability checks, route checks, or more formal feature toggles.

Keep the condition close to the asset or behavior it controls

Scattering unrelated block checks across the theme makes it harder to debug later. The block detection should live near the code it enables.

Production checklist

• Use the full block name in every check.
• Run the logic only in contexts where post content exists.
• Keep block-aware enqueues targeted to the asset they gate.
• Test pages where the block is absent, present once, and present multiple times.
• Do not confuse content detection with authorization or feature flags.
• Review conditional loads in performance testing after rollout.

Common mistakes

• Using a shortened block identifier. The check expects the full namespace/name format.
• Running block detection where no singular content is loaded. The condition becomes unreliable.
• Loading assets globally anyway. That defeats the purpose of the check.
• Turning content detection into business logic. Block presence is not an access-control mechanism.
• Forgetting custom blocks. Third-party or ACF blocks need their real registered names.

Related reading

If the block assets are registered through theme or plugin script loading, pair this with the wp_enqueue_script guide. If the block itself is custom, the block.json article is the next step.

References and further reading

• WordPress Code Reference: has_block()
• WordPress Code Reference: wp_enqueue_style()
• WordPress Block Editor Handbook: Core Blocks Reference