WAF prepend not removed when plugin deactivated

Hi @catnaveo

In the Basic Firewall Options section on the All Options page you will see a warning that says:

If you’re moving to a new host or a new installation location, you may need to temporarily disable extended protection to avoid any file not found errors. Use this action to remove the configuration changes that enable extended protection mode or you can remove them manually.

This warning is also displayed when you originally optimize the firewall.

You need to use the button REMOVE EXTENDED PROTECTION before migrating a staging site to a production site location, or vice versa, because the absolute file path for each website is different.

Wordfence does have an option to fully remove all additional files and code used by the firewall, plus all database tables. That option is Delete Wordfence tables and data on deactivation found in the General Wordfence Options section on the All Options page. However, in your situation you don’t want to use that option as you will lose all of your Wordfence settings.

However, simply deactivating the plugin means it should be doing no work until reactivated, correct? Should it not then remove configuration changes that load WordFence before core WP? If the plugin isn’t active, it should not be getting run on every request.

I see there are checks for whether the WAF is disabled before it runs, but it’s only after bootstrapping and loading pretty much all of WF on every request. Is that not excessive if it’s just going to drop out because it is deactivated?

No deactivated plugin should impact the functioning of a site. Even basic troubleshooting has users disable all plugins and switch to a default theme to check for conflicts. If this were the case, it would appear to them that there was something wrong with WordPress itself.

Most users wouldn’t read the warnings, or think to check these things. I had already changed the paths in the .htaccess file, and neglected the .user.ini, which I seem to rarely even encounter on optimized sites for some reason. However, the warnings being on the options page also doesn’t help anyone whose site has turned into something that won’t load.

I’ve talked to the person who was responsible for the change, and things have been dealt with as a practice on our end, where it is only supposed to have been getting optimized during final steps. But it does still seem like a lot more code is being loaded and run for WF than should be when the plugin is deactivated. Something that many users would not know is happening.

Hi @catnaveo

The firewall optimization works by setting a string for the auto_prepend_file PHP directive in a server configuration file to process the wordfence-waf.php file before any other file in WordPress. This allows the firewall to run before any other files in your WordPress file system are processed.

If you deactivate Wordfence then the auto_prepend_file PHP directive in the server configuration file is still active.

For example if you migrated your site to a different server then the file path in the string for the auto_prepend_file PHP directive in the server configuration file will very likely be incorrect. The new server will try to process the wordfence-waf.php file that is in a location that very likely doesn’t exist and this will generate a fatal PHP error. Hence the warning below In the Basic Firewall Options section on the All Options page:

If you’re moving to a new host or a new installation location, you may need to temporarily disable extended protection to avoid any file not found errors. Use this action to remove the configuration changes that enable extended protection mode or you can remove them manually.

As I previously mentioned this warning is also displayed when the user originally optimized the firewall.

Removing the firewall optimization removes the line of code that sets the string for the auto_prepend_file PHP directive in the server configuration file so that the site can be safely migrated and the user can then optimize the firewall again.

I understand your mention and reference to the warning, and I was able to identify and correct the problem, though it took slightly longer than I’d have hoped because of the change being in two files instead of only one. The average user likely could not have done this.

However, fundamentally, deactivated plugins should not be running, and thus the viewpoint that leaving the auto_prepend_file in place on deactivation is not proper, irrespective of whether the installation is being moved. It should be handled differently than the removal of all configuration settings on deactivation.

If you’re moving to a new host or a new installation location, you may need to temporarily disable extended protection to avoid any file not found errors. Use this action to remove the configuration changes that enable extended protection mode or you can remove them manually.

What the above does not say is that even if you disable the plugin, that code will continue to be loaded and run from the plugin despite being turned off. It should be simple enough to keep one’s settings, but have the WAF properly deactivated when the plugin is deactivated, and re-enabled when the plugin is.

If you do not agree that deactivated plugins should avoid loading and executing code, then there is a problem with our fundamental understandings of the ecosystem in which the plugin exists. However, I am reporting this as I deem it to be a bug that a plugin, which is not active, is configured in such a way as to load and execute code despite not being active.