--- title: "WordPress Block Access by User Role" date: 2026-01-26 author: "Imtiaz Rayhan" featured_image: "https://wpblocksuite.com/wp-content/uploads/2026/08/featured-wordpress-block-access-by-user-role.png" categories: - name: "Block Editor" url: "/blog/category/block-editor.md" --- # WordPress Block Access by User Role WordPress can show different block choices according to a user’s capabilities. Filter `allowed_block_types_all` and check capabilities with `current_user_can()`. Prefer capabilities over hard-coded role names. Role-aware block lists guide editorial workflows. They do not secure block output or server actions. Sensitive operations still need authentication, capability checks, validation, and escaping. Combine user rules with post-type and context rules carefully. Preserve earlier restrictions. Existing saved blocks remain until separately migrated. ## A capability-aware block filter ``` function acme_role_aware_blocks( $allowed, $context ) { if ( empty( $context->post ) ) { return $allowed; } $basic = array( 'core/paragraph', 'core/heading', 'core/list', 'core/image', ); $advanced = array( 'core/group', 'core/columns', 'core/buttons', 'acme/notice', ); $local = current_user_can( 'use_advanced_blocks' ) ? array_merge( $basic, $advanced ) : $basic; if ( false === $allowed ) { return false; } return is_array( $allowed ) ? array_values( array_intersect( $allowed, $local ) ) : $local; } add_filter( 'allowed_block_types_all', 'acme_role_aware_blocks', 30, 2 ); ``` This example uses a custom capability. It keeps unrelated editor contexts unchanged. It also respects stricter earlier allow lists. ## Roles and capabilities are different A role is a named collection of capabilities. Users can hold customised capabilities beyond their role. Plugins can also add roles and change capability maps. Checking a role name assumes a fixed site structure. Checking a capability asks the useful question directly. WordPress documentation discourages role checks inside `current_user_can()`. The [official function reference](https://developer.wordpress.org/reference/functions/current_user_can/) supports capabilities and object identifiers. Use meta capabilities when access depends on a particular post. ## Create a capability matching the editorial decision Generic capabilities like `edit_posts` may be too broad. Many ordinary authors already have them. A custom capability can express advanced block access clearly. - `use_advanced_blocks` can expose layout tools. - `manage_campaign_blocks` can expose promotional components. - `edit_structured_tables` can expose specialised data blocks. Name capabilities around responsibilities, not job titles. Roles can then receive them as needed. This survives organisational changes more cleanly. ## Add capabilities during controlled lifecycle events Role changes persist in the database. Repeatedly adding them on every request wastes work. Plugins commonly add capabilities during activation or migrations. Removing a plugin raises an ownership decision. Should custom capabilities remain for another component? Define [uninstall behaviour](https://wpblocksuite.com/blog/uninstall-wordpress-plugin-cleanly/) deliberately and document it. The [Roles and Capabilities guide](https://developer.wordpress.org/plugins/users/roles-and-capabilities/) covers adding roles and capabilities. Test upgrades from every supported plugin version. ## Combine post type and capability rules A product editor may need advanced product blocks but no landing-page layouts. A page designer needs the opposite. One role list cannot model both contexts. Build the post-type list first. Then narrow or expand according to approved capabilities. Keep the combination deterministic and documented. Our [post-type guide](https://wpblocksuite.com/blog/allow-blocks-by-post-type/) provides safe context checks and list intersection. Reuse that foundation rather than duplicating competing filters. ## Preserve incoming restrictions Another component may already return false or a restricted array. Your capability rule should not re-enable blocks accidentally. Preserve false and intersect arrays. Filter priority determines which decision arrives first. Cooperative logic matters more than winning. Record ownership and effective priority. Log effective lists only during staging diagnostics. User-specific lists can reveal internal policy. Remove verbose logs before production. ## Block lists are not authorization The inserter is one client interface. REST requests, imports, pasted markup, and custom clients can bypass it. Saved block content can arrive elsewhere. Therefore, hiding a payment block does not protect payments. The rendering callback must check permissions. Any state-changing endpoint must enforce its own capabilities. Follow least privilege throughout the application. The [official Users guide](https://developer.wordpress.org/plugins/users/) recommends granting only essential privileges. Editor curation supports that principle without replacing it. ## Use object-aware checks when required A user may edit one post but not another. Meta capabilities can evaluate a specific object. Pass the post identifier where the capability expects it. Generic list building often uses stable custom capabilities. Object-aware branches add complexity. Use them only for verified workflows requiring per-record differences. Test ownership changes, private records, scheduled content, and delegated editing. Capability mapping can vary by post status and author. ## Existing blocks need a separate policy A user may open content containing a block absent from their insertion list. Registration usually remains. Editing behaviour depends on block and template controls. Decide whether users may edit, move, duplicate, or remove those instances. Block locking and [content-only editing](https://wpblocksuite.com/blog/content-only-editing-wordpress/) can shape that workflow more precisely. Do not unregister the block merely to prevent insertion. Unregistration can make existing content unavailable inside the editor. Server allow lists are gentler. ## Templates can provide broader structures safely A restricted editor can work inside a prebuilt template containing advanced blocks. They edit approved content fields without inserting the surrounding structure themselves. Content-only editing and locks can protect layout. Role-aware insertion lists then reduce unrelated choices. These layers solve different responsibilities. Test template creation, editing, saving, and recovery for every role. An administrator preview cannot prove an author workflow. ## Patterns can be an approved access path A pattern can insert a controlled arrangement of advanced blocks. Direct insertion may remain unavailable. This lets users apply approved compositions without building them. Test whether restrictions allow the pattern and its nested blocks. Behaviour can differ across contexts. Do not promote patterns users cannot complete. Synced pattern editing deserves stronger capability checks. One change can reach many pages. Separate insertion access from shared-source modification. ## Personal hiding remains separate A user can hide allowed blocks through Preferences. Their personal list may become smaller than the role list. That is normal. Resetting Preferences restores only choices permitted by enforced rules. It cannot override capability restrictions. Explain this distinction during training. ## Avoid caching one user’s list for another Capability-aware output varies by user. A shared cache key can leak broader or narrower lists. WordPress editor settings should remain request-specific. If custom caching exists, include every relevant policy dimension. User capability sets, post type, site, and context can matter. Invalidation also matters. Avoid caching unless measurement proves a need. List intersection is cheap. Incorrect access guidance costs far more than the saved computation. ## Multisite adds network capabilities Super administrators have broad network authority. Site administrators can have different capabilities. Network-active plugins can register blocks across every site. Check capabilities within the current site context. Use site-specific functions when evaluating another site. Test network and site administrators separately. A shared role name can carry different meaning after customisation. Capability checks remain the more reliable contract. Document network defaults and exceptions. ## Design a role-and-block matrix ResponsibilityBlock accessSeparate permission WriterText and approved mediaPublish or submit DesignerLayout and visual componentsEdit shared design Campaign managerPromotional componentsManage campaign data AdministratorRecovery and full registryManage configuration Block visibility guides work; capabilities still authorize the actual action.## Frontend visibility is a separate feature Some blocks can hide rendered content by visitor role or login state. That concerns viewers. Editor block access concerns authors and builders. Do not reuse one rule for both audiences automatically. A writer may configure member content without being a member. Responsibilities and visibility differ. Server rendering must enforce visitor visibility securely. CSS hiding is insufficient for private information. Search engines and assistive technology may still receive hidden markup. ## Shared editing needs escalation paths A restricted writer will occasionally need an advanced component. Define a request and approval path. Do not encourage shared administrator accounts. An authorised editor can insert the component into an approved template or pattern. The writer can then update allowed content fields. Ownership remains visible. Record temporary capability grants with expiry and purpose. Remove them after the task. Permanent access should follow recurring responsibilities. ## Emergency access should remain narrow Recovery work may require broader block access. Create a documented emergency role or capability grant. Keep ordinary publishing permissions unchanged where possible. Log who granted access, why, and when it ended. Use individual accounts. Review affected content after emergency changes. A global bypass flag can help during incidents. Protect it with strong capabilities. Test its rollback before any production emergency. ## Audit role and capability drift Plugins can add capabilities during updates. Administrators can customise roles manually. Over time, the effective permission model can diverge from documentation. Export role capabilities periodically and compare expected values. Investigate unexpected additions and removals. Do not overwrite legitimate local changes without review. Include inactive roles and individual user grants. A one-off exception can outlive its purpose. Remove stale access deliberately. ## Custom blocks may need their own permissions An advanced block can expose data, configuration, or external actions. Inserter access alone cannot protect those operations. Check capabilities inside each endpoint. The editing component can show an explanatory placeholder when permission is missing. Avoid exposing private values in client state. Return only authorised data. Rendering should fail safely when privileges change. Stored attributes may outlive an authorised editor. Revalidate access during every sensitive request. ## Revisions preserve restricted block content A revision can contain blocks no longer allowed for the current user. Restoring that revision may reintroduce those instances. The restore action needs appropriate permission. Test revision browsing and restoration with representative roles. Existing block registration matters. A restored unavailable block can become difficult to edit. Keep recovery roles broader than ordinary author roles. Document when an administrator must help. Do not disable revisions to avoid this workflow. ## API clients need the same permission model Headless editors and mobile clients may not use the standard inserter. They can submit block markup through REST. Server checks remain authoritative. Expose allowed-block configuration to trusted clients only when needed. The client can guide choices. It should not decide final authorization. Test application passwords, cookie authentication, and delegated integrations separately. Each identity receives capabilities through its WordPress user. Revoke unused credentials. ## Train users around responsibilities Explain why certain blocks are available. Name the approved alternative for common missing choices. Users follow policies better when the preferred path is clear. Do not present restrictions as punishment. They reflect publishing responsibilities and impact. Provide escalation for legitimate exceptions. Update training when capability maps change. Screenshots and role names become stale. Teach the workflow and support route, not just menus. ## Review access through real tasks A matrix cannot reveal every usability problem. Ask each role to create, edit, schedule, review, and recover representative content. Observe workarounds. Repeated administrator intervention signals an overly narrow list or unclear process. Repeated design damage signals an overly broad list. Adjust evidence, not instinct. Review quarterly and after team changes. Access should follow current responsibility. Departed users and abandoned exceptions require prompt cleanup. ## A testing checklist 1. List responsibilities and required custom capabilities. 2. Assign capabilities through controlled migrations. 3. Build post-type lists before user narrowing. 4. Preserve false and existing arrays. 5. Test every representative user account. 6. Test new and historical records. 7. Test templates, patterns, paste, and transforms. 8. Verify server actions enforce real permissions. 9. Test personal preference reset behaviour. 10. Test multisite contexts where applicable. 11. Provide a rollback for list rules. 12. Review after role or plugin changes. Use actual accounts, not capability assumptions. Complete real editorial tasks. A correct list can still create an unusable workflow. Document every test account’s capabilities before execution. Capture the expected inserter list and prohibited actions. Repeat tests after switching users within the same browser. Cached editor state can otherwise confuse results. Finish by confirming sensitive endpoints reject unauthorised requests directly. Keep a signed-off record of every expected difference. Traceable approvals make later access reviews much easier. Keep that approval record current too. The mechanics are in [WordPress block manager](https://wpblocksuite.com/blog/wordpress-block-manager/). ## Frequently asked questions Can WordPress restrict blocks by user role? Yes. Filter allowed block types using user capabilities and the current editor context. Should code check a role name or capability? Check capabilities. They express permission directly and support customised role structures. Are role-based block lists a security control? No. They guide the editor. Sensitive server operations need independent capability enforcement. What happens to existing restricted blocks? They remain saved. Editing depends on registration, templates, locks, and other workflow rules. Can personal preferences override role restrictions? No. Preferences can hide permitted blocks. They cannot restore blocks excluded by enforced rules. ## The verdict Verdict **Check capabilities:** roles are containers, while capabilities express the actual responsibility. **Secure separately:** block lists guide editors but never replace server authorization. Focused block access can make specialist plugins easier for teams. It also needs careful testing. Try WP Block Suite’s free plugins first. Then [compare the $299 lifetime suite](https://wpblocksuite.com/#pricing) when approved Pro tools fit defined responsibilities.