Troubleshooting

Updated Aug 11, 2026

Troubleshooting

This guide covers common issues you may encounter while configuring or using Oleva Admin Cleaner (OAC).

Most unexpected behavior is related to Audience targeting, WordPress permissions, third-party plugins, or changes to the WordPress admin environment.

Before making major changes, identify which users are affected and which AUC feature is involved.

Start With These Checks

When something does not work as expected, start with a few basic checks:

  1. Confirm that Oleva Admin Cleaner is active.
  2. Confirm that the affected user matches the intended Audience.
  3. Check whether the user is excluded from the Audience.
  4. Check whether Owner or Manager protection affects the user.
  5. Save the relevant AUC configuration again.
  6. Test using the actual affected user when possible.
  7. Review Audit Log for recent configuration changes.
  8. Check whether a plugin, theme, or WordPress update recently changed the admin environment.

Caption: Start troubleshooting by identifying the Audience and AUC feature involved in the unexpected behavior.

Avoid changing several AUC settings at once while troubleshooting.

Changing one thing at a time makes the cause easier to identify.

AUC Changes Are Not Applied to a User

If a user does not receive the expected AUC configuration, check Audience first.

Verify that:

  • The user's role is included where expected.
  • The individual user is included where required.
  • The user is not explicitly excluded.
  • The correct user account is being tested.
  • Owner or Manager access is not intentionally bypassing the configuration.

Remember:

Exclude takes priority over Include.

For example:

Include
└── Editor

Exclude
└── John

If John is an Editor, the exclusion still takes priority.

See Audience for details.

A Menu Item Is Still Visible

If Menu Cleaner is configured to hide an item but the user can still see it:

  1. Confirm that the user matches the intended Audience.
  2. Confirm that the correct menu item or submenu is configured.
  3. Save the Menu Cleaner configuration.
  4. Test using the affected user account.
  5. Check whether the menu item is generated dynamically by a plugin.
  6. Check whether a recent plugin update changed the menu structure.

Third-party plugins can register or rebuild admin menus in different ways, so behavior may vary for some plugin-generated items.

See Menu Cleaner for details.

A Hidden Menu Page Is Still Accessible

This can be expected.

Menu Cleaner controls navigation visibility. Hiding a menu item does not necessarily prevent direct access to the underlying WordPress admin page.

For example:

Menu Cleaner
└── Plugins: Hidden

may remove Plugins from the admin menu, while WordPress may still allow the user to open:

/wp-admin/plugins.php

if their WordPress permissions allow it.

If the page must not be accessible, use Page Locks.

Hide for clarity. Lock for access restriction.

A Page Lock Is Not Applied

If a user can still access a page that should be locked:

  1. Confirm that the user matches the configured Audience.
  2. Confirm that the correct admin page is locked.
  3. Check whether the user is protected by Owner or Manager access.
  4. Confirm that Recovery Mode or Safe Mode is not currently active.
  5. Test the exact page URL using the affected user.
  6. Check whether the third-party plugin uses a different admin URL than expected.

Some plugin features use multiple admin pages or dynamic URLs.

A lock configured for one page may not automatically represent every page belonging to that plugin.

See Page Locks for more information.

A Page Lock Affects the Wrong User

If a Page Lock applies to someone who should remain unaffected, review Audience.

Check:

  • Included roles.
  • Included users.
  • Excluded roles or users.
  • Owner configuration.
  • Manager configuration.

For example, targeting the entire Administrator role may also include administrators responsible for maintaining the website unless they are protected appropriately.

Correct the Audience before changing the Page Lock itself if the lock is otherwise configured correctly.

A Locked Page Redirects Unexpectedly

If opening a locked page produces an unexpected redirect:

  1. Confirm that the Page Lock targets the intended page.
  2. Review the configured redirect behavior.
  3. Make sure the destination is accessible to the affected user.
  4. Check whether the destination is also locked.
  5. Check whether a third-party plugin performs its own redirect.

