Switching Off a Broken Theme From the Database

Editing the database is the third option, not the first. A theme that throws a fatal error takes wp-admin down with it, and the instinct is to go straight to phpMyAdmin. Two safer routes usually solve it in less time and with no risk of corrupting anything, so work through them in order.

Try Recovery Mode first

Since the fatal error handler was introduced, WordPress emails the site administrator a Recovery Mode link when a theme or plugin crashes. That link gets you into a working admin session with the offending component paused, where you can switch themes normally.

Check the administrator inbox and its spam folder before anything else. The full procedure, including what to do when the email never arrives, is in the white screen guide.

Then rename the theme folder

This is the fix that deserves to be better known. Over SFTP or the hosting file manager, go to wp-content/themes/ and rename the active theme's directory:

wp-content/themes/broken-theme
wp-content/themes/broken-theme-disabled

WordPress cannot find the theme it was told to load, and falls back to an available default theme such as one of the Twenty-somethings. The site comes back, usually looking plain, and wp-admin works again.

Two conditions apply. A default theme must actually be installed — check the directory listing before you rename anything, because renaming the only theme present replaces one broken site with another. And if a child theme is active, rename the child, not the parent, unless the parent is the thing that is broken.

Or use WP-CLI, if you have SSH

WP-CLI does this properly, through WordPress itself, with all the validation core would normally apply:

wp theme list
wp theme activate twentytwentysix

Run the first command and use a slug it actually reports. This is the cleanest method available and it bypasses wp-admin entirely, so reach for it whenever SSH exists.

What the database is actually storing

If neither route is available — no file access, no SSH, only phpMyAdmin — then the direct edit is justified. Know what you are changing first.

The active theme lives in the options table, which is named with the table prefix set in wp-config.php: wp_options by default, but frequently something else.

These are directory names, not display names. The theme shown as "Twenty Twenty-Six" lives in a folder called something like twentytwentysix, and the folder name is what belongs in these rows. Values are case-sensitive on Linux servers.

On a multisite network, each site has its own options table — wp_2_options, wp_3_options and so on — so make sure you are editing the right one.

Back up before you touch anything

This is not optional advice. A mistyped WHERE clause in an UPDATE statement rewrites every row in the table, and there is no undo.

In phpMyAdmin, select the options table, choose Export, and save a full SQL dump. If the site is large or you have the time, export the whole database — the backup routine is worth having in place regardless.

The query

Confirm the target directory exists under wp-content/themes/ and note its exact name. Then:

UPDATE wp_options
SET option_value = 'twentytwentysix'
WHERE option_name IN ('template', 'stylesheet');

Change the table prefix and the theme slug to match your install. If the previously active theme was a child, this correctly sets both rows to the same standalone fallback.

Prefer editing the two rows individually through the phpMyAdmin interface if you are at all unsure. It is slower and it cannot go catastrophically wrong.

Setting a value that does not correspond to a real directory produces a site that cannot render at all, which is why the existence check comes first.

Afterwards

Flush every cache — a persistent object cache will happily keep serving the old options from memory, and a page cache or CDN will keep serving the old HTML. Clearing caches properly is the step that most often explains "the query ran but nothing happened".

Then log in and confirm the theme shown in Appearance matches reality. If you cannot log in either, adding an administrator through phpMyAdmin is the companion procedure.

Fix the cause, not just the symptom

The theme is off; it is still broken. Read the error log to find out why — an incompatible PHP version and a bad edit to functions.php are the two usual answers.

If the fault was a customisation, that customisation belonged in a child theme, and switching themes deliberately is the process to follow when you reinstate it. If the database itself looks damaged rather than merely wrong, stop editing it and work through repairing the database instead.