WordPress ships with a generous set of features. That generosity cuts both ways. It gives site builders a fast start, sure. But it also leaves behind a trail of admin menu items, metaboxes, dashboard widgets, and REST API endpoints that most projects never touch. The gut reaction is to strip them out. Do it the wrong way, though, and you break the mental model of the people who have to live inside the admin every day. This piece is about removing what you don’t need while keeping the interface predictable for editors, content managers, and site owners.
Why Naive Feature Removal Creates Admin Friction
Most developers reach for remove_menu_page() or remove_meta_box() and call it done. The problem isn’t the code. The problem is the context collapse that follows. When you delete a menu item a user expects to see—even if they never click it—you introduce a tiny moment of disorientation. Multiply that across a dozen removed items, and the admin area starts to feel broken. The user may not be able to name what’s wrong, but they sense something is off. That feeling erodes trust in the system and in the team that built it.
A better approach is to think in terms of capability-based reduction rather than blunt removal. Instead of deleting the Tools menu, restrict the capabilities that make it visible. Instead of hiding the Comments screen, disable comments at the content-type level. The goal is to make the admin area reflect the actual responsibilities of the logged-in user, not to create a stripped-down interface that looks like a developer’s local environment.
Map the Admin Experience Before You Touch a Single Hook
Before writing any code, sit down with the people who will use the site daily. Ask them what they expect to see when they log in. Document the roles: editor, shop manager, content reviewer, SEO specialist. For each role, list the screens they need and the actions they perform. Then list the screens they don’t need but expect to exist. That second list is the dangerous one. Removing the Posts menu from someone who only manages pages might seem logical, but if that person has used WordPress before, the absence of Posts can feel like a bug.
Once you have the map, you can decide what to disable and what to simply restrict. Disabling means the feature is gone for everyone. Restricting means it’s hidden from some roles but visible to others. Most projects need more restriction and less disabling.
Use the Role and Capability System as Your Primary Tool
WordPress roles and capabilities are the most underused feature in the ecosystem. They let you shape the admin experience without touching a single menu hook. For example, if your client never needs to manage categories, don’t remove the Categories submenu. Instead, create a custom role that lacks the manage_categories capability. The menu item disappears naturally, and the system remains internally consistent. If an administrator logs in, the menu is still there, because administrators should see the full structure.
This approach also prevents a common support nightmare: the client hires a new person, gives them an Editor role, and suddenly that person can’t find a feature that the documentation references. When you remove menu items globally, you create a divergence between your site’s admin and every WordPress tutorial on the internet. Capability-based hiding keeps the admin aligned with standard WordPress behavior for roles that need the full picture.
Custom Roles vs. Capability Filtering
You have two paths. One is to define custom roles with add_role() and assign them to users. This works well for sites with clearly defined, stable teams. The other is to filter capabilities on existing roles using the map_meta_cap or user_has_cap filters. This is more surgical and allows you to adjust capabilities based on context—for instance, preventing post deletion only for published posts. I prefer custom roles for most projects because they’re explicit and easier to audit later. A role named “Content Editor” tells a story. A filtered “Editor” role with six unset capabilities requires documentation that nobody will read.
Handling Metaboxes and Screen Options Without Frustration
Metaboxes are another common target. The WordPress post editor accumulates metaboxes from plugins, themes, and core. Many of them are noise. The typical fix is remove_meta_box(), but that can backfire. Some metaboxes contain fields that are hidden but still functional. Removing the metabox hides the fields but doesn’t disable their logic. Plugins may still process that hidden data, leading to unexpected behavior.
A safer pattern is to hide metaboxes via Screen Options, then lock those preferences. You can set default screen options with the default_hidden_meta_boxes filter and then remove the Screen Options tab entirely for non-administrators. This keeps the data flow intact while decluttering the interface. The user never sees the clutter, but the underlying functionality remains available if an administrator needs to troubleshoot.
Code Example: Setting Default Hidden Metaboxes
add_filter( 'default_hidden_meta_boxes', 'jooom_default_hidden_meta_boxes', 10, 2 );
function jooom_default_hidden_meta_boxes( $hidden, $screen ) {
if ( 'post' === $screen->base ) {
$hidden[] = 'postcustom';
$hidden[] = 'slugdiv';
$hidden[] = 'trackbacksdiv';
}
return $hidden;
}This snippet hides the Custom Fields, Slug, and Trackbacks metaboxes by default. Users can still enable them through Screen Options if they have the capability. To fully lock the interface, combine this with a capability check that removes the Screen Options tab for non-admins.
Dashboard Widgets: Clean Without Confusion
The WordPress dashboard is a prime target for cleanup. Clients often find the default widgets—Quick Draft, WordPress News, Welcome—distracting or irrelevant. Removing them with remove_meta_box() is straightforward, but again, consider who is logging in. A site owner might want the WordPress News widget. A content editor probably doesn’t. Use role checks before removing widgets so the dashboard adapts to the user.
Also, consider replacing removed widgets with something useful. An empty dashboard feels abandoned. A custom dashboard widget that shows the user’s recent drafts, upcoming deadlines, or a quick link to documentation turns a blank space into a helpful starting point. This is where design awareness meets system engineering: you’re not just taking things away; you’re curating the workspace.
REST API and Application Passwords: Restrict, Don’t Disable
WordPress REST API endpoints expose a lot of data by default. The instinct to disable the REST API entirely is strong, but it’s almost always the wrong move. The block editor relies on it. Many plugins rely on it. Disabling it outright breaks modern WordPress. Instead, restrict access to specific endpoints based on capability or authentication status. Use the rest_authentication_errors filter to require authentication for all REST requests, or use rest_endpoints to remove only the endpoints you don’t need, such as the users endpoint on a site where user enumeration is a concern.
Application passwords are another feature that often gets disabled globally. That’s a mistake if the site needs to integrate with external services via REST API. Instead, limit application password creation to administrators only, or disable it per user role. This keeps the feature available for legitimate use while closing the door on accidental exposure by low-privilege users.
Comments: Disable at the Content Level, Not the Menu Level
Many brochure sites don’t need comments. The quick fix is to uncheck “Allow comments” in Discussion Settings and then remove the Comments menu item. But if you only remove the menu item, comments can still be open on individual posts if the setting was enabled before the menu was hidden. The correct sequence is: disable comments site-wide via the default_comment_status and default_ping_status filters, close comments on all existing posts with a one-time script, and then remove the Comments menu item for roles that don’t need to moderate. This three-step process ensures no orphaned comment forms remain and the admin interface accurately reflects the site’s state.
Admin Bar: Contextual Links, Not Global Removal
The admin bar is a navigation tool, not a decoration. Removing it entirely for logged-in users is a common request, but it removes the “Edit Post” link from the front end, which editors rely on. Instead, prune the admin bar nodes based on user role and context. Keep the site-name menu, the edit link, and any custom links you’ve added. Remove the WordPress logo, the comments link, and the “New” menu if they’re not needed. Use show_admin_bar to disable the bar for specific roles on the front end only, leaving it intact in the admin area.
Code Example: Contextual Admin Bar Pruning
add_action( 'admin_bar_menu', 'jooom_prune_admin_bar', 999 );
function jooom_prune_admin_bar( $wp_admin_bar ) {
if ( ! current_user_can( 'manage_options' ) ) {
$wp_admin_bar->remove_node( 'wp-logo' );
$wp_admin_bar->remove_node( 'comments' );
$wp_admin_bar->remove_node( 'new-content' );
}
}This keeps the admin bar functional for administrators while removing distracting nodes for everyone else. The key is that the bar itself remains, preserving the front-end editing shortcut.
Plugins and Themes: The Silent Admin Invaders
Plugins and themes often add their own admin menu items, metaboxes, and dashboard widgets. These are the hardest to control because they vary with every update. Rather than fighting each one individually, establish a policy: every plugin and theme must be audited for admin additions before deployment. If a plugin adds a top-level menu item that your users don’t need, either choose a different plugin or wrap the addition in a capability check that your custom roles lack. Many plugins use manage_options as the default capability for their menus. By not granting that capability to content roles, you automatically hide those menus without writing a single line of removal code.
For plugins that don’t respect capabilities, you may need to use remove_menu_page() or remove_submenu_page(). But treat this as a last resort. Document every removal so that future maintainers understand why a menu is hidden. Otherwise, someone will spend hours debugging a “missing” plugin menu that you intentionally removed.
Testing: Verify the Admin Experience Across Roles
After implementing your restrictions, log in as each role and walk through the expected workflows. Check not only that the right menus are visible, but also that the order and grouping of menus still makes sense. WordPress menus are organized by context: content creation, content management, site configuration. If you remove the Pages menu but leave Posts, the grouping breaks. The user’s eye expects a certain rhythm. Preserve that rhythm even when you remove items.
Also test the “What’s missing?” scenario. Give a test user a task that requires a feature you’ve hidden. See if they can find an alternative path or if they get stuck. If they get stuck, you’ve hidden too much. The admin area should never be a puzzle.
Documentation: The Feature Map as a Living Document
Create a simple table that lists every WordPress feature you’ve modified, the method used, the roles affected, and the reason. Store this in the project repository or a shared wiki. When the site changes hands—and it will—this document prevents the new developer from undoing your work because they assume it was a mistake. It also helps the site owner understand why their admin looks different from the WordPress.com demo they saw in a sales video.
If you’ve built custom roles, include a capabilities matrix. List each role and the capabilities it has, compared to the default WordPress roles. This matrix is invaluable during security audits and when integrating third-party services that check user capabilities.
When Removal Is the Only Option
There are cases where a feature must be removed entirely, for all roles, with no exceptions. XML-RPC is a classic example. If you don’t use the mobile app, Jetpack, or any XML-RPC-based integration, disabling it reduces the attack surface. But even here, do it cleanly. Use the xmlrpc_enabled filter rather than blocking access via .htaccess. The filter method keeps the logic inside WordPress, where it’s visible to other developers and compatible with core updates. Blocking at the server level creates a hidden dependency that can cause confusing errors later.
Another case is the theme and plugin editors. These are security risks on production sites. Disable them with DISALLOW_FILE_EDIT in wp-config.php. This is a global removal that makes sense for almost every site. It also removes the corresponding menu items automatically, so you don’t need additional code.
Bringing It Together: A System, Not a Collection of Hacks
Disabling WordPress features isn’t a one-time task. It’s a system design decision that affects every user who logs in. Approach it with the same care you’d give to designing the front-end information architecture. Map the experience, use capabilities as your primary lever, hide rather than remove when possible, and document everything. The result is an admin area that feels intentional—clean but not empty, focused but not broken.
When you get this right, clients don’t notice the missing features. They notice that the admin area makes sense. That’s the highest compliment a systems engineer can receive.
FAQ
Should I ever use remove_menu_page() for core WordPress menus?
Rarely. For core menus, capability-based hiding is almost always better. Use remove_menu_page() only for menus added by plugins that don’t respect capabilities, and only after you’ve exhausted other options. If you must use it, document why so future maintainers understand the decision.
How do I handle features that are half-needed?
Some features are needed by one role but not another. For example, an SEO specialist may need access to the Categories page, while a content editor doesn’t. In these cases, don’t remove the menu item. Instead, create a custom capability for that feature and assign it only to the SEO role. This keeps the menu visible for those who need it and hidden for those who don’t, without any hard-coded removals.
What if a client insists on removing a feature that I think should stay?
Explain the trade-offs. Removing a feature globally can break tutorials, confuse new hires, and create support overhead. Offer a capability-based alternative that hides the feature from their daily view but keeps it available for administrators. Most clients accept this compromise once they understand the long-term cost of a non-standard admin.
How do I test admin changes without affecting real users?
Use a staging environment with cloned user accounts. Log in as each role and perform typical tasks. Also, use the User Switching plugin on a development site to quickly jump between roles. This lets you verify the admin experience for each role without logging in and out repeatedly.
