Fix: Fatal error: Call to undefined function wp_cache_get()
What Actually Happened
This one bit me while removing W3 Total Cache from a WordPress site. I deactivated and deleted the plugin through the dashboard, the admin went white, and the front end threw:
Fatal error: Call to undefined function wp_cache_get() in /wp-includes/...
The plugin was gone but WordPress was still trying to use it.
The reason is drop-ins. W3TC does not only live in wp-content/plugins/. It installs drop-ins: PHP files WordPress loads automatically at startup, before any plugin runs. When the plugin is deleted, the drop-ins stay behind, and they call functions whose definitions were deleted with the plugin. WordPress then fatals on the first cache call.
Four files are involved, and it is worth knowing all of them rather than only the two in most guides.

The Four W3TC Drop-ins
| File | What it does | Symptom when orphaned |
|---|---|---|
wp-content/object-cache.php |
replaces the object cache | wp_cache_get() fatal — this is the usual culprit |
wp-content/db.php |
routes database calls through the cache | white screen or DB errors |
wp-content/advanced-cache.php |
page cache bootstrap | odd behaviour, no caching, or a fatal on load |
wp-content/w3tc-config/ |
the plugin's config directory | stale config reapplied |
The guide that fixed my site said dp.php, which is a typo — the file is db.php. If you follow that literally you will not fix anything, because you will be renaming something that does not exist.
The Fix, Safely
You need file access. Use SFTP or SSH — not FTP, which sends your credentials in plaintext across the internet in 2026. WinSCP, FileZilla in SFTP mode, or your host's file manager all work.
Back up first. Download wp-content/ or take a host-level snapshot. You are about to change how WordPress boots.
Then, in wp-content/, rename rather than delete:
object-cache.php -> object-cache.php.delete
db.php -> db.php.delete
advanced-cache.php -> advanced-cache.php.delete
w3tc-config/ -> w3tc-config.delete
Renaming is the whole trick. Most hosts let you rename in seconds but take minutes to restore a backup, and if removing one of those files makes things worse, you rename it back and you are exactly where you started.
Then reload the site. In the common case it comes straight back.

If It Is Still Broken
Check for other cache plugins. The same drop-ins are used by WP Rocket, LiteSpeed Cache, Autoptimize and others. If two caching plugins were ever installed, you may have inherited one drop-in from each. Rename them all, then reinstall only the plugin you actually want and let it write its own.
Flush the cache at the host level. Many managed hosts run their own page cache in front of WordPress (Cloudflare, LiteSpeed, Varnish). A stale cached page can keep serving the fatal error even after the file is gone. Purge it from the host panel and from any CDN.
Check wp-config.php for a WP_CACHE constant or a stray define left by the plugin. With WP_CACHE true and advanced-cache.php missing, WordPress will look for a file that is not there.
Look at the actual error line. If the fatal names a different function (wp_cache_add, wp_cache_set), you have not removed the drop-in that is calling it — re-check that object-cache.php really is gone and not sitting in a subdirectory.

Why Rename Rather Than Delete
Two reasons, both practical.
The first is rollback. If the site gets worse, one rename puts you back in the exact previous state, with no backup restore and no downtime while a tarball unpacks.
The second is diagnosis. Leaving the files on disk lets you diff them or read them later to work out which plugin wrote them. A file called object-cache.php that references w3tc_ functions tells you exactly which plugin left it, which matters if the site has a long history of half-removed plugins.
The General Lesson
Deleting a plugin through the WordPress dashboard removes the plugin directory and its database rows. It does not reliably remove drop-ins, because drop-ins live outside the plugin folder by design — that is what makes them drop-ins.
So any time you remove a plugin that touches caching, database or performance, check wp-content/ for leftovers afterwards. object-cache.php, db.php and advanced-cache.php are the standard three. If one of them is present after the plugin is gone, you have found the cause of a crash that will otherwise look inexplicable.
Don't trust the download button. Trust the hash.
If this was useful, More hands-on tech guides at TechGeek. No pressure — read it whenever it's useful.