Overview
AdminLocks is tested with WordPress 6.0 and above, running on PHP 7.4 or later. The vast majority of plugins and themes work alongside AdminLocks without any issues. This page documents known interactions and compatibility details for popular tools and hosting environments.
WordPress Versions
| Version | Status | Notes |
|---|---|---|
| 6.0 - 6.3 | Compatible | Basic support, all core features work |
| 6.4 - 6.6 | Fully compatible | Recommended versions for best experience |
| 6.7+ | Compatible | Latest tested, full feature support |
We recommend running WordPress 6.4 or later for the best AdminLocks experience. Older versions work but may lack some WordPress APIs that AdminLocks uses for enhanced dashboard widgets.
PHP Versions
| Version | Status | Notes |
|---|---|---|
| 7.4 | Minimum | Supported but nearing end-of-life |
| 8.0 - 8.1 | Recommended | Best performance and compatibility |
| 8.2 - 8.3 | Compatible | Fully tested, no known issues |
| 8.4+ | Untested | Likely works, not officially verified |
Popular Plugins
AdminLocks has been tested with the most widely used WordPress plugins:
- WooCommerce — Fully compatible. AdminLocks can restrict WooCommerce admin pages through policies by adding WooCommerce menu slugs to the
deny_pagesordeny_menuslists. - Yoast SEO — Fully compatible. No known interactions.
- Advanced Custom Fields (ACF/ACF Pro) — Fully compatible. ACF field groups and settings pages work normally under all policy configurations.
- Gravity Forms — Fully compatible. Form management pages can be restricted via policies if needed.
- WP Rocket — Fully compatible. See the caching plugins section below for cache exclusion recommendations.
Page Builders
Page builders that add their own admin pages work with AdminLocks. You can restrict access to builder settings pages through policies.
- Elementor — Compatible. To restrict Elementor admin pages, add the relevant Elementor menu slugs to your policy's
deny_pageslist. - Beaver Builder — Compatible. No special configuration required.
- Divi — Compatible. Divi uses non-standard menu slugs for some settings pages, so you may need to identify the correct slugs manually when creating policy rules. Check the URL of each Divi admin page to find the slug.
Security Plugins
Security plugins that modify user capabilities can interact with AdminLocks since both hook into the same WordPress filters.
- Wordfence — Compatible. Wordfence hooks into
user_has_capat priority 10. AdminLocks policies also run at priority 10 and approvals at priority 20. Both plugins coexist without issues in standard configurations. - iThemes Security (Solid Security) — Compatible. No known conflicts.
- Sucuri — Compatible. Sucuri's WAF and monitoring features do not interfere with AdminLocks capability filtering.
If you experience unexpected capability behavior with a security plugin active, try temporarily deactivating one to isolate the conflict. Both plugins modifying user_has_cap at the same priority can occasionally produce order-dependent results.
Caching Plugins
Caching plugins are fully compatible with AdminLocks. However, you should exclude AdminLocks REST API endpoints from page caching to ensure real-time webhook delivery and API responses.
Exclude this path from page caching in your caching plugin settings:
/wp-json/adminlocks/*Tested caching plugins:
- WP Rocket — Add the exclusion under Settings > WP Rocket > Advanced Rules > Never Cache URLs.
- W3 Total Cache — Add the exclusion under Performance > Page Cache > Never cache the following pages.
- LiteSpeed Cache — Add the exclusion under LiteSpeed Cache > Cache > Excludes > Do Not Cache URIs.
Object caching via Redis or Memcached works perfectly with AdminLocks. Policy lookups and settings benefit from object caching through WordPress transients.
Hosting Environments
AdminLocks works on all major WordPress hosting platforms:
| Host | Status | Notes |
|---|---|---|
| WP Engine | Compatible | Use WP-CLI for admin tasks if locked out |
| Kinsta | Compatible | No special configuration needed |
| SiteGround | Compatible | Works with SiteGround's caching layer |
| Flywheel | Compatible | No known issues |
| Cloudways | Compatible | Works with all Cloudways server types |
| Shared hosting | Compatible | Ensure WP-Cron works or use real cron |
On shared hosting environments, WP-Cron may not execute reliably. If you use approval auto-expiry or Cloud sync features, set up a real system cron job to trigger wp-cron.php every few minutes. Contact your hosting provider for instructions on configuring cron jobs.
Multisite
AdminLocks works on individual sites within a WordPress multisite network. Each site has its own policies, audit log, and settings.
Key multisite considerations:
- Network activation is not currently supported. Activate AdminLocks on each site individually from the site's own Plugins page.
- Super admins bypass all policies network-wide. This is consistent with WordPress multisite behavior where super admins have unrestricted access across all sites in the network.
- Each site connects to AdminLocks Cloud independently with its own API key.
- Policies created on one site do not automatically apply to other sites in the network. Use Cloud policy deployment via webhooks to push policies to multiple sites simultaneously.