---
title: "Compatibility"
description: "How Adminkeep works alongside WooCommerce, membership plugins, Jetpack, security plugins, DISALLOW_FILE_MODS and multisite, and what it needs to run."
source: https://adminkeep.com/docs/compatibility/
---

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

## WooCommerce and membership plugins

Disabling user registration (the **Registration Lockdown** setting) has three layers. The
strictest — 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/).

## Login forms and login plugins

[Two-Factor Login](/docs/two-factor-login/) asks for its code on the main WordPress login screen.

- **WooCommerce My Account and custom login forms** cannot show the code screen, so they refuse
  users in the chosen roles and link them to the main login screen. Customers are not in those
  roles and log in at My Account as before.
- **A plugin that moves the login screen** to another address works as usual.
- **A plugin that replaces the login screen** with a form of its own cannot show the code screen.
  Test in a private window after switching Two-Factor Login on, and keep the recovery email.
- **Plugins that limit login attempts** see a wrong code as a failed login.
- **The REST API, application passwords and XML-RPC** are not asked for a code, so apps and
  integrations keep working.

## 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

Blocking plugin and theme installs (the **Installation Lockdown** setting) 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 it is on.

## The DISALLOW_FILE_MODS and DISALLOW_FILE_EDIT constants

`DISALLOW_FILE_MODS` and `DISALLOW_FILE_EDIT` still work, and Adminkeep never
interferes with them. The plugin's own switches 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, deleting the plugin keeps each site's data unless that site switched on **Delete all
  Adminkeep data when the plugin is deleted**; the sites that did are cleaned up, the rest are
  left as they were. See [Uninstalling](/docs/installation/#uninstalling).

## Keep WordPress itself updated

Adminkeep hardens 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 two Adminkeep settings blunt
the pattern that flaw relied on, and why patching still comes first.