Common Issues

White Screen After Activation

A white screen of death (WSOD) immediately after activating AdminLocks is almost always caused by PHP memory exhaustion from a plugin conflict. AdminLocks hooks into several WordPress core systems during activation (creating database tables, registering capabilities, setting up cron jobs), and if another plugin is consuming significant memory on every admin page load, the combined memory usage can exceed your PHP memory limit.

Step 1: Increase PHP Memory Limit

Add the following to your wp-config.php file, before the line that says "That's all, stop editing!":

define('WP_MEMORY_LIMIT', '256M');

If you are on shared hosting and cannot edit wp-config.php, try adding this to your .htaccess file:

php_value memory_limit 256M

Step 2: Check the Debug Log

Enable WordPress debug logging to see the actual error (see the Debug Logging guide for full instructions):

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Then check wp-content/debug.log for the specific error. Common patterns include:

• Fatal error: Allowed memory size of X bytes exhausted — increase memory limit
• Fatal error: Cannot redeclare function — another plugin is defining a function with the same name
• Fatal error: Class 'X' not found — a required PHP extension is missing

Step 3: Deactivate Conflicting Plugins

If increasing memory does not resolve the issue, deactivate all other plugins via FTP or WP-CLI, then reactivate AdminLocks. If it works, reactivate other plugins one by one to identify the conflict.

# Deactivate all plugins via WP-CLI
wp plugin deactivate --all

# Reactivate AdminLocks
wp plugin activate adminlocks

# Reactivate other plugins one at a time
wp plugin activate woocommerce
wp plugin activate wordpress-seo

Permission Errors

If you see "You do not have permission to access this page" when trying to open the AdminLocks settings page, your WordPress user account does not have the manage_options capability. AdminLocks requires this capability for all admin-facing features.

Common Causes

• Non-administrator role — only the Administrator role has manage_options by default. Editor, Author, Contributor, and Subscriber roles cannot access AdminLocks settings.
• Modified administrator role — a security plugin or custom code has removed manage_options from the administrator role.
• Multisite sub-site admin — on WordPress Multisite, sub-site administrators may have a reduced capability set. Only Super Admins have guaranteed manage_options on all sites.

Fix

Verify your user's capabilities using WP-CLI:

# Check a specific user's capabilities by ID
wp user list-caps 1

# Check which role a user has
wp user get 1 --field=roles

If manage_options is missing from your administrator account, reset the role:

wp user set-role 1 administrator

Cloud Connection Failed

When AdminLocks cannot connect to Cloud, you will see a "Cloud Connection Failed" error in the plugin settings. This means your WordPress site cannot reach cloud.adminlocks.com.

Checklist

1. Verify the API key — go to AdminLocks > Settings and confirm the Cloud API key is entered correctly. Keys start with ak_live_ for production or ak_test_ for testing.
2. Test outbound connectivity — run a quick connectivity test from your server:

   # Test HTTPS connectivity to Cloud
   curl -v https://cloud.adminlocks.com/api/health

3. Check firewall rules — some hosting providers block outbound HTTPS connections from PHP. Contact your host if the curl test fails.
4. Verify SSL — the connection requires a valid SSL certificate on your site. Self-signed certificates may cause verification failures.
5. Check PHP cURL extension — AdminLocks uses WordPress's HTTP API, which requires the cURL PHP extension:

   php -m | grep curl

Policies Not Applying

If you have created a policy but it does not seem to be enforcing restrictions, work through these checks:

1. Verify the Policy Is Active

Go to AdminLocks > Policies and confirm the policy's status toggle is enabled. Inactive policies are stored but not enforced.

2. Check Role Targeting

The policy's roles field must match the WordPress role of the user you are testing with. If the roles field is empty, the policy applies to all non-admin roles. If it is set to editor, it only affects users with the editor role.

# Check a user's role via WP-CLI
wp user get 3 --field=roles

3. Remember Super Admin Bypass

Super administrators (and any user with manage_options) always bypass all policies. If you are testing with an administrator account, the policy will appear to have no effect. Create a test account with the target role to verify policy enforcement.

4. Check Policy Priority

If multiple policies target the same role, they are evaluated in priority order (lower numbers first) and their restrictions are merged. A less restrictive policy cannot override a more restrictive one — restrictions are always additive.

5. Clear Caches

If you are using an object caching plugin (Redis, Memcached) or a page caching plugin, clear all caches after modifying policies. While AdminLocks uses direct database queries for policy evaluation, cached admin pages may show stale menu states.

Missing Menu Items

If WordPress admin menu items have disappeared unexpectedly, an active AdminLocks policy is likely hiding them. This is the intended behavior when a policy includes those menus in its deny_menus array.

How to Diagnose

1. Log in as an administrator (not the affected user role)
2. Go to AdminLocks > Policies
3. Review each active policy's rules to see which menus are being denied
4. Check the roles field to confirm the policy targets the affected user's role

If you want to restore a menu item for a specific role, edit the policy and remove the corresponding slug from the deny_menus array.

Audit Log Not Recording

If the AdminLocks audit log shows no entries, there are two main things to check:

1. Verify Audit Logging Is Enabled

Audit logging can be toggled on and off. Check the setting:

# Check via WP-CLI
wp option get adminlocks_audit_enabled

If the value is empty or 0, enable it through the AdminLocks settings page or via WP-CLI:

wp option update adminlocks_audit_enabled 1

2. Verify the Database Table Exists

AdminLocks creates its audit log table during activation. If the activation was interrupted or failed silently, the table may not exist.

# Check if the table exists
wp db query "SHOW TABLES LIKE '%adminlocks_audit_log%'"

If the table does not exist, deactivate and reactivate the plugin to trigger the table creation routine:

wp plugin deactivate adminlocks
wp plugin activate adminlocks

3. Check Database Permissions

On some hosting configurations, the WordPress database user may not have CREATE TABLE permissions. Check with your hosting provider if the table creation fails repeatedly. AdminLocks requires standard MySQL permissions: SELECT, INSERT, UPDATE, DELETE, CREATE, and ALTER.