Optimizing The Firewall

By default, the VMP Security firewall runs as part of WordPress — it loads when WordPress loads, after PHP has already initialized. This catches most attacks, but it has a real limitation: any attack that exploits a vulnerability before WordPress is fully loaded is invisible to the firewall. Optimizing the firewall fixes this. After optimization, the firewall runs before WordPress, intercepting requests at the very beginning of the PHP execution.

In This Article

• What optimization does
• Running the optimization wizard
• Configuration types
• Reverting optimization
• Troubleshooting

What optimization does

WordPress loads in stages: the web server hands a request to PHP, PHP loads wp-config.php, then the WordPress core, then plugins. Without optimization, the firewall is a plugin, which means it loads in the last stage. By that point, plugin code that runs early in the WordPress lifecycle has already executed.

Optimizing the firewall installs a small loader file (vmp-waf.php) and configures PHP to include it before any other PHP runs. The firewall then evaluates each request against its rules first; only if the request looks safe does PHP continue into WordPress. This catches a class of attacks that simply cannot be blocked from inside WordPress, including attacks against plugins that have not yet finished initializing.

After optimization, the firewall’s protection level changes from “Basic WordPress Protection” to “Extended Protection.” Both levels block the same rule set; the difference is when the firewall gets to evaluate each request.

Running the optimization wizard

The optimization wizard performs the changes for you. You should not need to edit server config files by hand.

1. Open VMP Security → Firewall → Firewall Options.
2. In the Protection Level card, click OPTIMIZE THE VMP FIREWALL.
3. The wizard checks your server type. The optimizer relies on .htaccess, so it is supported on Apache and LiteSpeed only. On Nginx or IIS the wizard will report that the optimization cannot be applied automatically.
4. The wizard backs up your current .htaccess to wp-content/vmpfence-backups/ and lets you download the backup. Keep that copy somewhere safe.
5. Click Continue. The wizard writes vmp-waf.php at the WordPress root, adds an auto_prepend_file directive to .htaccess, and reloads the page.
6. The page reloads with Protection Level set to Extended Protection. You are done.

The whole process usually takes under a minute. If the wizard reports the server is unsupported or that .htaccess is not writable, follow the instructions in the modal — the wizard will not partially apply changes.

How the optimization works

Extended Protection works by adding a php_value auto_prepend_file directive to .htaccess that points at vmp-waf.php in the WordPress root. From that moment on, every PHP request executes vmp-waf.php first, which evaluates the request against the firewall rules. Only if the request looks safe does PHP continue to index.php and the rest of WordPress.

This is why Extended Protection requires .htaccess: the directive needs an Apache-style configuration mechanism. Servers that do not honour .htaccess (Nginx, IIS) cannot use the optimizer. On those servers the firewall remains at Basic WordPress Protection.

Reverting optimization

To undo optimization — for example, when migrating the site to a new server — click REMOVE EXTENDED PROTECTION on the Firewall Options page. The optimizer removes the auto_prepend_file entry from .htaccess and deletes vmp-waf.php from the WordPress root. The protection level returns to Basic.

If you have already moved the site or otherwise lost admin access, you can revert manually: edit .htaccess and remove the auto_prepend_file line that points at vmp-waf.php, then delete the vmp-waf.php file. The plugin detects the change on the next admin page load and shows the protection level as Basic.

Troubleshooting

The site shows a fatal error after optimization

If a PHP fatal error like Failed opening required '/path/to/vmp-waf.php' appears, the loader file path baked into .htaccess no longer matches reality. This usually happens when a site has been moved without reverting optimization first. Edit .htaccess manually, remove the auto_prepend_file line, and then re-run the optimizer from Firewall Options on the new server.

Optimization completes but the level stays Basic

If the wizard reports success but the page still shows Basic Protection, the server is ignoring the .htaccess directive. The most common causes are:

• The Apache AllowOverride directive is set in a way that disallows php_value. Ask your host to allow AllowOverride All for the WordPress directory.
• An OPcache layer is serving the previous PHP configuration. Restart PHP-FPM or wait for the OPcache TTL to expire.
• A static cache (Varnish, Cloudflare, a page cache plugin) is serving the old admin page. Clear the cache.

Hosting-specific notes

Some managed-WordPress hosts ship a security configuration that conflicts with auto_prepend_file. If the wizard cannot complete on your host, leave the firewall at Basic Protection — it still blocks the same rule set, just slightly later in the request lifecycle.