WordPress 7.1 adds filters for configuring Site Editor screens for pages, templates, template parts, and patterns. The hook segment is `postType`, not lowercase `posttype`, and the names are case-sensitive. A typo can silently leave the default screen in place, while a filter that ignores capabilities can expose confusing fields or editing actions to the wrong role.
Use this for theme and plugin developers, editorial platform teams, multisite administrators, and agencies that customize Site Editor list screens for administrators, editors, authors, or client-specific roles.
Quick answer
Build a fixture for each supported role and entity type, register the exact mixed-case hook, and change one property at a time through the view configuration object. Verify default view, default layouts, visible fields, filters, sorting, selection, bulk actions, and Quick Edit against capabilities. A hidden field is not an authorization boundary, so direct REST and crafted action requests must still fail when the user lacks permission.
What to check first
- List every targeted entity screen and exact filter name: page, `wp_template`, `wp_template_part`, and `wp_block`, preserving the documented `postType` case.
- Create users for administrator, editor, author, contributor, subscriber, and each custom role, then record capabilities that govern viewing, editing, deleting, publishing, and reusable content.
- Capture the unfiltered configuration and UI for each role before changing default view, default layouts, view list, field visibility, filters, sorting, or Quick Edit form behavior.
- Apply one configuration merge at a time and test empty states, pagination, search, saved preferences, browser refresh, direct URLs, keyboard use, narrow widths, and translated labels.
- Send direct REST and action requests for hidden or disabled operations to prove server capability checks remain authoritative when a field or button disappears from the interface.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Map entity hooks and roles | List every targeted entity screen and exact filter name: page, `wp_template`, `wp_template_part`, and `wp_block`, preserving the documented `postType` case. | Development evidence confirms the exact callback runs for page, template, template part, and pattern screens intended by the plugin. |
| Capture unfiltered screen contracts | Create users for administrator, editor, author, contributor, subscriber, and each custom role, then record capabilities that govern viewing, editing, deleting, publishing, and reusable content. | Role screenshots and configuration snapshots match the approved default view, layouts, fields, filters, sorting, and Quick Edit behavior. |
| Merge one property at a time | Capture the unfiltered configuration and UI for each role before changing default view, default layouts, view list, field visibility, filters, sorting, or Quick Edit form behavior. | Direct REST, form, bulk, and crafted requests return the expected authorization result independently of visible controls. |
| Test UI and direct requests | Apply one configuration merge at a time and test empty states, pagination, search, saved preferences, browser refresh, direct URLs, keyboard use, narrow widths, and translated labels. | Removing the plugin or filter restores the WordPress default without stranded preferences, fatal errors, or inaccessible content. |
Why this usually happens
- PHP hook names are strings, so a lowercase character can prevent the callback from running without a syntax error.
- A shared callback may assume every entity exposes the same fields, layouts, or form operations.
- Saved user preferences can mask a changed default and make two accounts appear to receive different configuration.
- Interface visibility is often mistaken for permission enforcement even though direct requests bypass the visible control.
Field notes
- Log the hook name, current user role, entity type, and changed configuration keys in development. Do not log content bodies or personal profile data.
- Use deterministic fixture names so screenshot comparisons can distinguish pages, templates, parts, and patterns without exposing client content.
- Retest custom roles after membership, editorial workflow, multilingual, and capability-management plugins have loaded their filters.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
add_filter(
'get_entity_view_config_postType_wp_template',
function ( $config ) {
return $config->merge( array(
'default_view' => 'table',
) );
}
);
// The postType segment is case-sensitive.
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Map entity hooks and roles
- Capture unfiltered screen contracts
- Merge one property at a time
- Test UI and direct requests
- Document role-specific fallback behavior
Decision rule
Pass when every supported role sees the intended fields and actions for each entity, saved preferences behave predictably, unsupported configurations fall back cleanly, and server capability checks reject every direct action the role is not allowed to perform.
What to tell the client or owner
Give the owner the affected versions, exact workflow, observed result, business impact, evidence location, temporary control, named owner, and next review time. Remove credentials and personal data from shared screenshots and logs.
Production verification checklist
- Development evidence confirms the exact callback runs for page, template, template part, and pattern screens intended by the plugin.
- Role screenshots and configuration snapshots match the approved default view, layouts, fields, filters, sorting, and Quick Edit behavior.
- Direct REST, form, bulk, and crafted requests return the expected authorization result independently of visible controls.
- Removing the plugin or filter restores the WordPress default without stranded preferences, fatal errors, or inaccessible content.
Mistakes to avoid
- Do not change several plugins, cache rules, firewall settings, or integrations before preserving a baseline.
- Do not treat one successful browser test as proof for APIs, background jobs, alternate roles, webhooks, or mixed-version fleets.
- Do not paste secrets, personal data, complete production payloads, or customer records into tickets, screenshots, or long-lived logs.
- Do not close the test until the user-visible result and server-side evidence agree.
Questions teams ask during testing
Why does my filter never run?
Check the exact hook name first. The documented segment uses `postType` with a capital T, and hook names are case-sensitive.
Can hiding Quick Edit secure a field?
No. It changes the interface only. The underlying write path must still enforce capabilities and validate data.
Should defaults override a user's saved view?
Decide this explicitly. A default usually applies before a preference exists, so test both a new account and an account with saved settings.
When HandL WP should help
Bring in HandL WP when a production checkout, form, editor, firewall, search visibility, or attribution workflow is at risk. We can preserve evidence, isolate the failing layer, make a narrow corrective change, and verify the result across WordPress, connected services, logs, and the user journey.
If this is active on a production site, test a role-based Site Editor customization.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references