The WordPress admin panel is powerful—but that power often ends up in the wrong hands. With default permissions, clients can access too many plugins, too many settings, and too many ways to accidentally break a site. Whether it’s installing plugins without approval, modifying ACF field groups, or unintentionally altering custom templates, these well-meaning actions can quickly lead to unstable deployments and a flood of preventable support tickets. If you’ve ever had to clean up after a client “just tried something,” you know exactly what’s at stake.
And no, this isn’t simply about assigning the “Editor” role and calling it a day. In practice, many clients request—or genuinely require—Administrator-level access so they can manage integrations, users, and key settings. Denying that access altogether often leads to friction and unnecessary back-and-forth. But giving full admin control doesn’t have to mean handing over the keys to your site’s design and architecture. That’s where this approach shines: you can grant operational admin access while still restricting design, structural, and system-critical tools—effectively transforming WordPress into a stable, focused content management environment, much like a headless CMS.
What does a Headless CMS Backend Look Like?
A headless CMS is designed to separate content management from design and development, which results in a cleaner, more focused admin interface. Instead of exposing users to themes, plugins, or layout tools, a headless CMS presents only the fields they need to manage—titles, body content, media, SEO settings, and structured data—nothing more. This streamlined approach minimizes confusion, prevents accidental design changes, and makes the editing experience faster and more intuitive. For teams managing content at scale, especially across multiple channels or frontends, this clarity is invaluable. It ensures that content editors can do their jobs without stepping into areas that affect branding, layout, or performance—making the site easier to maintain and less prone to user-induced errors.
Restricting access to design settings and plugins will help preserve the integrity of your website.
This post will walk you through how to lock down the WordPress admin area to only allow critical access to trusted users. We'll cover:
- Why locking down WordPress matters
- How it improves UX and security
- Step-by-step code examples to restrict core areas
- How to package this as a Must-Use (MU) Plugin
- How to Restrict Plugin and Theme Access in WordPress Without Removing Admin Rights
- How this makes WordPress feel more like a headless CMS
Why Should you Lock Down the WordPress Admin?
Over the years, WordPress has introduced a variety of tools intended to empower non-technical users—like the Customizer, Full Site Editing (FSE), block patterns, and page builder plugins. While these features offer flexibility, they’ve also blurred the lines between content editing and site design. Clients and team members now have the ability to modify headers, footers, typography, colors, and even plugin behavior—all from the admin interface. While this may seem like a benefit, it often results in off-brand visuals, broken layouts, inconsistent user experiences, and additional developer overhead to reverse or correct well-intentioned changes. What was once a clean, developer-maintained system becomes a patchwork of user-made design decisions. By locking down design-related tools and exposing only content-editing capabilities, you protect the integrity of the site’s design system and maintain the kind of consistency that’s critical for scalable, professional web projects.
Who Needs Full Access?
By default, WordPress gives administrators (and sometimes editors) access to far more than they need:
- Theme switching and editing
- Plugin management (install, delete, update)
- Full Site Editing (FSE)
- Template and template part editing
- ACF field group management
- Custom Post Type configuration changes
The Problem With Too Much Power
These features are dangerous in production:
- A user could accidentally break templates, install vulnerable or conflicting plugins
- A user can attempt to create a new feature themselves, by installing plugins, activating add-ons, or creating new post types, impacting the entire function of the website.
- Someone could unintentionally break templates using Full-Site editing mode.
- Editors could modify ACF field groups or sync ACF JSON changes unintentionally.
One of the biggest challenges in maintaining a professional WordPress site is when clients attempt to create new features themselves—often by installing plugins, modifying ACF fields, or tweaking settings—thinking they’re just a few clicks away from a working solution. In many cases, they think they got 90% of the way there without you, only to encounter a “bug” that’s really just a symptom of skipping the planning and development process. These aren't bugs; they're incomplete, unsupported implementations of functionality that should have been scoped, designed, and built by a WordPress developer.
When this happens, what should have been a billable feature request turns into a support ticket, leading to confusion, missed expectations, and potential instability. By locking down the admin interface and clearly defining boundaries between content management and development, we help prevent these situations and ensure that every new feature is thoughtfully planned, properly implemented, and aligned with the long-term vision of the site.
That’s why it’s critical to create clear boundaries within the CMS—so clients are empowered to manage content, not build features.
Just as platforms like Contentful, Sanity, or Storyblok only expose what content editors need, you can treat WordPress the same way — turning it into a more focused, user-friendly, and reliable backend.
What Capabilities Should You Restrict from Client Admins in the WordPress Backend?
Here are the areas we recommend hiding from everyone except the super-admin (usually user ID 1):
- Plugins
- Themes
- Customizer
- Full Site Editor (FSE)
- Templates / Template Parts
- Advanced Custom Fields (ACF) interface
- Block Plugins (Example: Blockstudio, Kadence Blocks, Spectra Blocks) or Page Builder Template and Settings pages (Examples: Elementor, Kadence)
Code: Restrict Admin Access by User ID
You can place this code in a custom plugin or convert it into a Must-Use Plugin.
How to Disable Plugin and Theme Editors
Place this in your wp-config.php file, not the Must-Use Plugin. It's great for hardening admin access and reducing the risk of code being edited directly in production.
define('DISALLOW_FILE_EDIT', true);Block access to Plugins
Blocking access to the Plugins screen is one of the most effective ways to safeguard a WordPress site from instability and unauthorized changes. Plugins control everything from SEO and caching to form handling and security—disabling or modifying them without oversight can cause serious disruptions. By restricting access to plugin management, you prevent clients or team members from accidentally deactivating critical functionality or installing unvetted third-party tools. In addition to removing the Plugins menu and blocking direct access, you can further harden your setup by defining DISALLOW_FILE_MODS in wp-config.php, which disables all plugin, theme, and core updates through the admin UI. For more granular control, use DISALLOW_PLUGIN_INSTALL and related capability filters. This approach ensures plugin changes go through developer review, keeping your WordPress environment secure, performant, and consistent.
define('DISALLOW_FILE_MODS', true);
This is ideal for production environments where all updates are managed via code or deployment pipelines. It disables:
- Plugin installation, updates, and deletion
- Theme installation, updates, and deletion
- Core updates via the admin UI
1// Hide Plugins menu
2add_action('admin_menu', function() {
3 if (get_current_user_id() !== 1) {
4 remove_menu_page('plugins.php');
5 }
6}, 100);
7
8// Block direct access
9add_action('admin_init', function() {
10 if (is_admin() && basename($_SERVER['PHP_SELF']) === 'plugins.php' && get_current_user_id() !== 1) {
11 wp_die(__('You do not have permission to access the Plugins screen.'));
12 }
13});
14
15// Prevent install/update/delete
16add_action('init', function() {
17 if (get_current_user_id() !== 1) {
18 add_filter('user_has_cap', function($allcaps) {
19 $allcaps['install_plugins'] = false;
20 $allcaps['delete_plugins'] = false;
21 $allcaps['update_plugins'] = false;
22 return $allcaps;
23 });
24 }
25});Block access to Themes and Customizer
Blocking access to the Themes screen and Customizer is a crucial step in maintaining design consistency and preventing accidental disruptions to the live site. When users have the ability to switch themes or access the Customizer, they can unintentionally override global styles, reset widget areas, or introduce visual inconsistencies that affect the entire site. This is especially risky in production environments, where a single theme change can break layouts or integrations. By restricting access to these areas, you ensure that the site's design system remains stable and that all design changes are handled through version-controlled development processes—just as you would in a headless or component-driven architecture.
1// Hide Themes menu
2add_action('admin_menu', function() {
3 if (get_current_user_id() !== 1) {
4 remove_menu_page('themes.php');
5 }
6}, 100);
7
8// Block direct access to themes.php
9add_action('admin_init', function() {
10 if (get_current_user_id() !== 1 && basename($_SERVER['PHP_SELF']) === 'themes.php') {
11 wp_die(__('You do not have permission to access the Themes page.'));
12 }
13});
14
15// Hide Customize menu & block direct access
16add_action('admin_menu', function() {
17 if (get_current_user_id() !== 1) {
18 remove_submenu_page('themes.php', 'customize.php');
19 }
20}, 100);
21
22add_action('admin_init', function() {
23 if (get_current_user_id() !== 1 && strpos($_SERVER['PHP_SELF'], 'customize.php') !== false) {
24 wp_die(__('You do not have permission to access the Customizer.'));
25 }
26});
27
28// Admin CSS to hide any leftover links
29add_action('admin_head', function() {
30 if (get_current_user_id() !== 1) {
31 echo '<style>
32 a[href*="themes.php"],
33 #adminmenu a[href*="customize.php"] {
34 display: none !important;
35 }
36 </style>';
37 }
38});Block Full Site Editing (FSE), Templates, and Template Parts
Full Site Editing (FSE), along with access to templates and template parts, gives users the ability to modify the structure and layout of a WordPress site at a fundamental level. While powerful, this level of control is rarely appropriate for anyone other than the lead developer or technical site owner. Allowing clients or team members to edit headers, footers, and templates directly through the Site Editor can introduce inconsistencies, undo intentional design systems, or even break responsive layouts. Blocking access to FSE ensures that structural elements remain intact, changes go through proper development workflows, and content editors can focus solely on managing what they should—content. This mirrors the controlled, schema-first environment offered by headless CMS platforms.
1// Hide FSE menu
2add_action('admin_menu', function() {
3 if (get_current_user_id() !== 1) {
4 remove_submenu_page('themes.php', 'site-editor.php');
5 }
6}, 100);
7
8// Block direct access to FSE
9add_action('admin_init', function() {
10 global $pagenow;
11 if ($pagenow === 'site-editor.php' && get_current_user_id() !== 1) {
12 wp_die(__('You do not have permission to access the Site Editor.'));
13 }
14});
15
16// Block access to template post types
17add_action('admin_init', function() {
18 if (get_current_user_id() !== 1 && isset($_GET['post_type']) && in_array($_GET['post_type'], ['wp_template', 'wp_template_part'])) {
19 wp_die(__('You do not have permission to access templates.'));
20 }
21});
22
23// Hide templates in menu
24add_action('admin_menu', function() {
25 if (get_current_user_id() !== 1) {
26 remove_menu_page('edit.php?post_type=wp_template');
27 remove_menu_page('edit.php?post_type=wp_template_part');
28 }
29}, 100);
30
31// Unregister template block types
32add_action('init', function() {
33 if (get_current_user_id() !== 1) {
34 unregister_post_type('wp_template');
35 unregister_post_type('wp_template_part');
36 }
37}, 100);
38
39// Block FSE REST API endpoints
40add_filter('rest_pre_dispatch', function($result, $server, $request) {
41 $route = $request->get_route();
42 if (get_current_user_id() !== 1 && is_string($route)) {
43 foreach (['/wp/v2/templates', '/wp/v2/template-parts'] as $restricted) {
44 if (stripos($route, $restricted) === 0) {
45 return new WP_Error('rest_forbidden', __('Access to template editing is restricted.'), ['status' => 403]);
46 }
47 }
48 }
49 return $result;
50}, 10, 3);Lock down ACF Administration
Locking down ACF (Advanced Custom Fields) administration is essential for preserving the structural integrity of your content model. ACF field groups define the backbone of custom data entry in WordPress, and allowing any user on the team to access or modify these configurations (even with best intentions) can lead to broken layouts, invalid content relationships, or even data loss. Editors and content managers should be focused solely on entering content—not managing schema. By restricting access to ACF’s admin interface, you maintain a clear boundary between development and content management, ensuring a more stable, maintainable, and professional site architecture.
1// Only run if ACF is active
2add_action('acf/init', function() {
3
4 // Hide ACF admin menu
5 add_filter('acf/settings/show_admin', function($show) {
6 return get_current_user_id() === 1;
7 });
8
9 // Block direct access to field groups
10 add_action('admin_init', function() {
11 if (
12 get_current_user_id() !== 1 &&
13 isset($_GET['post_type']) &&
14 $_GET['post_type'] === 'acf-field-group'
15 ) {
16 wp_die(__('You do not have permission to access ACF settings.'));
17 }
18 });
19
20 // CSS fallback
21 add_action('admin_head', function() {
22 if (get_current_user_id() !== 1) {
23 echo '<style>
24 #adminmenu a[href*="edit.php?post_type=acf-field-group"] {
25 display: none !important;
26 }
27 </style>';
28 }
29 });
30});How to Create a Must-Use (MU) Plugin
To make these restrictions tamper-proof, convert your code into a Must-Use Plugin.
Step-by-Step:
- Create a file:
/wp-content/mu-plugins/restrictions.php - Add a header and paste in your code:
1<?php
2/**
3 * Plugin Name: Admin Restrictions
4 * Description: Restricts admin access to plugins, themes, FSE, templates, and ACF for everyone except user ID 1.
5 * Author: Your Name
6 */- Save and you're done. MU plugins load automatically, can’t be disabled from the admin, and are ideal for locked-down workflows.
Your WordPress backend now feels more like a Headless CMS
Headless CMS platforms like Contentful, Sanity, and Storyblok have one key trait in common:
Users never see or manage the system itself. They just manage content.
By locking down WordPress in this way:
- Users don’t see plugins, themes, templates, or configuration
- You maintain version-controlled control over structure and design
- WordPress becomes a clean, reliable content backend, similar to a headless CMS
This lets you deliver custom frontend experiences while giving clients a focused, safe admin environment—ideal for enterprise, marketing, or decoupled builds.
Take it further
- Combine this with custom roles or capabilities
- Create a settings panel for toggling restrictions per environment
- Log attempts to access restricted pages for audits
Let WordPress be your flexible backend — but make it safe, clean, and focused.
At our agency, we believe that giving clients a powerful CMS shouldn't mean giving them the tools to accidentally break their own website. That's why we build WordPress experiences that balance flexibility with protection. Through thoughtful admin restrictions, customized interfaces, and developer-led configuration, we ensure our clients can confidently manage their content without ever worrying about disrupting the design, security, or performance of their site. Whether it's a traditional WordPress build or a headless implementation, we deliver clean, stable environments that empower users while preserving the integrity of the system—so teams can focus on growth, not technical recovery.
