WordPress allowed_block_types_all Example: Restrict Editor Blocks Safely

Last reviewed: April 30, 2026

The block editor becomes noisy fast when every post type exposes every block, especially on sites with strict editorial workflows. The allowed_block_types_all filter is the clean way to narrow the inserter for a specific editing context without unregistering blocks globally.

This guide shows how to restrict allowed blocks for one post type while leaving the rest of the editor experience untouched.

Scope the restriction to a real editor context

<?php
add_filter( 'allowed_block_types_all', 'vulnwp_limit_post_blocks', 10, 2 );

function vulnwp_limit_post_blocks( $allowed_blocks, $editor_context ) {
	if ( empty( $editor_context->post ) || 'post' !== $editor_context->post->post_type ) {
		return $allowed_blocks;
	}

	return array(
		'core/paragraph',
		'core/heading',
		'core/list',
		'core/image',
		'core/quote',
	);
}

The key here is not the array itself. It is the guard clause that avoids applying the restriction to unrelated editors.

Return the incoming default when you are not restricting

The filter accepts either true or an array of block slugs. If a request is outside the targeted post type or editor state, return the incoming value instead of forcing a global rule.

Be careful around site editor and template contexts

The WordPress Developer Blog explicitly warns that aggressive block restrictions can break template editing flows. Production code should scope the filter to content types that truly need editorial constraints.

Keep the allowlist short and intentional

If authors only need five block types for a press-release post type, give them five. A vague half-restriction usually creates the worst of both worlds: editorial confusion without real consistency.

Production checklist

• Check the editor context before returning a restricted array.
• Limit blocks only for post types with a defined editorial model.
• Return the original value for unrelated editors.
• Test the Site Editor and template editing after rollout.
• Document the exact allowlist for editorial teams.
• Review plugin-provided block slugs before finalizing the rule set.

Common mistakes

• Applying one allowlist everywhere. Template editors and post editors do not always need the same rules.
• Forgetting editor context checks. That is how block restrictions leak into the wrong screens.
• Returning a hardcoded boolean for all cases. That overrides more than intended.
• Allowlisting blocks by guesswork. Use real registered slugs.
• Restricting before the editorial workflow is defined. Rules should follow content operations, not precede them.

Related reading

If the goal is visual consistency rather than block removal, use the register_block_style guide. If the block itself is custom and controlled through metadata, continue with the block.json article.

References and further reading

• WordPress Code Reference: allowed_block_types_all
• WordPress Developer Blog: How to Disable Specific Blocks
• WordPress Block Editor Handbook: Core Blocks Reference