# Recovering from a Broken Object Cache Drop-in
> HTTP 500 on every page, including wp-admin, after enabling ForgeCache Object Cache: recovery via SSH, cPanel File Manager or a host ticket, plus the fix.
- Canonical:
- Last updated: 2026-09-08
- HTML version:
---
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.
### This doc only applies if you enabled Object Cache
If your site went down and you did **not** recently enable *ForgeCache → Settings → Object Cache*, this isn’t the right recovery guide. Try [JS / CSS Optimization Broke My Site](https://royalplugins.com/support/forgecache/css-js-optimization-broke-my-site/) or [Site got slower after activation](https://royalplugins.com/support/forgecache/site-got-slower-after-activation/). This doc is specifically for the “every page returns HTTP 500 immediately after enabling Object Cache” case.
## 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](mailto: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](https://my.royalplugins.com/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](https://my.royalplugins.com/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](mailto: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](https://royalplugins.com/support/forgecache/) — back to the main support page.
- [**Site got slower after activation**](https://royalplugins.com/support/forgecache/site-got-slower-after-activation/) — different problem class (site loads but slow), different fix path.
- [**JS / CSS optimization broke my site**](https://royalplugins.com/support/forgecache/css-js-optimization-broke-my-site/) — if enabling a Defer / Delay / Critical CSS toggle broke rendering rather than throwing a 500.
- [**WooCommerce caching issues**](https://royalplugins.com/support/forgecache/woocommerce-caching-issues/) — cart / checkout / mini-cart problems.