WordPress Theme Broke Your Site: Switch to a Default Theme Without wp-admin

What’s actually happening when a theme breaks WordPress

When a theme breaks a WordPress site, it’s rarely mystical. It’s usually a straightforward operational failure: PHP can’t execute some code the theme depends on, WordPress can’t load the active template, or something in the request path (cache, CDN, PHP-FPM, database) is hiding the real error.

The common mechanics

• Fatal error in theme PHP (often functions.php or a bundled framework): PHP halts and WordPress can’t render either the frontend or admin.
• Missing dependencies: theme expects a plugin, a PHP extension, or a specific PHP version feature.
• Filesystem mismatch: theme folder renamed, partial upload, permissions wrong, or deployment left you with half old/half new.
• Template points to a theme that isn’t there: WordPress stores active theme selection in the database; if it points to something missing, you get chaos.
• Cache lies to you: page cache serves the old good page while admin still dies—or the reverse, which is how you get paged at 02:13.

The goal here is not “fix the theme.” The goal is “restore service quickly.” Once you’re back online with a default theme, you can debug the broken theme without a production incident breathing down your neck.

One quote worth keeping in your pocket, especially when you’re tempted to tinker in production: “Paraphrased idea” — Gene Kranz: tough and competent; stay disciplined under pressure.

Joke #1: A broken theme is like a bad haircut—you can pretend it’s fine, but your customers will still notice.

Fast diagnosis playbook (first/second/third checks)

If you have five minutes before someone escalates, don’t wander. Run this playbook. You’re trying to answer one question: Is this a theme-level PHP failure, or an infrastructure bottleneck masquerading as one?

First: confirm it’s really the theme and not the platform

1. Check web server error logs for PHP fatals (Nginx/Apache + PHP-FPM). If you see a theme file in the stack trace, you’re done diagnosing.
2. Check the HTTP status and response body. 500 with “critical error” or blank output strongly suggests PHP fatal. 502/504 suggests upstream (PHP-FPM) meltdown or timeout, which may still be theme-caused.
3. Check PHP-FPM status / slowlog. A theme can trigger runaway CPU or recursion until you hit timeouts.

Second: verify the active theme selection

1. Query wp_options for template and stylesheet. If they point to a theme directory that doesn’t exist, fix that first.
2. List installed themes with WP-CLI (if available). If WP-CLI can’t bootstrap, fall back to database edit or filesystem rename.

Third: restore service with the least invasive method

1. WP-CLI activate a default theme (fast, clean, reversible).
2. DB edit the two theme options (works even when PHP is too broken for WP-CLI).
3. Filesystem rename the broken theme directory (crude, but forces WordPress to fall back).

Decision rule: if you can run WP-CLI without it dying, use WP-CLI. If WordPress bootstrap explodes, go straight to the database. If you don’t have database access, rename theme files. Don’t spend 40 minutes “trying one more thing” while the site is down.

Interesting facts and context (yes, themes have history)

• Theme choice lives in the database: WordPress stores it in options named template and stylesheet. This is why a missing folder can brick the site.
• “Twenty *” default themes are more than decoration: they’re a supported baseline for compatibility and recovery. They’re the WordPress equivalent of a spare tire.
• WordPress introduced a “fatal error protection” feature that can sometimes disable a broken plugin/theme and email an admin. It’s helpful, but it’s not a guarantee—especially if mail is broken or the error occurs too early.
• The child theme mechanism is just directory pointers: the “parent” is referenced inside the child theme’s style.css. A missing parent can take the whole theme down.
• Early theme ecosystems encouraged bundling everything (custom frameworks, page builders). That’s why modern theme failures often look like dependency explosions.
• WP-CLI exists because operating WordPress via web UI doesn’t scale. It’s been a staple for SRE-ish WordPress operations for years.
• Many managed hosts disable direct file edits in the admin for safety. The upside: fewer self-inflicted wounds. The downside: you need SSH/CLI skills when things break.
• Caching layers can “preserve” a broken deployment for minutes to hours. This makes incidents confusing: some users see a healthy site, others hit the broken origin.

Before you touch anything: access, backups, and guardrails

Switching themes sounds harmless until you realize it can trigger widget resets, menu changes, customizer settings mismatches, and layout regressions. You still do it. Because uptime beats aesthetics. But you do it with guardrails.

What you need

