Recovering from a Broken Object Cache Drop-in

If you enabled the Object Cache option in ForgeCache and now every page on your site — including /wp-admin/ — returns HTTP 500 with a “critical error” message, this doc walks through recovery. Three paths depending on what access you have (SSH, cPanel / File Manager, or host support ticket), plus the upgrade step that keeps it from happening again. Expected recovery time: under 10 minutes for SSH, under 30 minutes for File Manager, 1–4 hours if you have to file a host ticket.

Confirm This Is the Bug You’re Hitting

All three symptoms below must match. If any don’t, this isn’t the right recovery guide.

Every page including /wp-admin/ returns HTTP 500 (or a WordPress “There has been a critical error on this website” page).
It started immediately after enabling Object Cache in ForgeCache settings (or after an auto-update installed ForgeCache 2.1.32 with the option already on).
You have Redis or Memcached available on the server (that’s the prerequisite for the option turning on in the first place).

If you can read your error log, confirm the exact fatal

WordPress writes fatal errors to wp-content/debug.log if WP_DEBUG_LOG is enabled, and to your PHP-FPM / Apache error log otherwise. If you can access either, grep for:

Cannot declare class WP_Object_Cache, because the name is already in use

Seeing that line confirms this doc applies. If your error log shows a different fatal, this isn’t the right recovery guide — contact your host with the error text or email support@royalplugins.com.

Two files need to move + one line in wp-config.php needs deleting

All three recovery paths below delete the same two files (wp-content/object-cache.php and wp-content/advanced-cache.php) and remove one line from wp-config.php. Pick the path that matches your access. Save a backup of each file before touching it.

Path A — SSH Access (Fastest, ~5 min)

If you can SSH into the server and run WP-CLI, this is the cleanest recovery. Substitute /var/www/YOUR-SITE with your actual WordPress root.

Connect + set a variable for your WP root

ssh user@your-server
WP=/var/www/YOUR-SITE

The WP variable is used in every command below so you can copy-paste the whole block.

Try WP-CLI first (it might work if only some request paths fatal)

sudo -u www-data wp plugin deactivate forgecache --path=$WP

If that succeeds, ForgeCache is off and step 3 below cleans up the leftover files. If it also fatals (very likely — WP-CLI bootstraps the same failing code path as a web request), skip straight to step 3.

Move the two ForgeCache drop-ins aside

mv $WP/wp-content/object-cache.php   $WP/wp-content/object-cache.php.bak
mv $WP/wp-content/advanced-cache.php $WP/wp-content/advanced-cache.php.bak

Move, don’t delete. The .bak copies let you compare if you need to file a support ticket. Remove them permanently once the site is stable.

Remove the ForgeCache-added WP_CACHE line from wp-config.php

sed -i.bak "/define('WP_CACHE', true); \/\/ Added by ForgeCache/d" $WP/wp-config.php

