Compatibility

VMP Security is designed to coexist with the rest of the WordPress ecosystem. In practice that means it is compatible with the vast majority of plugins, themes, and hosts — but a small number have well-known interactions worth understanding before they cause confusion.

In This Article

• Caching plugins
• Page builders
• CDNs and reverse proxies
• Multisite
• Other security plugins
• Local and staging environments

Caching plugins

Caching plugins (W3 Total Cache, WP Rocket, LiteSpeed Cache, WP Super Cache, Cache Enabler, and others) are compatible with VMP Security. They cache page output for visitors; the firewall runs before the cache is consulted, so blocking decisions are not cached and continue to apply.

Two interactions to know about:

• Admin pages should not be cached. All major caching plugins exclude /wp-admin/ by default. Confirm this is still the case on your installation. If admin pages are cached, the VMP Security admin will show stale data and your changes may appear not to take effect.
• Static-cache hits do not show up in Live Traffic. When a request is served from cache (often without invoking PHP at all), the firewall is not invoked and the request is not captured in Live Traffic. This is correct behavior — you are not at risk because the cache hit does not execute any code — but it is worth knowing if you are doing analysis from Live Traffic alone.

Page builders

Elementor, Beaver Builder, Divi, Bricks, and similar page builders work fine with the firewall enabled. The interaction worth knowing about: page builders sometimes post content (HTML, JavaScript fragments, custom CSS) that triggers a firewall rule the first time you save a page with unusual content.

If you see false positives while editing in a page builder:

1. While logged in as an administrator, exercise the builder’s features once. When the firewall blocks a legitimate save, use the “Add to allowlist” button on the block page (or do it from Tools → Live Traffic) to whitelist the URL/parameter pair the builder uses.
2. Switch back to Enabled. Future editing sessions should work without false positives.

This is a one-time setup. Once allowlisted, the patterns stay allowlisted for the version of the builder you used during the learning session.

CDNs and reverse proxies

Sites behind a CDN or reverse proxy (Cloudflare, Sucuri, Fastly, KeyCDN, BunnyCDN, AWS CloudFront, an internal load balancer) need to be configured so the firewall sees the real visitor IP rather than the CDN’s IP.

• Open VMP Security → All Options and find the How does VMP Security get IPs? option.
• Set the visitor IP source to the header your CDN provides. Most use X-Forwarded-For; Cloudflare uses CF-Connecting-IP; Sucuri uses X-Sucuri-ClientIP.
• Set the trusted-proxy list to the IP ranges of your CDN. The plugin only honors the forwarded-for header from these ranges; requests from any other source are read directly.

Without this configuration, every request looks like it is coming from a CDN IP, which means rate limiting, country blocking, and IP blocks all apply to the CDN as a single “visitor” rather than to the real users. The Compatibility section of the diagnostics page tells you whether your visitor-IP detection looks correct.

Multisite

VMP Security supports WordPress multisite, with two activation modes:

• Network-activated. The plugin is enabled across every site in the network, and most options are set network-wide by a network administrator. Sub-site administrators can see the plugin’s status but cannot change the firewall configuration.
• Per-site activation. Each site decides independently whether to enable VMP Security and configures its own options. Useful for hosting providers who want to give individual customers control of their own security.

The firewall is intrinsically per-installation, not per-site — it runs at the PHP layer below WordPress and cannot distinguish between requests to different sites in the same network. Firewall rules and allowlists therefore apply to all sites in the network. Per-site differences are limited to the configuration that lives in the per-site WordPress options table (alerts, scan exclusions, brute-force thresholds).

Other security plugins

Running multiple security plugins simultaneously is rarely a good idea. Each plugin assumes it is the authoritative protection layer; multiple plugins doing overlapping work can produce conflicting blocks, double notifications, and confusing diagnostics.

If you are migrating between security plugins, our recommendation is:

1. Install and configure VMP Security alongside the existing plugin. Both can be active briefly without breaking anything.
2. Disable the existing plugin’s features one at a time, verifying that the equivalent VMP Security feature is doing the job. Start with scanning, then login security, then the firewall.
3. Once every feature has been migrated, deactivate and remove the old plugin.

Doing the migration this way avoids any window where the site is unprotected.

Local and staging environments

The plugin runs fine in local and staging environments, with two adjustments worth making:

• Disable the firewall in local development. The development workflow involves all kinds of activity that a firewall would reasonably flag. Toggle Web Application Firewall Status to Disabled on the local environment’s Firewall Options page (or set the option directly via WP-CLI in your local provisioning script).
• Do not connect non-production environments to Portal. Portal counts each connected site against your license. Reserve Portal connections for production sites; staging and local environments should run standalone.