Poor Coding of Wordfence Security Plugin Includes Failing to Properly Uninstall
While developing our upcoming WordPress firewall plugin, we have done a fair amount of comparison to the two existing firewall plugins that provide a reasonable measure of protection. With both of them, we have come away with a poor impression of quality of the development of those plugins. That comes through in them failing to provide the level of protection they should. With Wordfence Security, it also could be causing a significant unnecessary performance penalty on websites running it.
A way we are trying to better understand where other firewall plugins are not delivering the result they could be is to look at the reviews of the on the WordPress Plugin Directory. One recent review of Wordfence Security shows that the developer of the plugin doesn’t have a good grasp of the basic of developing a WordPress plugin, while having 4+ million installs according to WordPress’ stats. Here is the whole review:
I’ve just spent an amazing amount of time dealing with leftover file issues and settings with Wordfence because when you uninstall the plugin it doesn’t completely uninstall and it doesn’t remove settings that it places when the plugin is activated. In fact, you actually have to install a second plugin just to remove the orphaned records and files it leaves in the database. This is very lazy and poor design and development. Come on, write clean code or don’t write it at all. My recommendation is to avoid this plugin until they can correct some of the leftover junk that it leaves behind. I would recommend considering using another security plugin. I know I will moving forward for any sites I create. This plugin isn’t well written and while it may provide minimal additional security improvements, getting rid of the plugin is similar to dealing with malware removal processes. 0 out of 5 stars. Fix your code!
The response from a Wordfence employee didn’t exactly dispute what was claimed. Part of what they said is this:
Delete Wordfence data on deactivation
If you are removing Wordfence permanently, or if you want to do a fresh reinstall of Wordfence you can enable the option “Delete Wordfence tables and data on deactivation”. If you then deactivate the plugin, all the Wordfence tables will be deleted. You can then choose to activate Wordfence again to get a fresh installation, or you can choose to delete the plugin. This option can be found in the Wordfence > All Options > General Wordfence Options section.
That is a curious option. If you check the relevant page on the handbook for WordPress plugins, which is in the “Plugin Basics” section, it states that database tables should be removed when a plugin is uninstalled, not deactivated.
We then went to check further on this. Next to that option in Wordfence Security’s setting is a help link that states this:
By default, if you disable Wordfence, the database tables will remain in place with their data. This is to ensure that if you accidentally or temporarily deactivate Wordfence then you won’t lose your configuration or the data you have accumulated like the “Live Traffic” page data.
If you would like to remove all Wordfence data when you deactivate the plugin then check this box and save the change. When you disable the plugin then all Wordfence database tables, entries in the WordPress options database table, scheduled cron jobs, and any other stored data associated with the Wordfence plugin will be removed.
Note that this does not include “Login Security” settings and tables, which have a similar option at the bottom of the “Login Security” > “Settings” page. This allows you to leave those settings in place if you are switching to the standalone Wordfence Login Security plugin. This will be simplified in an upcoming version.
If you then reactivate Wordfence after removing all tables and data, it will appear as if it has been activated on your website for the first time.
The default behavior is the correct one, but missing there is any mention of what happens when you uninstall the plugin, as the database tables should be removed. So we tested things out and found that when uninstalling the plugin the database tables are not removed as they should be. If you enable those options, they are removed when deactivating the plugin.
Further checking shows that the plugin doesn’t actually do anything when it is being uninstalled. So there are also still entries in the _options table and files left after the plugin in uninstalled.
Not only is the plugin not coded in line with how it should, they have bloated their options with two options that shouldn’t need to exist if they properly coded the plugin.
By comparison, we had already ensured that our plugin removed its database table on uninstall, which isn’t hard to accomplish.