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.

Login forms and login plugins

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.

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