When a non-technical editor logs into a WordPress site, the dashboard is the first thing they see. If it’s cluttered with plugin notices, irrelevant meta boxes, and admin menu items they’ll never use, you’ve already lost them. The WordPress admin panel is a workspace, not a billboard. Designing it for editors means stripping away noise, surfacing only the controls they need, and making the publishing flow feel obvious. This sits at the intersection of systems engineering and UX design—what I call editor experience architecture. It’s not about dumbing down the interface. It’s about removing friction so the person writing, editing, and managing content can do their job without asking you where the publish button went.
This article is for builders who hand off sites to clients, content teams, or internal staff. You’ll get a repeatable method for auditing the default dashboard, hiding what doesn’t serve the editor, and adding lightweight customizations that stick. We’ll cover the admin menu, the post edit screen, user roles, and a few code-level tweaks that don’t require a plugin. By the end, you’ll have a dashboard that feels like a tool, not a puzzle.
Why the Default WordPress Dashboard Fails Editors
WordPress ships with a dashboard designed for site administrators, not content editors. The default view includes widgets like “WordPress Events and News,” “Quick Draft,” and “Site Health Status.” For someone whose only job is to publish and update pages, these are distractions. The left-hand admin menu often shows entries for plugins like SEO tools, caching layers, and form builders—items that can break the site if misused. Even the post edit screen buries the content editor beneath Yoast SEO boxes, custom field groups, and discussion settings.
This overload creates a real problem: editors become hesitant. They worry they’ll click the wrong thing and break the site. They call you for tasks that should be self-service. The fix isn’t training them on every menu item. The fix is designing an interface that matches their mental model. A content editor thinks in terms of pages, posts, media, and maybe categories. Everything else is system overhead. Your job is to hide that overhead without removing functionality they actually need.
Start with a User Role Audit
Before you touch a line of code or install a plugin, define who the editor is. In WordPress, the built-in Editor role has capabilities like edit_pages, edit_others_posts, manage_categories, and moderate_comments. But it also grants access to some things you might not want, like the ability to delete published posts or edit theme files if a plugin has altered capabilities. If the default Editor role is too broad, create a custom role using a plugin like Members or with a few lines of code in your theme’s functions.php.
Map out exactly what the editor needs to do. A typical list: create and edit posts and pages, upload images, manage categories and tags, moderate comments, and maybe view form submissions. They don’t need to see the Plugins menu, Tools, Settings, or Appearance. They definitely don’t need to see the Customizer unless you’ve built a specific workflow around it. Write this list down. It becomes your specification for what to keep and what to remove.
Custom Capabilities for Granular Control
Sometimes the standard capabilities aren’t enough. For example, you might want an editor to edit existing pages but not create new ones. Or you might want them to publish posts but not edit published posts by other users. This requires adding or removing specific capabilities. The map_meta_cap filter lets you adjust these on the fly. Here’s a snippet that prevents editors from deleting published posts, even if the role normally allows it:
add_filter('map_meta_cap', function($caps, $cap, $user_id, $args) {
if ($cap === 'delete_post' && !empty($args[0])) {
$post = get_post($args[0]);
if ($post && $post->post_status === 'publish' && in_array('editor', wp_get_current_user()->roles)) {
$caps[] = 'do_not_allow';
}
}
return $caps;
}, 10, 4);
This kind of targeted restriction keeps the editing experience safe. The editor never sees a “Move to Trash” link on published content, so they can’t accidentally delete it. Pair this with a custom admin notice that explains why, and you’ve built trust into the interface.
Cleaning the Admin Menu
The left-hand admin menu is the primary navigation for editors. By default, it’s a long list of items sorted alphabetically, with no visual hierarchy. Plugins often add top-level menu items that editors don’t need. Start by removing these. You can do it with the remove_menu_page() and remove_submenu_page() functions, hooked to admin_menu with a late priority so plugins have already added their items.
Here’s a practical example that strips the menu down to just Posts, Media, Pages, Comments, and Profile for editors:
add_action('admin_menu', function() {
if (!current_user_can('editor')) return;
remove_menu_page('index.php'); // Dashboard
remove_menu_page('tools.php');
remove_menu_page('options-general.php');
remove_menu_page('themes.php');
remove_menu_page('plugins.php');
remove_menu_page('users.php');
// Remove submenus from Posts
remove_submenu_page('edit.php', 'edit-tags.php?taxonomy=post_tag');
}, 999);
Notice I removed the Dashboard itself. For editors, the Dashboard is often a dead end. Instead, redirect them to the Posts list or Pages list on login. This small change sets the tone: you’re here to manage content, not stare at a widget screen. Use the login_redirect filter to send editors straight to /wp-admin/edit.php.
Renaming and Reordering Menu Items
Sometimes you want to keep a menu item but make it clearer. The default “Posts” label might not match the client’s vocabulary—they might call them “Articles” or “News.” Use the gettext filter to rename menu items globally, or target the admin menu specifically with JavaScript if you prefer a front-end approach. Reordering is trickier; the menu_order filter works for top-level items, but for submenus you often need to unset and re-add them with add_submenu_page() at the desired position.
For a news site, I’ll rename “Posts” to “Articles” and move it to the top. For a portfolio site, “Pages” might become “Projects.” The key is to match the language the editor already uses. This reduces cognitive load because they don’t have to translate their mental model into WordPress terminology.
Simplifying the Post Edit Screen
The post edit screen is where editors spend most of their time. Out of the box, it’s a mess of meta boxes: Excerpt, Send Trackbacks, Custom Fields, Slug, Author, Discussion, and whatever plugins have added. Most of these are irrelevant to a content editor. The goal is to show only the title field, the content editor, the featured image, categories, and maybe a custom meta box you’ve built for a specific purpose.
Use the remove_meta_box() function to strip out the clutter. Hook it to admin_menu or do_meta_boxes. Here’s a snippet that leaves only the essentials for a standard post type:
add_action('admin_menu', function() {
remove_meta_box('authordiv', 'post', 'normal');
remove_meta_box('commentstatusdiv', 'post', 'normal');
remove_meta_box('commentsdiv', 'post', 'normal');
remove_meta_box('formatdiv', 'post', 'side');
remove_meta_box('postcustom', 'post', 'normal');
remove_meta_box('postexcerpt', 'post', 'normal');
remove_meta_box('revisionsdiv', 'post', 'normal');
remove_meta_box('slugdiv', 'post', 'normal');
remove_meta_box('trackbacksdiv', 'post', 'normal');
remove_meta_box('tagsdiv-post_tag', 'post', 'side');
});
If you’re using the block editor (Gutenberg), meta boxes are less of an issue because the editor takes over the screen. But plugins can still add panels to the sidebar or below the content. Disable these in the plugin settings or with custom code. For the classic editor, this cleanup is essential. Either way, test the screen as an editor user to see what remains.
Customizing the Block Editor Experience
The block editor can be overwhelming too. The inserter shows every block from every plugin, including ones editors shouldn’t use. Lock this down with allowed_block_types filter. For a simple blog, you might allow only paragraph, heading, image, list, quote, and embed blocks. This keeps the editor focused on writing, not designing layouts they’ll break.
You can also disable the fullscreen mode by default, which hides the admin sidebar and can confuse editors who expect to see the menu. Use the block_editor_settings filter or a small JavaScript snippet to set the default to non-fullscreen. These details matter because they reduce the number of “where did everything go?” support tickets.
Hiding Plugin Notices and Dashboard Widgets
Plugin update nags, review requests, and upsell notices are the worst offenders in an editor’s dashboard. They appear on every screen, often with no way to dismiss them permanently. For editors, these should be completely hidden. The admin_notices hook doesn’t give you a direct way to remove specific notices, but you can suppress all notices for non-administrators with a simple capability check, or use CSS to hide known notice selectors.
A more surgical approach: many plugins attach their notices to the admin_notices action using a specific callback. If you can identify the callback, you can remove it with remove_action(). This requires digging into the plugin code, but it’s worth it for a clean interface. For dashboard widgets, use remove_meta_box() with the dashboard screen ID. Remove “WordPress Events and News,” “Quick Draft,” and any plugin-added widgets that aren’t relevant to content creation.
Building a Custom Dashboard Widget That Actually Helps
Instead of leaving the dashboard empty, replace the removed widgets with something useful. A custom dashboard widget can show the editor their recent drafts, a quick link to create a new post, or a simple content checklist. This turns the dashboard from a dumping ground into a launchpad.
Here’s a minimal widget that shows the editor’s last five drafts and a “New Post” button:
add_action('wp_dashboard_setup', 'custom_editor_dashboard_widget');
function custom_editor_dashboard_widget() {
if (current_user_can('editor')) {
wp_add_dashboard_widget(
'editor_content_widget',
'Your Content',
'render_editor_dashboard_widget'
);
}
}
function render_editor_dashboard_widget() {
$drafts = get_posts([
'post_status' => 'draft',
'author' => get_current_user_id(),
'posts_per_page' => 5,
]);
echo '<ul>';
foreach ($drafts as $draft) {
printf(
'<li><a href="%s">%s</a></li>',
get_edit_post_link($draft),
esc_html($draft->post_title)
);
}
echo '</ul>';
echo '<p><a href="' . admin_url('post-new.php') . '" class="button button-primary">New Post</a></p>';
}
This widget replaces the default clutter with something actionable. The editor sees their work in progress and a clear path to start new content. It’s a small change that shifts the dashboard from a passive info screen to an active workspace.
Handling Media Library Access
Editors need to upload and insert media, but they shouldn’t see every file ever uploaded to the site. By default, WordPress shows all media to any user with the upload_files capability. This can be a problem if the media library contains sensitive files or if editors get confused by seeing hundreds of images they didn’t upload.
A common solution is to restrict the media library to show only files uploaded by the current user. This can be done with the ajax_query_attachments_args filter, which modifies the query used in the media library’s grid view. Add a check for the current user’s role and set the author parameter to their user ID. This keeps the library clean and relevant without removing the ability to upload new files.
For sites where editors need to see all media but shouldn’t delete anything, use the map_meta_cap filter to remove the delete_post capability for attachments. This prevents accidental deletion of images used on live pages—a common support headache.
Designing the Login Experience
The login screen is the first touchpoint of the editing experience. The default WordPress login page is functional but generic. For a client site, a branded login page with the company logo and a custom URL (like /editor-login) signals that this is a purpose-built tool, not a generic CMS. Use the login_enqueue_scripts action to add a custom stylesheet, and the login_headerurl and login_headertext filters to link the logo to the site’s homepage.
More importantly, consider the login flow. If editors are redirected to the dashboard after login, they’re already off-track. Use the login_redirect filter to send them directly to the Posts or Pages list. If you’ve removed the Dashboard menu item, this is essential. Also, set the admin_email to a real address that someone monitors, so password reset emails don’t get lost.
Testing with Real Editors
You can’t design an editor experience in isolation. After you’ve made your changes, sit down with an actual non-technical person and watch them use the dashboard. Give them a task: “Create a new blog post, add an image, and schedule it for next Tuesday.” Don’t guide them. Just observe where they hesitate, what they click by mistake, and what they ask about.
This testing will reveal gaps you missed. Maybe the “Add New” button is too small. Maybe the category selector is hidden behind a tab they didn’t see. Maybe the publish button’s label (“Publish…”) makes them think it’s a multi-step process. These are real friction points that code alone won’t catch. Iterate based on what you observe, not what you assume.
Maintaining the Design Over Time
WordPress sites change. Plugins get added, themes get updated, and new users join the team. The clean dashboard you built six months ago might now have a new notice from an SEO plugin or a menu item from a recently installed form builder. Schedule a quarterly review of the editor experience. Log in as an editor user and click through every screen. Check for new meta boxes, menu items, and dashboard widgets. Update your cleanup code accordingly.
Document your customizations in a site-specific plugin or a mu-plugin file. This keeps the editor experience code separate from the theme, so it survives theme switches. It also makes it easier to hand off to another developer. Include comments that explain why each removal was made, not just what it does. Future you (or the next developer) will thank you.
When to Use a Plugin vs. Custom Code
Several plugins promise to clean up the WordPress admin. Adminimize and WPS Hide Login are popular choices. They work, but they add another layer of abstraction. For a single site, custom code in a mu-plugin is often more maintainable because you control exactly what happens. For a multisite network or an agency managing dozens of sites, a plugin with a UI might be more practical.
My rule: if the cleanup logic is simple (removing menu items, meta boxes, dashboard widgets), use custom code. If you need role-based visibility settings that non-developers will adjust, consider a plugin. But always test the plugin’s performance impact. Some admin cleanup plugins load their own CSS and JavaScript on every admin page, which can slow down the editor’s workspace.
Common Mistakes That Undermine the Editor Experience
Even well-intentioned customizations can backfire. One common mistake is hiding the “Screen Options” tab. Editors might need to enable a meta box you thought was useless. Instead of hiding the tab, use it to set sensible defaults and then leave it accessible. Another mistake is removing the “Help” tab without providing alternative documentation. If you strip away WordPress’s built-in help, replace it with a custom help page or a link to your own docs.
Over-restricting capabilities is another pitfall. If an editor can’t change a post’s author or modify the slug, they might not be able to do their job. Before removing a capability, ask: “Is there a legitimate reason an editor would need this?” If the answer is “sometimes,” leave it in and provide training instead. The goal is to remove noise, not to lock editors out of necessary tools.
Building a Content Hub That Editors Understand
Beyond the dashboard, the site’s information architecture affects the editor experience. If your post types and taxonomies are confusing, no amount of dashboard cleanup will fix that. Editors need to understand the difference between a “Post” and a “Page,” or between “Categories” and “Tags.” If your site uses custom post types, name them clearly and group them logically in the admin menu.
For a site with multiple content types, consider creating a custom admin page that serves as a content hub. This page could list all post types with quick-add buttons, recent drafts across all types, and links to documentation. It replaces the default dashboard with a purpose-built command center. This is especially useful for sites that use WordPress as a headless CMS, where the front-end is decoupled and editors need a clear starting point.
FAQ
How do I hide the admin bar for editors?
Use the show_admin_bar filter. Check the current user’s role and return false for editors. Add this to your theme’s functions.php or a mu-plugin: add_filter('show_admin_bar', function($show) { return current_user_can('editor') ? false : $show; });. This removes the toolbar from the front-end, which can be distracting for editors who don’t need quick access to the dashboard while viewing the site.
Can I create a completely custom admin page for editors?
Yes. Use add_menu_page() to create a top-level menu item that links to a custom page. Build the page content with a callback function that outputs your HTML. You can include shortcuts, recent drafts, and site-specific instructions. Set this page as the default landing page for editors using the login_redirect filter. This gives you full control over the editor’s starting point.
What’s the best way to handle editor training without overwhelming them?
Build contextual help directly into the dashboard. Use the admin_notices hook to display a dismissible welcome message with links to video tutorials or a written guide. Add a custom dashboard widget with a “Quick Start” checklist. For complex tasks, create a dedicated admin page with step-by-step instructions. The key is to provide help where and when the editor needs it, not in a separate manual they’ll never open.
How do I prevent editors from accidentally publishing unfinished posts?
Use the wp_insert_post_data filter to force posts to “draft” or “pending review” status when saved by editors, unless they explicitly click “Publish.” You can also remove the “Publish” button for editors and add a custom “Submit for Review” button that changes the post status to “pending.” This creates a workflow where an administrator or senior editor reviews content before it goes live.
Next Steps for Your Site
Start with the user role audit. Write down exactly what your editors need to do, then remove everything else. Test the result with a real editor and iterate. The code snippets in this article are starting points—adapt them to your specific setup. If you’re dealing with a site that has existing content and a confused editor, you might also want to read about what to fix first when a new WordPress site says nothing found, which covers common content visibility issues that can compound editor frustration.
Remember: a well-designed dashboard is invisible. The editor doesn’t notice it because it just works. They log in, find their content, and get to work. That’s the goal. Build it, test it, and then leave it alone until the next quarterly review.