• SSH access to the server or container running WordPress, or at least to the shared hosting shell.
• Database access (MySQL/MariaDB credentials from wp-config.php or environment variables).
• A known-good default theme installed (e.g., twentytwentyfour, twentytwentythree). If it’s not installed and the admin is dead, you may need to upload it manually.
• Enough permissions to rename directories in wp-content/themes or to run WP-CLI.

Guardrails you will thank yourself for

• Snapshot/backup of database and wp-content before changes. If you can’t snapshot, at least dump the two option values before editing them.
• Read-only mindset first: confirm what’s active, what exists on disk, what errors are thrown. Then change one thing.
• Log what you did (ticket note, chat update, or a local text file). Future-you counts as a stakeholder.

Path A: Fix it with WP-CLI (best case)

WP-CLI is the cleanest way to flip the active theme because it updates the right options and can validate what’s installed. The catch: WP-CLI bootstraps WordPress. If your theme fatal error happens during bootstrap, WP-CLI may die too. Try it anyway; if it fails, don’t fight it—switch methods.

What “success” looks like

• You can run wp theme list without a fatal error.
• You activate a default theme and the site returns (even if ugly).
• You confirm both frontend and /wp-admin/ load.

Path B: Fix it by editing the database (phpMyAdmin or CLI)

If WordPress can’t execute enough PHP for WP-CLI to run, the database is your control plane. WordPress reads the active theme name from wp_options (or a different prefix) and then loads the corresponding directory under wp-content/themes.

In practice, you change two options:

• template — the parent theme directory name
• stylesheet — the active theme directory name (child theme if used)

Set both to a default theme directory name like twentytwentyfour. If you’re unsure what’s installed, list directories on disk first.

Path C: Fix it by moving theme files (last-resort but effective)

If you can’t access the database quickly (or credentials are missing in the heat of the moment), you can force WordPress to stop loading the broken theme by renaming its directory. When WordPress can’t find the active theme folder, it usually falls back to another installed theme.

This is not elegant. It is effective. Operations is full of these uncomfortable truths.

Multisite and managed hosting wrinkles

Multisite: network-enabled themes vs site-activated themes

In multisite, themes are “enabled” network-wide, but individual sites choose which enabled theme to use. The active theme for each site is stored in that site’s options table (e.g., wp_2_options for site ID 2) unless you’ve got unusual table mapping.

Decision rule: if only one subsite is broken, you’re editing the options for that blog ID, not the main site. If the whole network is broken, start with the main site options and confirm whether a MU-plugin or network-level customization is involved.

Managed hosting: limited shells and aggressive caching

Some platforms give you WP-CLI but not raw MySQL CLI. Others give you phpMyAdmin but no SSH. Some sit behind caching layers that ignore your changes until you purge. Your method depends on what’s available. Don’t be sentimental about tools.

Practical tasks (12+): commands, outputs, and what you decide next

Below are the tasks I actually run in production incidents. Each one includes: a command, what typical output means, and the decision you make next. These are not “nice to have.” They’re how you stop guessing.

Task 1: Confirm you’re on the right host and in the right directory

cr0x@server:~$ hostname -f; pwd; ls -la
wp01.prod.example.internal
/home/cr0x
total 32
drwxr-xr-x  4 cr0x cr0x 4096 Jan 12 09:10 .
drwxr-xr-x  3 root root 4096 Jan 10 18:22 ..
drwx------  2 cr0x cr0x 4096 Jan 12 09:10 .ssh
-rw-r--r--  1 cr0x cr0x  220 Jan 10 18:22 .bash_logout
-rw-r--r--  1 cr0x cr0x 3771 Jan 10 18:22 .bashrc
-rw-r--r--  1 cr0x cr0x  807 Jan 10 18:22 .profile

What it means: You’re not accidentally operating on staging or some forgotten VM.

Decision: If the host is wrong, stop. If right, cd to the WordPress docroot next.

Task 2: Find the WordPress root (docroot) quickly

cr0x@server:~$ sudo find /var/www -maxdepth 3 -name wp-config.php -print
/var/www/html/wp-config.php

What it means: You found the WordPress config. That directory is almost always your root.

Decision: cd /var/www/html and work from there.

Task 3: Verify the active theme folders exist on disk

cr0x@server:~$ cd /var/www/html && ls -1 wp-content/themes
broken-agency-theme
twentytwentythree
twentytwentyfour

What it means: You have at least one default theme installed. Good—recovery won’t require uploads.

