When you’re managing hundreds of WordPress sites like I do, one thing becomes clear: Wordfence can leave behind serious database bloat, especially in large installations. Recently, I ran into a brutal case — I couldn’t delete a single table, even from phpMyAdmin or the MySQL CLI.

That table? wp_wffilemods.

The Symptoms

I disabled Wordfence, then tried to:

But all operations would spin forever in phpMyAdmin — nothing worked.
Even the REPAIR TABLE wp_wffilemods; query was stuck.

Diagnosing the Issue with SHOW PROCESSLIST

Since I had cPanel Terminal access (but no SSH), I connected to MySQL via CLI:

mysql -u DB_USER -p

Then:

USE your_database;
SHOW PROCESSLIST;

That showed the truth: the table was locked by a long-running query:

State: Waiting for someone to free space
Query: INSERT INTO wp_wffilemods ...

Meanwhile, all my DROP TABLE, TRUNCATE, and CREATE TABLE queries were Waiting for table metadata lock.

The Fix: Killing the Blocker

I killed the blocking query safely using:

KILL 1247991;

That immediately released the metadata lock.

After that, I was able to drop the table instantly:

DROP TABLE wp_wffilemods;

Boom. Problem solved. ✅

Is KILL Safe?

Yes — when:

Always double-check with SHOW PROCESSLIST first.

Final Cleanup

Once the table was gone, I:

  1. Removed any lingering Wordfence cron jobs using the WP Crontrol plugin
  2. Deleted the wordfence plugin folder from wp-content/plugins/
  3. Optimized the database to remove leftover overhead

Lessons Learned


If you’re managing WordPress sites and run into a stuck wp_wffilemods, don’t panic. Just go surgical with MySQL CLI.

Need help with WordPress cleanup, blacklist removal, or DB repairs?
Visit 3zerodigital.com — we fix 0-day issues with 0 downtime, 0 error, 0 vulnerability.

Leave a Reply

Your email address will not be published. Required fields are marked *