This deletes only the exact line ForgeCache added (marked with the // Added by ForgeCache comment). Other define() lines in wp-config.php are untouched. The -i.bak flag writes a backup as wp-config.php.bak before editing — keep it until the site is verified working.

Purge the ForgeCache page cache directory

rm -rf $WP/wp-content/cache/forgecache/

Removes the pre-broken cached HTML so the next request rebuilds from scratch.

Verify the site returns 200

curl -s -o /dev/null -w "%{http_code}\n" https://YOUR-SITE.com/
curl -s -o /dev/null -w "%{http_code}\n" https://YOUR-SITE.com/wp-login.php

Both should print 200 (or 302 for wp-login if it redirects). If you see 500, either the file paths above didn’t match your install (WordPress may live under a subdirectory), or you have a different fatal — check the debug log again.

Update ForgeCache to 2.1.33 or later

Log in to /wp-admin/, go to Plugins, and update ForgeCache if an update is available. If you don’t see one, download the 2.1.33 zip from your My Account page and upload via Plugins → Add New → Upload Plugin. Once on 2.1.33+ you can safely re-enable Object Cache — the new version prevents the option from turning on unless the drop-in install can actually complete cleanly.

Why WP-CLI usually fatals on step 2

WP-CLI runs the same WordPress bootstrap sequence as a web request, so the same fatal fires. Step 3 (moving the file directly) bypasses WordPress entirely and always works.

Path B — cPanel or Host File Manager (~15 min)

If your host provides a web-based File Manager (cPanel, Plesk, DirectAdmin, SiteGround Site Tools, Cloudways, etc.), you can do the same cleanup from a browser.

Open the File Manager and navigate to wp-content

Log in to your hosting panel, open File Manager, and navigate to the folder containing your WordPress install — usually public_html/, then into wp-content/.

Rename object-cache.php

In wp-content/, right-click object-cache.php and choose Rename. Rename it to object-cache.php.bak. Do not delete — the .bak is your backup.

Rename advanced-cache.php

Same step: right-click advanced-cache.php, rename to advanced-cache.php.bak.

Edit wp-config.php to remove the WP_CACHE line

Navigate up one level to the WordPress root. Right-click wp-config.php and choose Edit (or Code Editor if offered). Find this line:

define('WP_CACHE', true); // Added by ForgeCache

Delete that entire line. Save the file. Leave every other define() line alone.

Delete the ForgeCache cache folder

Back in wp-content/, open the cache/ folder, right-click the forgecache/ subfolder, and choose Delete.

Reload your site to verify

Open your homepage in a new browser tab (or force-refresh). It should load normally. Then log in to /wp-admin/ and update ForgeCache to 2.1.33 or later via Plugins → Update.

Filename showing as hidden?

Some File Managers hide files starting with a dot but show all .php files normally. The two drop-in files (object-cache.php, advanced-cache.php) should both be visible without changing any “show hidden files” setting. If you don’t see them, you may be looking at the wrong wp-content/ directory — check that the path shown at the top of the File Manager includes your site’s WordPress root.

Path C — Host Support Ticket (Managed / No File Access)

If you’re on a fully-managed host (many WP Engine, Kinsta, Cloudways, Pantheon plans) or you don’t have SSH or File Manager access, your host’s support team can do the fix in one ticket. Every host that supports WordPress hosting has done this cleanup before — it’s a standard drop-in recovery.

Copy-paste this into your host support ticket

Hi — I need help recovering from a broken WordPress object-cache drop-in. Please: 1. Delete or rename the file wp-content/object-cache.php 2. Delete or rename the file wp-content/advanced-cache.php 3. Edit wp-config.php and delete the line: define('WP_CACHE', true); // Added by ForgeCache Leave every other define() line unchanged. 4. Delete the folder wp-content/cache/forgecache/ if it exists. The site should return HTTP 200 immediately after these four steps. I’ll take it from there — the ForgeCache developer has published a fixed plugin version (2.1.33) that I’ll install once the site is reachable again. Site URL: https://YOUR-SITE.com/ Login username: (I can share via your secure channel) Thanks.

Typical response time

SLA-managed hosts (Kinsta, WP Engine, Pagely, etc.): 15–60 minutes. Standard shared hosts (SiteGround, Bluehost, etc.): 1–4 hours. Cheaper shared hosts: within 24 hours. If it’s critical, request that the ticket be marked urgent — a fully-500’d site is a standard urgent-priority reason.

After Recovery — Prevent This From Happening Again

Once your site is back to 200, update ForgeCache to 2.1.33 or later before you re-enable Object Cache.

Update ForgeCache to 2.1.33+

WP-Admin → Plugins → find ForgeCache → Update Now. If your license expired or the update doesn’t appear, download the current zip from My Account and upload via Plugins → Add New → Upload Plugin (overwrite when prompted).

Re-enable Object Cache safely (optional)

On 2.1.33+, if you toggle Object Cache on and any of the prerequisites are missing (Redis/Memcached extension, WP_REDIS_HOST or WP_MEMCACHED_SERVERS constant, or writable wp-content/), the toggle refuses to save and shows a specific admin notice explaining what’s missing. The failure mode that took your site down cannot recur.

Remove the .bak files

After a day or two of confirmed stability, delete the object-cache.php.bak, advanced-cache.php.bak, and wp-config.php.bak files you created during recovery. They’re harmless left in place but they clutter wp-content/.

Prevention Baked into 2.1.33

Update to ForgeCache 2.1.33 or later before you re-enable Object Cache. Three changes in that release cover the entire failure mode:

The pre-enable guard refuses to save the toggle unless every prerequisite is verified in place (Redis or Memcached extension loaded, host constant defined, wp-content/ writable, test-write succeeds). If any check fails the option won’t enable and a specific admin notice explains what’s missing.
The install path itself was rewritten to be fully compatible with WordPress’s cache-loading contract, so a saved-on toggle always produces a working drop-in.
An auto-heal check on next page load detects any leftover drop-in from a prior release and replaces it in place — no customer action required once 2.1.33 is installed.

Still Stuck? Email Priority Support

If none of the three paths above worked or you hit a different fatal partway through recovery:

Email support@royalplugins.com. Priority email support is included with your ForgeCache Pro license — typical response time is within 24 hours; mark the email [URGENT — site down] in the subject and we’ll bump priority.

Include in your email

Your site URL.
Which recovery path you tried (A / B / C) and which step it failed on.
The exact error message from your browser or server error log.
Your host name (SiteGround, Kinsta, DreamHost, etc.) — recovery steps differ slightly on some managed hosts.
Whether you can currently reach /wp-admin/ at all.

Related ForgeCache docs

ForgeCache Documentation — back to the main support page.
Site got slower after activation — different problem class (site loads but slow), different fix path.
JS / CSS optimization broke my site — if enabling a Defer / Delay / Critical CSS toggle broke rendering rather than throwing a 500.
WooCommerce caching issues — cart / checkout / mini-cart problems.