Remove or Reset

If you need to take VMP Security off a site fully — or reset it to a clean state without uninstalling — this article walks through the steps that go beyond a simple plugin deactivation. A normal deactivation leaves files, options, and Extended Protection configuration behind; full removal requires undoing each of these in turn.

In This Article

• Deactivation vs. removal
• Removing VMP Security
• Resetting data without uninstalling
• Leftover files to check
• After removal

Deactivation vs. removal

A plugin deactivation tells WordPress not to load the plugin, but leaves everything in place — configuration in the database, files on disk, scheduled events, and any external configuration the plugin installed. Deactivation is the right move when you are temporarily disabling something for troubleshooting.

A plugin removal deletes the plugin’s code from wp-content/plugins/vmpfence-security/. WordPress also runs the plugin’s uninstall script (uninstall.php), which cleans up the plugin’s database tables, scheduled cron events, and options based on the data-retention choice you made on the deactivation feedback dialog.

VMP Security has one piece of state that lives outside the standard uninstall: the Extended Protection configuration that the optimization wizard installs in .htaccess and the vmp-waf.php loader at the WordPress root. Always remove Extended Protection before deactivating, otherwise the auto_prepend_file directive will reference a file that no longer exists and PHP will error on every request.

Removing VMP Security

The full sequence:

1. If Extended Protection is enabled, open VMP Security → Firewall → Firewall Options and click REMOVE EXTENDED PROTECTION. Wait for the wizard to confirm that the loader file and .htaccess entry have been removed.
2. Disconnect the site from VMP Security Portal if it is connected.
3. Open VMP Security → Tools → Diagnostics and confirm Extended Protection is no longer active.
4. Open Plugins → Installed Plugins. Click Deactivate on VMP Security. The deactivation feedback dialog asks whether you want to retain or delete plugin data; choose accordingly.
5. Click Delete. WordPress runs uninstall.php, which removes the plugin’s database tables, options, and scheduled cron events.

Resetting data without uninstalling

If you want a clean slate but want to keep the plugin installed — for example, you have made a mess of options and want defaults back — the most reliable approach is to use Tools → Import/Export Options:

• Use Restore defaults on each settings page (Firewall Options, Scan Options, Blocking Options, etc.) to roll back individual sections to factory defaults.
• Use the export/import flow to back up your current configuration before resetting, in case you change your mind.

Resetting settings does not touch Extended Protection. If Extended Protection was enabled before the reset, it stays enabled after.

Leftover files to check

Even after a clean uninstall, a few things on disk and in server config are worth confirming are gone:

• wp-content/uploads/vmpfence/ — the plugin’s upload working directory (debug logs, temp files). Removed by the uninstall script, but check that it is actually gone, especially on hosts with delayed deletion.
• wp-content/vmpfence-backups/ — .htaccess backups created by the WAF Optimizer. Safe to delete once you no longer need to revert.
• vmp-waf.php at the WordPress root — the firewall loader. Should have been removed by REMOVE EXTENDED PROTECTION. If it is still there, delete it manually.
• .htaccess — should no longer have the VMP Security auto_prepend_file directive. Look for the markers # BEGIN VMP Security / # END VMP Security.
• Cron jobs — if you set up an external cron job specifically for VMP Security, remove it.

After removal

If you are removing VMP Security to install a different security plugin, do the install on the same site immediately. The window between “old security plugin removed” and “new security plugin enforcing” is unprotected.

If you are removing VMP Security and not replacing it, take a moment to think about what was protecting the site that is now no longer protected: brute-force lockouts, the firewall, scheduled scans, blocked-country lists. Some of these have minimal alternatives in plain WordPress (for example, you can ask your host to enable mod_security as a partial firewall replacement) but most do not.