Avoid configurations where restricted pages redirect to other restricted pages.

If you encounter a redirect loop, use your available recovery mechanism and correct the affected configuration.

I Cannot Access an Admin Page

First determine whether the page is being restricted by AUC.

If you still have access to Oleva Admin Cleaner:

  1. Review your Audience.
  2. Check Page Locks.
  3. Check Owner and Manager access.
  4. Correct the affected configuration.
  5. Save and test again.

If AUC itself or the required settings are no longer accessible, use the Recovery URL.

If Recovery URL is unavailable, enable Safe Mode through wp-config.php.

The normal recovery order is:

Access problem
      ↓
Can you access AUC?
   ↙             ↘
 Yes              No
  ↓                ↓
Correct rule   Recovery URL
                   ↓
             Still unavailable?
                   ↓
                Safe Mode
                   ↓
             Correct the rule

Do not Factory Reset the entire configuration as your first response to an access problem.

I Cannot Access Oleva Admin Cleaner

If your own configuration prevents access to AUC, use the available recovery mechanisms.

Recovery URL

Use your saved Recovery URL to temporarily bypass AUC restrictions and regain access.

Once inside WordPress:

  1. Open AUC.
  2. Review Audience and Page Locks.
  3. Correct the problematic configuration.
  4. Save your changes.
  5. Test normal access again.

Safe Mode

If Recovery URL is unavailable, add the Safe Mode constant to wp-config.php:

define('AUC_SAFE_MODE', true);

Correct the AUC configuration, then remove the constant or change it to:

define('AUC_SAFE_MODE', false);

See Recovery URL and Safe Mode for complete instructions.

A Dashboard Widget Is Still Visible

If Dashboard Cleaner does not hide a widget:

  1. Confirm that the affected user matches the Audience.
  2. Check that the widget is selected correctly in Dashboard Cleaner.
  3. Review the detected Dashboard widgets.
  4. Check whether the plugin renders the content through the standard WordPress Dashboard widget system.
  5. Test after clearing any relevant browser or page cache.

Some plugins create custom Dashboard content outside the standard WordPress widget system.

AUC may not be able to manage arbitrary content that only looks like a Dashboard widget.

See Dashboard Cleaner for compatibility details.

A Dashboard Widget Is Missing From Dashboard Cleaner

The available widgets depend on the current WordPress environment.

If a widget is not detected:

  • Make sure the plugin that provides it is active.
  • Confirm that the widget normally appears for the current WordPress environment.
  • Check whether the widget appears only for specific users or roles.
  • Check whether it is loaded dynamically.
  • Confirm that it is actually a standard WordPress Dashboard widget.

Some third-party interfaces cannot be detected as standard Dashboard widgets.

A Notice Is Still Visible

Notice Cleaner works with supported WordPress admin notices.

If a message remains visible:

  1. Confirm that the affected user matches the Audience.
  2. Review the Notice Cleaner configuration.
  3. Determine whether the message is a standard WordPress admin notice.
  4. Check whether it is generated dynamically with JavaScript.
  5. Check whether the plugin uses a completely custom interface.

Not every message displayed inside WordPress is technically a WordPress admin notice.

Third-party plugins may render promotional messages, banners, or alerts using their own markup.

AUC cannot guarantee control over every custom message created by every plugin.

An Important Notice Is Missing

If information you need is no longer visible, review your Notice Cleaner configuration.

Do not use Notice Cleaner simply to remove every message from WordPress.

Important information should remain visible to users who need to understand or act on it.

If administrators need technical notices but clients do not, use Audience targeting to provide different experiences where appropriate.

An Admin Bar Item Is Still Visible

If Admin Bar Cleaner does not hide a toolbar item:

  1. Confirm that the user matches the Audience.
  2. Check that the correct toolbar item is configured.
  3. Test both the WordPress admin area and frontend when relevant.
  4. Check whether the item appears only in certain contexts.
  5. Check whether the plugin creates the item dynamically.

