WordPress 6.9 Broke My Site: Getting Back Up Before Debugging

When a WordPress core update takes your site down, the first move is not to debug it. It is to get back to the last state that worked. Debugging a broken production site while it is broken is the slowest possible way to fix it, and every minute spent on it is a minute the site is offline.

That ordering — restore first, diagnose second — is the whole of the advice, and it is the part people skip because a fix feels close. It rarely is. Core updates that break sites almost never break because of core; they break because a plugin or theme relied on something core changed, and finding which one takes longer than a rollback does.

Table of contents

• Get the site back first
• If you cannot get into wp-admin
• Reading the actual error
• Why this keeps happening
• The process that makes this a non-event
• Rollback as a normal operation
• How this fits the rest of the stack
• FAQ

Get the site back first

If you have a recent backup and a one-click restore, use it now and read the rest of this afterwards. That is the fastest path and nothing below beats it.

If you do not, the next fastest thing is to downgrade core. WordPress keeps every release available, and the rollback is a file replacement:

1. Download the previous release from the WordPress.org release archive.
2. Put the site in maintenance mode if you can.
3. Replace wp-admin and wp-includes wholesale with the versions from the older release. Do not merge — delete and replace, or you get a mix of two versions, which is worse than either.
4. Replace the loose files in the site root except wp-config.php and the .htaccess file.
5. Leave wp-content entirely alone. Your themes, plugins, and uploads live there.

The two rules that matter: never touch wp-content, and never touch wp-config.php. Everything else in a WordPress install is replaceable core files.

If you have WP-CLI available, this is one command instead of the above, and it is much harder to get wrong:

wp core update --version=6.8.2 --force

If you cannot get into wp-admin

A fatal error often locks you out of the dashboard too, which rules out the usual plugin-deactivation route. You can still deactivate plugins from outside WordPress.

The file-based method, which needs only a file manager or SFTP:

1. Rename wp-content/plugins to wp-content/plugins-off. WordPress finds no plugins and deactivates all of them.
2. Load the site. If it comes back, a plugin is the cause.
3. Rename the folder back to plugins. Every plugin stays deactivated.
4. Reactivate them one at a time from the dashboard, loading the site between each, until it breaks again.

The one that breaks it is your answer. This is tedious and completely reliable, which beats clever on a site that is down.

If deactivating every plugin does not fix it, switch the theme. Rename the active theme’s folder and WordPress falls back to a default theme. If that fixes it, the theme is the problem — and a theme that breaks on a core update usually means a function it relied on was removed.

With WP-CLI, both of these are faster:

wp plugin deactivate --all
wp theme activate twentytwentyfour

Reading the actual error

A white screen is PHP hitting a fatal error with display_errors off. The error exists; you are just not being shown it. In wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Reload the site and read wp-content/debug.log. A fatal error from a core update names a file, and that file tells you which plugin or theme is at fault:

PHP Fatal error: Uncaught Error: Call to undefined function wp_some_removed_function()
in /wp-content/plugins/some-plugin/includes/class-thing.php:214

That is the whole diagnosis. The plugin called a function core removed. There is no fix on your side beyond updating the plugin, replacing it, or staying on the previous core version until its author ships a fix.

WP_DEBUG_DISPLAY set to false matters here — it keeps stack traces out of the page while still logging them. And turn the whole lot off once you are done; a readable debug.log on a live site leaks paths and sometimes credentials.

Why this keeps happening

The pattern behind almost every broken core update is the same. A plugin used something that was internal, deprecated, or undocumented. Core changed it. The plugin broke.

This is why the plugins that break are disproportionately the big ones — page builders, SEO suites, commerce platforms. They do the most, so they touch the most surface area, so they have the most to break. It is not a sign they are badly built; it is a consequence of how much they do.

It also means the fix is rarely yours to make. Once you have identified the plugin, your options are to update it, remove it, or wait. Patching a plugin’s source yourself works until the next plugin update overwrites your change.

The honest framing: your job is not to prevent plugin authors from having bugs. It is to make sure their bugs cannot take your site down without warning.

The process that makes this a non-event

Everything above is recovery. The reason it is stressful is that it happens on production with no rehearsal. Four changes remove most of that:

1. Turn off automatic major core updates. WordPress auto-updates minor releases by default, which is good — those are security fixes. Major version auto-updates are what put an untested release on your live site at 3am.
2. Have a staging copy. Update staging first, click through the site, then update production. This catches the overwhelming majority of these failures before a visitor sees them.
3. Wait a week on major releases. The plugin ecosystem shakes out compatibility fast. A week of other people finding the problems is free.
4. Verify your backups restore. Not that they run — that they restore. The difference is discovered at the worst possible moment.

The staging step is the one that does the most work. A core update on a staging copy that breaks is a Tuesday afternoon annoyance; the same update on production is an outage.

Rollback as a normal operation

The deeper point in all of this: the ability to undo a deploy quickly is worth more than the ability to debug it quickly. If reverting to the previous known-good state is a five-minute file-shuffling exercise, you will always be tempted to debug first because debugging feels faster. If reverting is one action, you will always revert first — which is correct.

That is true well beyond WordPress. Any deployment process where the last working version is one click away changes how you respond to a bad release, because the pressure to find the cause while the site is down disappears.

The equivalent question for your own setup: if the next update breaks the site, how long does it take to get back to the version that worked? If the answer is more than a few minutes, that is the thing worth fixing before the next update, not after.

How this fits the rest of the stack

The difference between a broken update being an incident and being an annoyance is almost entirely how fast you can get back to the last working version. Managed WordPress on RunxBuild includes a file manager and a database browser in the dashboard, so replacing core files or checking a table does not start with hunting for SFTP credentials, and deploy history means the previous version is something you select rather than reassemble. WordPress plans start at $3 a month; if you want to see that next to the database and bandwidth for a full site, the RunxBuild hosting calculator totals it as line items.

Useful related references:

• PostgreSQL permission denied for schema public: The PG15 Change That Broke Your Script
• WordPress Hosting for Agencies: White-Label, Multi-Site, and the Reseller Model
• Deploy a Next.js Static Site for Free
• Services on RunxBuild

FAQ

How do I roll back a WordPress core update?

Replace wp-admin, wp-includes, and the root files with the previous release from the WordPress.org archive, leaving wp-content and wp-config.php untouched. With WP-CLI it is a single command: wp core update —version=6.8.2 —force.

How do I deactivate plugins when I cannot log in?

Rename wp-content/plugins to wp-content/plugins-off using a file manager or SFTP. WordPress finds no plugins and deactivates all of them. Rename it back and reactivate one at a time to find the culprit.

Why is my site showing a blank white screen?

A white screen is a PHP fatal error with error display turned off. Enable WP_DEBUG and WP_DEBUG_LOG in wp-config.php, reload, and read wp-content/debug.log — the fatal error names the file and therefore the plugin or theme responsible.

Should I disable automatic WordPress updates?

Disable automatic major version updates, but keep minor ones enabled — those are security patches and you want them. Major releases are the ones worth testing on a staging copy first.

Is it safe to delete wp-content during a rollback?

No, never. wp-content holds your themes, plugins, and every uploaded file. A core rollback replaces wp-admin, wp-includes, and the root files only. wp-content and wp-config.php must be left alone.