Decision: If no default theme exists, you may need to upload or install one via WP-CLI (if possible) before switching.

Task 4: Check the site response and status code from the origin

cr0x@server:~$ curl -sS -D- -o /dev/null http://127.0.0.1/ | head
HTTP/1.1 500 Internal Server Error
Server: nginx
Date: Sat, 27 Dec 2025 10:42:18 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive

What it means: It’s an origin-side failure, not just a CDN glitch. 500 suggests PHP fatal or app error.

Decision: Go to logs to find the fatal and confirm it’s theme-related.

Task 5: Read the web server error log for the smoking gun

cr0x@server:~$ sudo tail -n 30 /var/log/nginx/error.log
2025/12/27 10:42:17 [error] 22140#22140: *1047 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught Error: Call to undefined function add_filter() in /var/www/html/wp-content/themes/broken-agency-theme/functions.php:19
Stack trace:
#0 /var/www/html/wp-settings.php(591): include()
#1 /var/www/html/wp-config.php(90): require_once('...')
#2 /var/www/html/wp-load.php(50): require_once('...')
#3 /var/www/html/wp-blog-header.php(13): require_once('...')
#4 /var/www/html/index.php(17): require('...')
#5 {main}
  thrown in /var/www/html/wp-content/themes/broken-agency-theme/functions.php on line 19" while reading response header from upstream, client: 10.0.4.12, server: _, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/run/php/php8.2-fpm.sock:", host: "example.com"

What it means: The active theme is executing before WordPress is fully loaded or is doing something fundamentally wrong. The stack trace points at the theme.

Decision: Switch to a default theme. Don’t debug the theme while the site is down.

Task 6: Confirm PHP-FPM is alive (avoid misdiagnosing a platform outage)