Third-party plugins may change their Admin Bar structure depending on the current page or user.

See Admin Bar Cleaner for details.

An Admin Bar Item Appears Only on Some Pages

This may be normal.

WordPress and plugins can add Admin Bar items conditionally.

An item may appear based on:

  • The current admin page.
  • Whether you are viewing the frontend.
  • User capabilities.
  • Theme functionality.
  • Plugin state.
  • Current content.

When testing Admin Bar Cleaner, check the contexts where the item normally appears.

Preview Looks Different From the Actual User

Preview is intended to help inspect AUC configuration, but it is not complete user impersonation.

An actual WordPress user may have:

  • Different WordPress capabilities.
  • User-specific settings.
  • Plugin-specific permissions.
  • Different preferences.
  • Conditions that exist outside AUC.

Use Preview while configuring AUC, but perform final testing with an appropriate real user account for important workflows.

See Preview for details.

Problems After Installing or Updating a Plugin

Plugins can change the WordPress admin environment by adding or modifying:

  • Admin menus.
  • Admin pages.
  • Notices.
  • Dashboard widgets.
  • Admin Bar items.
  • User capabilities.
  • Redirects.

After installing or significantly updating a plugin, review the relevant AUC configuration.

A previously configured admin element may have changed, and new elements may need to be reviewed.

Do not assume that an AUC configuration is permanently static when the WordPress environment around it changes.

Problems After Changing the Theme

Themes can also add WordPress admin functionality.

After changing themes, review AUC if you notice:

  • New admin menu items.
  • New Dashboard content.
  • New toolbar shortcuts.
  • Theme-specific admin pages.

Remove obsolete configuration related to the previous theme where appropriate.

Problems After Importing a Configuration

An imported configuration may have been created for a different WordPress environment.

Review:

  1. Owner and Manager access.
  2. Audience.
  3. User-specific rules.
  4. Roles.
  5. Menu Cleaner.
  6. Page Locks.
  7. Dashboard Cleaner.
  8. Admin Bar Cleaner.

Pay particular attention to plugin-specific admin elements and Page Locks.

A configuration that works on one website should be treated as a starting point when imported into another website.

See Import & Export for details.

Problems After Restoring a Backup

A backup represents an AUC configuration from a particular point in time.

The WordPress website may have changed since that backup was created.

For example:

Backup created
      ↓
New plugin installed
      ↓
Theme changed
      ↓
Users changed
      ↓
Old backup restored

The restored AUC configuration may no longer match every part of the current WordPress environment.

After restoring:

  • Review Audience.
  • Review Page Locks.
  • Check plugin-generated menus.
  • Review Dashboard widgets.
  • Check Admin Bar items.
  • Preview affected users.
  • Test important workflows.

See Backup & Restore for details.

Safe Mode Is Still Active

If AUC restrictions are unexpectedly not being applied to anyone, check whether Safe Mode is enabled.

Open wp-config.php and look for:

define('AUC_SAFE_MODE', true);

If you have completed troubleshooting, remove the constant or change it to:

define('AUC_SAFE_MODE', false);

Safe Mode intentionally prevents normal AUC restrictions from being applied and should not remain enabled during normal operation.

Check the Audit Log

If behavior changed unexpectedly, review Audit Log.

Look for recent activity involving the affected feature.

For example:

Unexpected Page Lock
        ↓
Check Audit Log
        ↓
Recent Page Locks change
        ↓
Review current configuration

Audit Log can help identify when a configuration changed and which user performed the supported action.

It does not provide a complete configuration history, so use Backup & Restore when you need a known state to return to.

Return to a Known Working Configuration

If several recent configuration changes make troubleshooting difficult, restoring a known working backup may be faster than correcting each setting individually.

