Skip to content

WordPress Plugin Compatibility

Vulnity is designed to run alongside common WordPress plugins without breaking the public site, WordPress admin, REST API, login flow, or plugin pages. Compatibility can still depend on the hosting stack, PHP version, WordPress version, cache layer, firewall rules, filesystem permissions, and other installed plugins.

This page documents the environments Vulnity is expected to support, the plugin combinations that have been tested, and the conditions that should be treated as unsupported or requiring review.

Use Vulnity on a standard, single-site WordPress installation with:

  • A supported WordPress version for the installed Vulnity plugin release.
  • A supported PHP version for the installed Vulnity plugin release.
  • Working WordPress REST API routes.
  • Working WP-Cron or a reliable server-side cron replacement.
  • Writable WordPress content directories where Vulnity needs to store protected plugin state.
  • Administrator access for setup, pairing, hardening review, and troubleshooting.

Vulnity should not be installed on unsupported WordPress or PHP versions. When the plugin detects an unsupported runtime, it should block activation or show a clear warning instead of allowing a fragile installation.

The following plugins have passed activation and HTTP smoke checks with Vulnity in a controlled WordPress test site. The checks included the public homepage, WordPress login, REST API behavior, Vulnity admin pages, and fatal-error pattern review.

  • WooCommerce 10.7.0: compatible. WP-CLI can emit route/schema warnings that were not site-breaking in the test.
  • Elementor 4.0.7: compatible. No fatal or admin break observed in the smoke test.
  • Wordfence Security 8.2.1: compatible. Security-plugin coexistence smoke passed.
  • Yoast SEO 27.5: compatible. SEO plugin coexistence smoke passed.
  • Contact Form 7 6.1.5: compatible. Form-plugin coexistence smoke passed.
  • WPForms Lite 1.10.0.4: compatible. Form-plugin coexistence smoke passed.
  • Polylang 3.8.3: compatible. Multilingual plugin coexistence smoke passed.
  • Advanced Custom Fields 6.8.0: compatible. Custom-fields plugin coexistence smoke passed.
  • W3 Total Cache 2.9.4: compatible. Cache-plugin coexistence smoke passed.
  • Autoptimize 3.1.15.1: compatible. Optimization plugin coexistence smoke passed.
  • LiteSpeed Cache 7.8.1: compatible. Cache-plugin coexistence smoke passed.
  • WP Mail SMTP 4.8.0: compatible. Mail plugin coexistence smoke passed.
  • UpdraftPlus 1.26.3: compatible. Backup plugin coexistence smoke passed.
  • Smush 4.0.3: compatible. Media optimization coexistence smoke passed.
  • Query Monitor 4.0.6: compatible. Developer-tool coexistence smoke passed.
  • Classic Editor 1.6.7: compatible. Editor coexistence smoke passed.
  • Akismet 5.5: compatible. Anti-spam coexistence smoke passed.
  • Cloudflare 4.14.2: compatible. Cloudflare integration coexistence smoke passed.
  • WPS Hide Login 1.9.18: compatible. Login-path plugin coexistence smoke passed.
  • Limit Login Attempts Reloaded 3.2.3: compatible after a Vulnity cron dispatch fix. A previous early-load cron fatal was reproduced and fixed before marking this combination compatible.

These results mean the tested combinations did not break the site under the tested conditions. They do not guarantee that every possible configuration, premium add-on, custom snippet, or hosting rule will behave the same way.

Some plugin categories deserve extra attention because they can change request flow, caching behavior, login behavior, or firewall rules:

  • Cache and optimization plugins may require cache purging after Vulnity setup or hardening changes.
  • Security and firewall plugins may need to allow Vulnity REST API routes and admin AJAX actions.
  • Login customization plugins can change login URLs, lockout behavior, or authentication flow.
  • Backup and migration plugins can copy old Vulnity state between sites if a site is cloned incorrectly.
  • Cloud or proxy plugins can affect IP detection if forwarding headers are not configured correctly.

When troubleshooting these categories, verify the WordPress REST API, WP-Cron, login flow, admin AJAX, and Vulnity admin pages before assuming the plugin is incompatible.

The following environments should be treated as unsupported unless current release notes say otherwise:

  • WordPress multisite / network activation.
  • WordPress or PHP versions below the minimum supported runtime for the installed Vulnity plugin.
  • Sites where the WordPress REST API is fully disabled.
  • Sites where WP-Cron and any server-side cron replacement are unavailable.
  • Hosting environments where required filesystem paths cannot be written and the fallback storage mode cannot recover safely.
  • Setups where another plugin or server rule blocks Vulnity admin AJAX or signed REST requests.

Unsupported does not always mean Vulnity will break the site. It means Vulnity cannot promise reliable monitoring, pairing, synchronization, hardening, or mitigation behavior in that environment.

There are currently no public, confirmed plugin incompatibilities that should be treated as a blanket blocklist.

If a conflict is found, it should only be listed here after Vulnity can reproduce it, identify the cause, document the affected versions, and provide a fix, workaround, or clear reason why the combination is unsupported.

What to include when reporting a compatibility issue

Section titled “What to include when reporting a compatibility issue”

Send enough detail to reproduce the conflict safely:

  • WordPress version.
  • PHP version.
  • Vulnity plugin version.
  • Hosting stack, such as Apache, Nginx, LiteSpeed, PHP-FPM, managed WordPress, or containerized hosting.
  • Active plugin list with versions.
  • Active theme and theme version.
  • Whether WordPress multisite is enabled.
  • Whether REST API, WP-Cron, admin AJAX, and login are working.
  • Relevant PHP fatal error, WordPress debug log, server log, or screenshot.
  • Steps that reproduce the issue.

Do not share Vulnity tokens, signing secrets, API keys, cookies, or private customer data in public reports.