WordPress Critical Error [Solved]

Have you ever had the SSL certificate expire and then had to troubleshoot a bunch of issues one by one to understand the real issue? That is exactly what this WordPress Critical Error was about.

When your WordPress site suddenly breaks with a vague “There has been a critical error on this website” message, it’s easy to panic. Recently, we helped a client resolve such an error that crashed the WordPress backend (/wp-admin), while the frontend was still working.

The root cause? A broken caching setup involving W3 Total Cache, Redis, and a leftover db.php override.

Here’s exactly how we solved it, and how you can avoid this problem on your WordPress site.

The Problem

After activating SSL and making changes to the cache plugin setup, the site began throwing a critical error on the WordPress admin login page. Meanwhile, the frontend loaded as usual.

Debug log revealed the following fatal error and we traced to,

Missing or broken object-cache.php and advanced-cache.php files
A leftover db.php file (likely created by W3 Total Cache or Redis plugin)
Redis object caching trying to initialize too early.

PHP Fatal error:  Uncaught Error: Call to undefined function wp_kses() in /wp-content/db.php

The Cause

A combination of missteps created the problem,

• W3 Total Cache plugin was removed improperly
• Redis object caching was enabled, but Redis was not available on the host
• db.php file attempted to run WordPress functions before they were loaded
• object-cache.php and other drop-ins remained active, pointing to missing services

This broke the WordPress load sequence, making it impossible to access /wp-admin.

Step-by-Step Solution

Here’s how we fixed it, and take a look at how we traced the error without showing it to users.

Enable Debug Logging

In wp-config.php, we added,

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Delete Residual Cache Files

From /wp-content/, we removed,

The folder w3tc-config
object-cache.php
advanced-cache.php
The plugin folder w3-total-cache (if it still existed)

Remove Redis & DB Drop-ins

We identified that db.php was calling wp_kses() before WordPress had loaded it. Deleting,

/wp-content/db.php

This action immediately resolved the admin crash.

Reset wp-config.php

We made sure WP_CACHE was disabled.

define( 'WP_CACHE', false );

And we removed any Redis-related definitions like WP_REDIS_HOST or WP_REDIS_PORT If they had been present.

In the end

As a rule of thumb remember the following,

Never delete cache plugins without disabling and cleaning drop-in files.
Redis is powerful but should only be used if your hosting supports it.
Debug mode is your best friend when errors aren’t obvious. Always refer to the Error Logs.
db.php, object-cache.php, and advanced-cache.php can cause fatal errors if left behind.

If you’re facing similar errors

We specialize in WordPress speed optimization, malware removal, and crash recovery. If your site is stuck in a critical error loop, we’ll get it back up; fast. If you want to try it on your own follow the following steps,

1. Turn on debugging via wp-config.php
2. Check and clean /wp-content/ for leftover cache-related files
3. Avoid Redis unless you’re on VPS or managed WordPress hosting with Redis enabled
4. Use lightweight and compatible caching plugins like:
   • LiteSpeed Cache (for LiteSpeed hosting)
   • WP Super Cache (for shared Apache/Nginx servers)