Before restoring:

  1. Create a backup of the current configuration when possible.
  2. Select the correct known working backup.
  3. Restore it.
  4. Review the resulting configuration.
  5. Preview affected users.
  6. Test important workflows.

Remember that restoring an older configuration may require additional review if the WordPress environment has changed since the backup was created.

Avoid Factory Reset Unless Necessary

Factory Reset should not be the default troubleshooting tool.

If only one feature is behaving incorrectly, investigate that feature first.

If access is blocked, use Recovery URL or Safe Mode.

If recent configuration changes caused the problem, consider restoring a backup.

Use Factory Reset only when you intentionally want to discard the existing AUC configuration and start over.

Browser and Cache Issues

Some admin behavior may appear outdated because of browser or caching behavior.

When appropriate:

  1. Reload the page.
  2. Perform a hard refresh.
  3. Test in a private/incognito browser window.
  4. Clear relevant browser cache.
  5. Review any caching or optimization system that affects the WordPress admin area.

Avoid clearing unrelated website data unless necessary.

Third-Party Plugin Compatibility

WordPress gives plugins significant freedom in how they build admin interfaces.

A third-party plugin may:

  • Register standard WordPress admin elements.
  • Build completely custom admin pages.
  • Load elements dynamically with JavaScript.
  • Change admin URLs based on context.
  • Create its own permission system.
  • Modify WordPress navigation after other plugins have loaded.

AUC is designed to work with supported WordPress admin structures, but it cannot guarantee identical behavior with every plugin.

If an issue affects only one third-party plugin, identify:

  • The plugin name.
  • Plugin version.
  • AUC feature involved.
  • WordPress version.
  • PHP version.
  • Steps required to reproduce the issue.

This information is useful when reporting a compatibility problem.

Before Reporting a Problem

Before contacting support, collect enough information to reproduce the issue.

Please include:

  • Oleva Admin Cleaner version.
  • WordPress version.
  • PHP version.
  • Affected AUC feature.
  • Affected WordPress role or user type.
  • Relevant third-party plugin and version, if applicable.
  • What you expected to happen.
  • What actually happened.
  • Steps to reproduce the problem.
  • Relevant screenshots or error messages.

For example:

AUC version: 1.x.x
WordPress: 7.x
PHP: 8.x

Feature: Page Locks
Audience: Editor

Expected:
Editor should be redirected when opening the selected page.

Actual:
Editor can still access the page directly.

Steps:
1. Include Editor in Audience.
2. Add Page Lock.
3. Save configuration.
4. Log in as Editor.
5. Open the page directly.

Clear reproduction steps make compatibility and configuration issues much easier to investigate.

Do Not Share Sensitive Information

When reporting a problem, do not include:

  • Passwords.
  • Recovery URLs.
  • Recovery tokens.
  • API keys.
  • Secret keys.
  • Database credentials.
  • Hosting credentials.
  • Other private authentication information.

If a screenshot contains sensitive information, remove or hide it before sharing.

Troubleshooting Checklist

When AUC does not behave as expected, work through this checklist:

  • Confirm AUC is active.
  • Check the affected Audience.
  • Review Include and Exclude rules.
  • Check Owner and Manager access.
  • Identify the AUC feature involved.
  • Review recent Audit Log activity.
  • Test with the actual affected user.
  • Check whether Safe Mode is active.
  • Review recent plugin or theme changes.
  • Check third-party plugin behavior.
  • Use Recovery URL if normal access is blocked.
  • Use Safe Mode if Recovery URL is unavailable.
  • Restore a known working backup when appropriate.
  • Use Factory Reset only when you intentionally want to start over.

Getting Support

If the problem continues after completing the relevant troubleshooting steps, contact Oleva Studio support.

Provide the environment information and reproduction steps described above.

The more clearly the issue can be reproduced, the easier it is to determine whether the cause is an AUC configuration, WordPress behavior, or a compatibility issue with another plugin.

Never send passwords or other sensitive credentials unless a secure support process specifically requires them.