---
title: "Compatibility"
description: "How Adminkeep behaves alongside WooCommerce, membership plugins, Jetpack, security plugins, and the WordPress lockdown constants."
source: https://adminkeep.com/docs/compatibility/
---

Every lock ships with defaults chosen so that turning it on does not break the things
sites commonly run. The specifics:

## WooCommerce and membership plugins

Registration Lockdown's strictest layer — blocking accounts created by plugin code — is
**off by default**, precisely because WooCommerce checkout and membership plugins create
accounts that way. With the shipped defaults, a customer can still register at checkout
while the administrator guard stays on. A test asserts a subscriber can still be created
with defaults.

The cleanup tool treats WooCommerce data the same way: order notes, webhook logs, and
product reviews are excluded from deletion unless you explicitly opt in — see
[comment cleanup](/docs/comment-cleanup/).

## Jetpack and remote publishing tools

The Jetpack mobile app and legacy remote publishing tools talk to your site over XML-RPC.
If you use them, leave **Disable XML-RPC** off. Nothing else in the plugin touches that
API.

## Security plugins

Installation Lockdown stops new plugins and themes being installed or uploaded, and leaves
updates alone. Your security plugin — and everything else already installed — keeps updating
normally while the lock is on.

## The WordPress lockdown constants

`DISALLOW_FILE_MODS` and `DISALLOW_FILE_EDIT` still work, and Adminkeep never
interferes with them. The plugin's own locks are deliberately softer: they filter
capabilities, so they can always be switched off from the settings screen instead of
requiring file access. Run the constants if you want the hard version; the two approaches
coexist.

## Requirements and multisite

- WordPress 6.9 or newer, PHP 7.4 or newer.
- On multisite, uninstalling cleans up every site in the network, not just the current one.

## Keep WordPress itself updated

Adminkeep locks down parts of the admin, but it is not a substitute for running current
WordPress core. In July 2026, WordPress patched a pre-authentication remote code execution
flaw (the "wp2shell" chain, CVE-2026-63030) affecting versions 6.9.0–6.9.4 and 7.0.0–7.0.1.
It is fixed in **7.0.2**, **6.9.5** and **7.1** — update to one of those or newer. See
[the write-up](/blog/wordpress-core-rce-wp2shell-locks/) for how Adminkeep's locks blunt
the pattern that flaw relied on, and why patching still comes first.