--- title: "How to Allow Different Blocks by Post Type" date: 2026-01-25 author: "Imtiaz Rayhan" featured_image: "https://wpblocksuite.com/wp-content/uploads/2026/08/featured-allow-blocks-by-post-type.png" categories: - name: "Block Editor" url: "/blog/category/block-editor.md" --- # How to Allow Different Blocks by Post Type Use the `allowed_block_types_all` filter to allow different blocks by post type. Read the current post from its editor context. Return an approved array for matching types. Keep the incoming value for contexts without a post. Preserve stricter upstream restrictions. Test templates, patterns, existing content, imports, and every supported custom type. This rule changes editor insertion choices. It does not remove saved blocks. It also does not replace capabilities or server-side content validation. ## A safe post-type block map ``` function acme_blocks_by_post_type( $allowed, $context ) { if ( empty( $context->post ) ) { return $allowed; } $map = array( 'post' => array( 'core/paragraph', 'core/heading', 'core/list', 'core/image', 'core/quote', ), 'page' => array( 'core/paragraph', 'core/heading', 'core/image', 'core/group', 'core/columns', 'core/buttons', ), ); $post_type = $context->post->post_type; if ( ! isset( $map[ $post_type ] ) ) { return $allowed; } if ( is_array( $allowed ) ) { return array_values( array_intersect( $allowed, $map[ $post_type ] ) ); } return false === $allowed ? false : $map[ $post_type ]; } add_filter( 'allowed_block_types_all', 'acme_blocks_by_post_type', 20, 2 ); ``` This example keeps non-post editors unchanged. It intersects existing arrays with local rules. A prior false value remains false. ## Why post types need different block sets Post types represent different content models. Blog posts need editorial blocks. Product records may need specifications and pricing. Team profiles may need only structured fields. A universal inserter exposes irrelevant choices everywhere. Editors can create inconsistent structures. Focused lists reduce accidental design and content drift. Restrictions should support the content model, not fight it. If every page needs exceptions, the map is wrong. Review editorial tasks before writing code. ## The filter receives more than a post type `allowed_block_types_all` runs for multiple editor contexts. Its second parameter is a `WP_Block_Editor_Context` object. A post is not always present. The Site Editor, widgets, and specialised screens can call the filter differently. Accessing `$context->post` without checking can produce errors or unintended restrictions. The [official hook reference](https://developer.wordpress.org/reference/hooks/allowed_block_types_all/) documents accepted values and context. Code against the supported WordPress baseline. ## Keep non-post contexts unchanged Return the incoming value when no post exists. This avoids applying post rules inside Site Editor templates or widget screens accidentally. If those contexts need curation, add explicit branches later. Give each branch its own tests and owner. Avoid one broad default. Context shapes can evolve. Defensive checks protect compatibility. Logging context during staging diagnostics can reveal unexpected editor surfaces. ## Preserve earlier restrictions The incoming `$allowed` value may already be true, false, or an array. Another plugin, theme, or site policy could have filtered it. Returning your map blindly can re-enable disallowed blocks. Keep false unchanged. Intersect incoming arrays with your post-type array. True means no earlier restriction. Your mapped array can then become the local allow list. Document the chosen filter priority. ## Use full registered block names Allow-list entries use names like `core/paragraph` and `acme/notice`. Display titles are unsuitable. They can change, translate, or collide. Inspect block metadata or registry output when uncertain. Core serialized comments omit their namespace, but filter arrays use full registered names. A misspelled name simply stays unavailable. Validate every configured name against the active registry. Report missing providers during deployment checks. ## Prefer an explicit configuration map A central map makes differences reviewable. Each post type receives one named list. Shared foundations can be composed to reduce duplication. ``` $writing_blocks = array( 'core/paragraph', 'core/heading', 'core/list', 'core/image', ); $map['post'] = array_merge( $writing_blocks, array( 'core/quote' ) ); ``` Remove duplicates after composition. Keep ordering stable for readable diffs. Explain every specialised addition beside the map or in documentation. ## Choose allow lists or deny lists deliberately An allow list hides future blocks until review. This supports strict content models. It requires maintenance after WordPress and plugin updates. A deny list allows future registrations automatically. It suits flexible editorial environments. New duplicate or unsuitable blocks can appear unexpectedly. The server filter directly accepts allowed arrays. Building deny behaviour requires obtaining registered names and subtracting exclusions. Keep that logic tested. ## Account for parent and child block relationships Some blocks only make sense inside specific parents. Others provide required child components. An incomplete list can break an otherwise approved feature. Navigation, Query, Columns, and Comment structures can use related children. Test complete insertion and editing flows. Do not judge names individually. Metadata can declare parent, ancestor, and allowed-child relationships. Review those definitions when adding structural blocks. Keep required companions available. ## Templates can contain blocks outside the list A post template can provide blocks editors cannot insert directly. Existing template structure may still render. Editing permissions and content-only roles affect interaction. Test every assigned template with the relevant post type. Open new and existing records. Confirm required fields remain selectable and editable. A restrictive allow list can hide recovery options for broken templates. Keep administrator workflows broader where needed. Document the emergency path. ## Patterns need compatible block sets Starter and theme patterns can contain blocks missing from a post-type list. Their visibility or insertion can change. Test every promoted pattern. Do not show patterns that fail after insertion. Either expand the approved block set or provide compatible alternatives. Pattern design should reflect actual policy. Synced patterns can appear across several post types. Their nested blocks may exceed one type’s list. Shared content needs cross-context acceptance tests. ## Existing saved blocks remain Changing allowed insertion does not rewrite `post_content`. Existing blocks stay serialized. They may remain editable because their type remains registered. Do not confuse an allow list with a migration. If a retired block must disappear, inventory and replace it separately. Preserve revisions and [rollback](https://wpblocksuite.com/blog/roll-back-wordpress-plugin-update/). Open representative existing records after enabling the filter. Check toolbar controls, saving, validation, and frontend output. Test deeply nested cases. ## Post-type rules do not replace roles Every user editing one post type receives the same mapped list by default. Administrators and authors may need different choices. That requires another policy dimension. A role check can narrow the list further. It should preserve post-type ownership. Our role-based block access guide covers that combination next. The mechanics are in [WordPress block access by user role](https://wpblocksuite.com/blog/wordpress-block-access-by-user-role/). Block availability is still not a security boundary. Use capabilities and server validation for protected actions. Editor lists guide workflows. ## Imported content can bypass insertion workflows REST clients, imports, and [database migrations](https://wpblocksuite.com/blog/wordpress-plugin-database-migrations/) can create content without using the inserter. An allowed list does not necessarily sanitize submitted block markup. Validate imports separately when policy requires it. Rejecting unknown blocks can destroy useful content. Quarantine and review often provides a safer path. Record provenance for migrated records. A future editor should know why unavailable blocks exist. Then plan replacement without rushed conversion. ## Custom post types need editor support A custom post type must support the editor for block curation to matter. Registration settings and REST support affect its editing experience. Confirm the type actually uses block content. Some custom types rely entirely on structured fields. Exposing an empty inserter there solves nothing. Coordinate with the type’s owning plugin. Updates can change templates or required blocks. Your map should not silently fight provider assumptions. ## Multisite maps need clear ownership Sites within a network can register different post types and plugins. A network-wide map may reference unavailable blocks. Validate each site registry. Define network defaults and site exceptions. Keep configuration traceable. One site’s marketing pages may need blocks forbidden on another site. Test network administrators and ordinary site users. Network activation can change block availability everywhere. Review maps after shared plugin updates. ## Put policy in a site-owned plugin Post-type block policy belongs to the site’s content architecture. A small managed plugin often owns it better than a presentation theme. Theme switching should not expose unsuitable content tools unexpectedly. Version-control the map. Review changes and deploy them through staging. Provider plugins can supply sensible defaults for their own types. Site code can narrow them. Document which layer owns the final decision. The full walkthrough is in [WordPress plugins vs code snippets](https://wpblocksuite.com/blog/wordpress-plugins-vs-code-snippets/). ## Example block sets by content model A news post may need text, media, quotes, embeds, and approved calls. A landing page may need layout, buttons, and branded sections. An event record may use a locked template with only Paragraph and Image edits. Product content might need tables, lists, galleries, and commerce blocks. These examples describe tasks, not universal lists. Interview content owners. Observe real editing before finalising each map. ## Understand true, false, and empty arrays Returning true permits all registered blocks. Returning false permits none. An empty array also exposes no named block types. False can express an earlier absolute restriction. Preserve that signal. Do not replace it with your local array unintentionally. A no-block editor may still display template content. Test saving carefully. Usually, a focused non-empty list creates the most useful workflow. ## Filter priority is part of policy WordPress runs filters by priority and registration order. A later callback receives earlier decisions. Your chosen priority affects composition with other rules. Do not pick a very late priority merely to win. Cooperative intersection is safer. Identify conflicting callbacks and agree on ownership. Log effective lists during staging diagnostics. Remove verbose logging before production. Document the final priority beside the configuration. ## Classic Editor screens are different Post types using the Classic Editor do not expose the block inserter normally. An allowed-block map cannot simplify an interface that is absent. Mixed sites can use blocks for some types and classic editing elsewhere. Confirm each type’s actual editor. Avoid unnecessary filter branches. Legacy content may still contain [block comments](https://wpblocksuite.com/blog/wordpress-block-markup-comments/) after editor changes. Do not infer storage format from the current editing screen alone. ## Post type may be too broad One Page post type can contain landing pages, legal pages, contact pages, and documentation. Their ideal block choices may differ substantially. Templates can provide another reliable signal. Taxonomy or metadata can also describe workflow. Additional branches increase complexity and testing cost. Prefer templates and locked structures before deeply conditional lists. They communicate intended composition more clearly. Use conditions only for stable editorial distinctions. ## Automate registry and map checks A test can compare configured names against registered block types. Missing names may signal deactivated providers or renamed blocks. Fail deployment when critical entries disappear. Snapshot effective lists for representative contexts. Review intentional diffs after updates. Avoid snapshots hiding broader behaviour changes. Browser tests should open each post type and inspect the inserter. Add template insertion, transforms, patterns, and historical records. Code-level tests cannot replace editor behaviour. ## Use editor feedback as maintenance evidence Repeated requests for one hidden block indicate a missing task. Repeated misuse of an allowed block may indicate a training or model problem. Record exceptions and their outcomes. Add blocks when they solve verified work. Remove blocks when another approved tool owns the same job. Review maps quarterly and after provider changes. A static list becomes stale. Content models and editorial responsibilities evolve. ## Test a matrix, not one editor DimensionRequired samplesCheck Post typeEvery supported typeCorrect approved list Record stateNew and historicalInsertion and existing editing TemplateEach assigned templateRequired blocks remain usable UserAdministrator and editorExpected workflow access Add patterns, transforms, paste, and imports to every relevant row.## A rollout checklist 1. Inventory post types using the block editor. 2. Document each type’s editorial tasks. 3. List full registered block names. 4. Build shared foundations and explicit maps. 5. Preserve false and intersect upstream arrays. 6. Keep non-post contexts unchanged. 7. Include required parent and child blocks. 8. Test templates and promoted patterns. 9. Open historical content containing restricted blocks. 10. Test paste, transforms, and imports. 11. Deploy through a site-owned code path. 12. Provide a documented rollback flag. 13. Review after WordPress and plugin updates. Ask editors to complete real tasks during staging acceptance. A technically accurate list can still omit necessary work. Adjust the model before production. ## Frequently asked questions How do I allow blocks by post type in WordPress? Filter `allowed_block_types_all`, read the context post type, and return its approved block names. What should I return when no post exists? Return the incoming value unless you intentionally own that separate editor context. Do post-type block lists remove existing blocks? No. They govern editor availability. Saved content remains until separately migrated or removed. Should I preserve another plugin’s allowed-block list? Yes. Keep false values and intersect existing arrays with your local post-type policy. Are post-type block rules a security feature? No. They guide editing. Capabilities and server validation must protect sensitive actions and data. ## The verdict Verdict **Map the content model:** each post type gets tools serving its real editorial tasks. **Code defensively:** preserve upstream rules, unrelated contexts, templates, and historical content. Focused post-type lists make specialist plugins easier to govern. They can still become too strict. Try WP Block Suite’s free blocks first. Then [compare the $299 lifetime suite](https://wpblocksuite.com/#pricing) when approved Pro blocks serve several content models.