Documentation Policies & Client Mode

Policies & Client Mode

Control what users can see and do with role-based policy rules.

guide 7 min read

Overview

Policies are the core of AdminLocks. They define which admin menus, pages, and capabilities are available to specific WordPress roles. By applying policies, you control exactly what each user role can see and do inside the WordPress admin area.

Policies work at three levels: they can hide menu items from the sidebar, block direct URL access to admin pages, and strip WordPress capabilities from user roles. This layered approach ensures that restricted content is truly inaccessible, not just hidden from view.

How Policies Work

AdminLocks enforces policies through three distinct enforcement layers, each providing a different type of protection:

LayerWhat It Does
Menu RemovalHides sidebar menu items so restricted pages do not appear in the admin navigation
Page Access BlockingReturns a 403 Forbidden response when a user tries to access a denied admin page by URL directly
Capability FilteringStrips WordPress capabilities like install_plugins or switch_themes from the user's role at runtime

All three layers work together. Even if a user bookmarks an admin URL or guesses a page slug, the page access blocking and capability filtering layers ensure they cannot reach restricted functionality.

Policy Templates

AdminLocks ships with three built-in policy templates that cover the most common agency scenarios. These templates can be applied directly or used as a starting point for custom policies.

Client Mode Basic

Client Mode Basic is a one-toggle safe mode designed for clients who only need to edit content. It is the most restrictive of the built-in templates.

Allows: Posts, Pages, Media, and the AdminLocks dashboard.

Denies: Plugins, Themes, Users, Tools, Settings, and all configuration pages.

This template is ideal for agency clients who need to update their own content but should not have access to any site configuration or technical features.

Content Editor

The Content Editor template is similar to Client Mode Basic but also blocks the Comments section. This is designed for content teams that work on posts and pages but do not manage community engagement.

Allows: Posts, Pages, and Media.

Denies: Plugins, Themes, Users, Tools, Settings, and Comments.

Marketing

The Marketing template provides broader access than the content-focused templates. It allows content editing plus limited access to Settings, making it suitable for marketing teams that need to configure some site options.

Allows: Posts, Pages, Media, and limited Settings (General, Reading, Discussion).

Denies: Plugins, Themes, Users, and Tools.

All built-in templates can be duplicated and modified. Go to AdminLocks → Policies, click the template name, and choose Duplicate to create an editable copy.

Creating Custom Policies

Custom policies are JSON rule objects with three arrays that define what to deny. You can create them from AdminLocks → Policies → Add New.

{
  "deny_menus": ["plugins.php", "themes.php", "users.php"],
  "deny_pages": ["plugin-install.php", "theme-install.php"],
  "deny_capabilities": ["install_plugins", "install_themes", "edit_users"]
}

See the Custom Policy Rules documentation for the full reference of available slugs, pages, and capabilities.

Policy Priority

Each policy has a numeric priority. Lower numbers run first. When multiple policies apply to the same user (for example, through overlapping role assignments), all denials are combined using a union operation.

There is no "allow" override in the policy system. If any active policy denies a menu item, page, or capability, that denial is enforced regardless of what other policies permit. This design ensures that security restrictions cannot be accidentally weakened by conflicting rules.

Be careful when assigning multiple policies to the same role. Since denials are cumulative, a user could end up with more restrictions than intended if overlapping policies are not reviewed.

Bypass Capability

Users with the adminlocks_bypass capability are never affected by any policy. Super admins on multisite installations are also automatically exempted from all policy enforcement.

To assign the bypass capability to a user, navigate to AdminLocks → Settings → Bypass Users and add the user account. Alternatively, you can grant the adminlocks_bypass capability directly using a role editor plugin or custom code.

Always assign adminlocks_bypass to your own administrator account before enabling restrictive policies. This prevents accidentally locking yourself out of the admin area.