cr0x@server:~$ systemctl status php8.2-fpm --no-pager | sed -n '1,12p'
● php8.2-fpm.service - The PHP 8.2 FastCGI Process Manager
     Loaded: loaded (/lib/systemd/system/php8.2-fpm.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2025-12-27 09:50:11 UTC; 52min ago
       Docs: man:php-fpm8.2(8)
   Main PID: 1183 (php-fpm8.2)
     Status: "Processes active: 2, idle: 6, Requests: 14321, slow: 0, Traffic: 0req/sec"

What it means: PHP-FPM is running. The 500 is likely app-level, not a dead backend.

Decision: Proceed with theme switching rather than restarting services blindly.

Task 7: Try WP-CLI bootstrap (quick health check)

cr0x@server:~$ cd /var/www/html && wp core version
Error: PHP Fatal error:  Uncaught Error: Call to undefined function add_filter() in /var/www/html/wp-content/themes/broken-agency-theme/functions.php:19
Stack trace:
#0 /var/www/html/wp-settings.php(591): include()
#1 /var/www/html/wp-config.php(90): require_once('...')
#2 /var/www/html/wp-load.php(50): require_once('...')
#3 /var/www/html/wp-cli.php(134): require_once('...')
#4 /usr/local/bin/wp(4): include('...')
#5 {main}
  thrown in /var/www/html/wp-content/themes/broken-agency-theme/functions.php on line 19

What it means: WP-CLI can’t run because WordPress bootstrap loads the broken theme early enough to crash.

Decision: Skip WP-CLI for the switch. Use database edit or filesystem rename.

Task 8: Pull DB credentials from wp-config.php (without leaking them into your scrollback)

cr0x@server:~$ cd /var/www/html && sudo sed -n "1,140p" wp-config.php | sed -n 's/.*DB_.*//p'

What it means: You intentionally didn’t print secrets. Good. Now extract them more carefully.

Decision: Use a safer approach: read the file locally in an editor you trust, or use narrowly-scoped grep and keep output private.

Task 9: Read the table prefix so you don’t edit the wrong table

cr0x@server:~$ cd /var/www/html && grep -n "table_prefix" wp-config.php
78:$table_prefix = 'wp_';

What it means: Your options table is probably wp_options. If it’s different, adjust all queries.

Decision: Use the correct table name. Guessing is how you “fix” nothing and waste an hour.

Task 10: Query current active theme from the database (read-only first)

cr0x@server:~$ mysql -u wpuser -p -h 127.0.0.1 wordpress -e "SELECT option_name, option_value FROM wp_options WHERE option_name IN ('template','stylesheet');"
Enter password:
+-------------+----------------------+
| option_name | option_value         |
+-------------+----------------------+
| template    | broken-agency-theme  |
| stylesheet  | broken-agency-theme  |
+-------------+----------------------+

What it means: WordPress is explicitly configured to use the broken theme.

Decision: Switch both values to a known default theme folder name.

Task 11: Update the active theme to a default (the actual fix)

cr0x@server:~$ mysql -u wpuser -p -h 127.0.0.1 wordpress -e "UPDATE wp_options SET option_value='twentytwentyfour' WHERE option_name IN ('template','stylesheet'); SELECT option_name, option_value FROM wp_options WHERE option_name IN ('template','stylesheet');"
Enter password:
+-------------+------------------+
| option_name | option_value     |
+-------------+------------------+
| template    | twentytwentyfour |
| stylesheet  | twentytwentyfour |
+-------------+------------------+

What it means: The database now points to twentytwentyfour.

Decision: Re-test the site from the origin. If it still fails, the theme wasn’t the only problem.

Task 12: Re-test frontend and wp-admin from the origin

cr0x@server:~$ curl -sS -D- -o /dev/null http://127.0.0.1/ | head -n 5
HTTP/1.1 200 OK
Server: nginx
Date: Sat, 27 Dec 2025 10:45:51 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive

What it means: The site is back. You’re not done, but you’re no longer on fire.

Decision: Check /wp-admin/. Then purge caches so users stop seeing stale errors.

Task 13: Purge/clear common caches (server-side page cache example)

cr0x@server:~$ sudo rm -rf /var/cache/nginx/*

What it means: You cleared Nginx cache if you use it. Your environment might differ.

Decision: If you’re behind a reverse proxy or CDN, also purge there using your platform’s controls.

Task 14: If you must use filesystem rename (no DB access)

cr0x@server:~$ cd /var/www/html/wp-content/themes && sudo mv broken-agency-theme broken-agency-theme.disabled

What it means: WordPress can’t load that theme directory anymore.

Decision: Reload the site. If it comes back, immediately set a valid default theme via DB/WP-CLI so you’re not relying on implicit fallback behavior.

Task 15: Confirm which theme WordPress thinks is active (after recovery)

cr0x@server:~$ mysql -u wpuser -p -h 127.0.0.1 wordpress -e "SELECT option_name, option_value FROM wp_options WHERE option_name IN ('template','stylesheet');"
Enter password:
+-------------+------------------+
| option_name | option_value     |
+-------------+------------------+
| template    | twentytwentyfour |
| stylesheet  | twentytwentyfour |
+-------------+------------------+

What it means: You have an explicit stable configuration.

Decision: Now you can debug the broken theme offline or in staging.

Task 16: Turn on debug logging (briefly) to catch remaining errors

cr0x@server:~$ cd /var/www/html && sudo grep -n "WP_DEBUG" wp-config.php
91:define('WP_DEBUG', false);
92:define('WP_DEBUG_LOG', false);
93:define('WP_DEBUG_DISPLAY', false);

What it means: Debugging is off, which is normal for production.

Decision: If you still see issues after theme switch, enable WP_DEBUG_LOG temporarily and tail wp-content/debug.log. Do not enable display in production.

Joke #2: Turning on WP_DEBUG_DISPLAY in production is a bold strategy—mostly for people who enjoy sharing stack traces with strangers.

Checklists / step-by-step plan

Emergency restore checklist (aim: 5–15 minutes)

1. Confirm the symptom: frontend down, admin down, status codes.
2. Check error logs for a theme file in the stack trace.
3. List installed themes on disk; confirm a default exists.
4. Attempt WP-CLI (wp theme list). If it works, activate default theme via WP-CLI.
5. If WP-CLI fails, edit DB options: set template and stylesheet to default theme directory.
6. Re-test from origin with curl: expect 200.
7. Re-test wp-admin (or at least the login page).
8. Purge caches that could keep serving errors.
9. Communicate status: “Service restored with fallback theme; investigating root cause.”

Stabilize after restore (aim: 30–90 minutes)

1. Identify exactly what changed (theme update, PHP version update, plugin update, deployment artifact).
2. Capture the fatal error stack trace and store it in the incident ticket.
3. Reproduce in staging using the same PHP version and plugin set.
4. Decide: fix theme, roll back theme, or replace theme.
5. Add a pre-deploy check: can WordPress render /wp-login.php and home page after theme changes?

Preventive controls (boring, effective)

1. Keep at least one default Twenty theme installed at all times.
2. Automate DB backups and verify restore works.
3. Use a staging environment that matches production PHP version.
4. Run WP-CLI health commands in CI/CD (or at least on deploy hosts).
5. Track theme and plugin changes like code: changelog, approvals, rollback plan.

Common mistakes: symptoms → root cause → fix

1) Symptom: blank white page (frontend and admin)

Root cause: PHP fatal error with error display off; theme code crashed early.

Fix: Check Nginx/Apache + PHP-FPM logs. Switch theme via DB or WP-CLI. Then inspect the fatal in logs.

2) Symptom: “There has been a critical error on this website”

Root cause: Unhandled exception/fatal; WordPress recovery mode may not engage or email fails.

Fix: Don’t wait for recovery email. Force default theme; then verify mail and recovery mode later.

3) Symptom: 502/504 from proxy, intermittent availability

Root cause: Theme triggers slow execution (infinite loop, heavy queries), exhausting PHP-FPM workers.

Fix: Switch to default theme and watch PHP-FPM stabilize. Then profile the theme in staging; consider slowlog.

4) Symptom: frontend works but /wp-admin/ is broken

Root cause: Admin loads different code paths; theme hooks into admin or loads broken assets.

Fix: Still switch theme. If admin remains broken, disable MU-plugins or suspect a plugin conflict—not the theme alone.

5) Symptom: after switching, site loads but layout is mangled

Root cause: Theme-specific widgets/customizer settings and shortcodes don’t translate to the default theme.

Fix: Accept it temporarily. Your goal is service restoration. Schedule a controlled theme rollback or fix.

6) Symptom: you updated template/stylesheet but nothing changed

Root cause: Wrong table prefix, wrong database, multisite blog ID mismatch, or object cache serving stale options.

Fix: Confirm table_prefix, confirm DB name, and in multisite confirm wp_<blogid>_options. Flush object cache if used.

7) Symptom: theme directory exists but WordPress says it’s missing

Root cause: Permissions/ownership, case sensitivity mismatch, or a symlink/deploy artifact.

Fix: Check file permissions and actual directory names. Normalize case and ownership; ensure PHP user can read.

8) Symptom: switching theme causes immediate redirect loops

Root cause: Theme or plugin enforces canonical URLs or HTTPS incorrectly; caches amplify it.

Fix: Verify siteurl and home options, check proxy headers, and purge caches. Theme switch is necessary but may not be sufficient.

Three corporate mini-stories from the trenches

Incident caused by a wrong assumption: “It’s just a theme, what could it do?”

A mid-sized company ran a marketing WordPress site on a fairly standard stack: Nginx, PHP-FPM, MariaDB. The marketing team bought a premium theme and pushed a “minor update” right before a campaign launch. Nobody expected drama because, in their minds, themes were “CSS and some templates.”

The update bundled a new PHP library and started calling functions that were only available in a newer PHP minor version. Production was one version behind because the ops team was coordinating a larger upgrade window with several unrelated apps. The theme didn’t fail gracefully; it threw a fatal during initialization and took down both the frontend and wp-admin.

The first response was a classic: restart PHP-FPM, restart Nginx, purge cache. It made things fluctuate but didn’t fix anything. The site returned briefly because cached pages served, then collapsed again when uncached URLs hit PHP. Confusion followed, because different people saw different behavior depending on which pages they hit.

The eventual fix was simple: edit wp_options to activate a default Twenty theme. Service returned immediately. Only then did the team notice that the theme update also included an auto-update feature that had rewritten some bundled assets during deployment, leaving the release in a half-updated state.

Afterward, they changed process: theme updates required staging validation against the current production PHP version, not whatever the theme vendor tested last week. Also: default theme stays installed forever. The root cause wasn’t “bad theme.” It was the wrong assumption that themes are harmless.

Optimization that backfired: caching away the truth

An enterprise site had aggressive caching: a reverse proxy cache, a plugin cache, and a CDN. It was fast, and everyone took credit. Then a custom theme release introduced a fatal error on a specific page template used by the homepage.

For some users, the site looked fine because the CDN still had a cached homepage. For others, especially those who hit a cold edge or a different locale path, the origin was contacted and returned a 500. Internally, engineers were split into two camps: “it’s fine” and “it’s down,” which is a great way to waste an hour.

Meanwhile, monitoring was misleading because the health check endpoint was a static URL that stayed cached. The dashboard stayed green while revenue metrics went sideways. The cache didn’t cause the bug, but it made the incident harder to see, harder to reproduce, and harder to trust.

The fix again was the boring one: switch to a default theme via DB update, purge caches in the correct order (origin first, then CDN), and temporarily adjust monitoring to bypass cache. Afterward, they changed health checks to include an uncached request with cache-busting headers and to validate admin reachability separately.

Caching is not the villain. But if your cache can make you blind, it’s not an optimization; it’s a liability wearing a performance badge.

Boring but correct practice that saved the day: default theme + rehearsed rollback

A global org ran WordPress as part of a broader content platform. Nothing fancy: hardened hosts, configuration management, predictable releases. Their runbook for theme changes looked almost comically strict for “a CMS site.”

They always kept two default Twenty themes installed. They always had WP-CLI available on the host. They had a pre-written SQL snippet in the runbook to switch template and stylesheet. And they had a policy: theme releases happened during business hours with a person on call who could SSH and perform rollback.

One day a child theme broke because the parent theme directory name changed in a deployment refactor. It was the kind of mistake that feels stupid afterward and is easy to make during a cleanup. The admin died instantly. The frontend returned 500s on uncached pages.

The on-call engineer followed the runbook: confirm the fatal, set both options to twentytwentyfour, purge the proxy cache, and announce service restored. Total disruption was short. The postmortem was equally boring: add a deploy check verifying that the active theme directory exists and the child theme parent is present.

It wasn’t heroics. It was repetition. In operations, boring is often the highest form of competence.

FAQ

1) Which database values actually control the active theme?

template and stylesheet in the options table. Usually wp_options, unless the table prefix differs or you’re on multisite.

2) What should I set template and stylesheet to?

Set both to the directory name of a known-good theme under wp-content/themes, such as twentytwentyfour. Directory name, not theme display name.

3) Can I fix this by deleting the theme?

You can, but renaming is safer. Deleting destroys evidence and makes rollback harder. Rename the directory to theme-name.disabled and switch explicitly via DB afterward.

4) WP-CLI fails with a fatal error. Is WP-CLI useless here?

WP-CLI depends on WordPress bootstrapping. If the active theme crashes during bootstrap, WP-CLI can crash too. That’s when database edits shine.

5) I switched themes in the DB but the site still shows the old broken page. Why?

Caching. Purge server cache, plugin cache, reverse proxy cache, and CDN cache as applicable. Also consider object caching (Redis/Memcached) holding stale options.

6) Will switching to a default theme delete my content?

No. Posts and pages stay in the database. But your presentation can change drastically: menus, widgets, and theme options may not map cleanly.

7) What if no default Twenty theme is installed and admin is down?

Upload a default theme directory to wp-content/themes from a trusted source via SCP/SFTP or your deployment mechanism. Then set template/stylesheet to that directory name.

8) How does this work on multisite?

Each site has its own options table (e.g., wp_2_options). Switch the theme options for the affected site’s blog ID. Also ensure the target theme is network-enabled.

9) Could a plugin be the real problem instead of the theme?

Yes. But if logs point to theme files, switch theme first to restore service. If the issue persists after theme switch, start disabling plugins (ideally via WP-CLI or database) systematically.

10) Do I need to update theme_mods_* options too?

Usually no for recovery. Those store customizer settings for a specific theme. Leave them alone until you’re stable and investigating data cleanup or reconfiguration.

Conclusion: next steps that prevent the sequel

The fastest way out of a broken-theme outage is to stop trying to “fix the theme” while your users are watching the error page. Switch to a default theme. Restore service. Then debug with oxygen in your brain again.

Do this next, in order

1. Lock in the recovery: verify template/stylesheet point to a default theme and that the directory exists on disk.
2. Capture evidence: save the fatal error stack trace and the exact theme version that caused it.
3. Reproduce safely: test the broken theme in staging with the same PHP version and plugin set.
4. Decide the long-term action: roll back theme, patch theme, or replace it. Don’t negotiate with a theme that keeps trying to take production hostage.
5. Add prevention: keep a default theme installed, add a deploy check for theme directory existence, and make cache-aware health checks.

If you do nothing else, do this: keep one default Twenty theme installed forever. It’s cheap insurance, and unlike most insurance, it actually pays out.