Key facts at a glance
WordPress 6.9 in 2026
Last updated
- What it is
- WordPress 6.9 released on December 2, 2025. It is stable and fully compatible with PHP up to 8.5. The breakage came from what it removed, not from a bug in the release.
- What actually broke sites
- Removed long-deprecated code: all Flash support including
swfuploadandswfobject, legacy Internet Explorer code, and deprecated internals around menu walkers, classic widgets, media modals, and the customizer. Old plugins calling them fatal. - The launch-day casualties
- WooCommerce had checkout fatals and cart problems, Yoast SEO sitemaps returned 404s, and the Elementor editor failed to load. All were fixed by updating each plugin to the 6.9-compatible release shipped within days.
- The Abilities API myth
- The headline new feature is additive and backward compatible. WordPress core states it does not affect existing functionality and is not a replacement for
current_user_can. It did not break your site. - Block-internal changes to watch
- The block visibility support key was renamed
blockVisibilitytovisibility, the Paragraph block moved to built-in text alignment, and the Interactivity API changed. These can affect custom and lightly maintained blocks. - The fix in one line
- Read the debug log, find the plugin or theme it names, and update it to its 6.9-compatible release, replace it if abandoned, or roll core back to 6.8 on staging while you wait for a patch. The fix is the extension, not WordPress, which is the supported and secure version. Reverting core is breathing room, not a destination, because 6.8 stops getting security updates.
Source: the WordPress core announcement of the Abilities API in 6.9, the WordPress Abilities API handbook, the WordPress developer notes for December 2025, the WordPress.com developer overview of 6.9, and our hands-on repairs. Get a quote in 60 seconds →
What WordPress 6.9 changed
WordPress 6.9 arrived on December 2, 2025 as a major release, and it is a solid one. It is fully compatible with modern PHP, up to and including PHP 8.5, and it added a long list of editor and developer features. The trouble was not in what it added. It was in what it finally removed. Every major WordPress release retires some code that has been marked deprecated for years, on the reasonable theory that maintainers have had ample warning. 6.9 retired more than usual, and a lot of plugins and themes had not done their homework.
The most concrete removals were old fallback technology. WordPress 6.9 took out all remaining Flash support, including the swfupload and swfobject scripts that the media system had carried for years, and it removed legacy Internet Explorer code. It also retired or changed deprecated internal functions that older code still leaned on, particularly around older menu walkers, classic widgets, media modals, and the customizer. When a plugin or theme calls a function that no longer exists, PHP raises a fatal error, and WordPress shows the critical error page. That is the mechanism behind nearly every 6.9 breakage report.
Because so many sites auto-update WordPress core by default, the failures arrived without warning. A site that was fine on the evening of December 1 could be showing the critical error on the morning of December 2 with nobody having touched it. The owner did not change anything. WordPress removed code that one of their plugins quietly depended on. Understanding that the cause sits in a specific extension, not in WordPress itself, is what makes the fix fast.
- December 2, 2025: WordPress 6.9 released. WooCommerce, Yoast SEO, and Elementor breakage reported within hours.
- Days after launch: major plugin vendors ship 6.9-compatible patches. Less-maintained plugins go quiet.
- Removed in 6.9: Flash support (
swfupload,swfobject), legacy Internet Explorer code, and assorted deprecated internals. - Compatible with PHP 8.5, so 6.9 paired with a host PHP upgrade is a common double hit.
What the Abilities API is and is not
A lot of the early commentary blamed the new Abilities API for the 6.9 breakage, and that is worth correcting because it sends people debugging in the wrong direction. The Abilities API is the marquee new feature in 6.9, but it is additive. The WordPress core team states plainly that it does not affect existing WordPress functionality and that plugins and themes can adopt it incrementally without breaking existing code.
What it actually does is provide a standard registry where plugins, themes, and core can declare their capabilities, their abilities, in a machine-readable format, so that automation tools and AI agents can discover and invoke what a site can do. In 6.9 that means a PHP registration layer with functions like wp_register_ability(), optional REST endpoints under the wp-abilities/v1 namespace, and new hooks. It is opt-in. A plugin has to choose to register abilities to participate.
The Abilities API is not a replacement for the current_user_can permission system, and it does not change how existing permission checks work. If your site broke after updating to 6.9, the Abilities API is not the cause. The cause is a plugin or theme calling a deprecated function that 6.9 removed, which the debug log will name. Spend your time there, not on the new feature.
Which symptom matches yours
Find the row that matches what you see. Each one points at a specific extension and fix.
| Symptom | Most likely root cause |
|---|---|
| The whole site shows the critical error message right after the 6.9 update | A plugin or theme called a function 6.9 removed and threw a fatal. The debug log and recovery email name the file. Update or deactivate that one extension. |
| WooCommerce checkout or cart broke after updating to 6.9 | WooCommerce hit fatals on some setups on launch day. Update WooCommerce to its 6.9-compatible release, which the developer shipped within days of 6.9. |
| Yoast SEO sitemaps started returning 404 after 6.9 | A known launch-day Yoast incompatibility. Update Yoast SEO to its patched 6.9-compatible version and re-save permalinks if the sitemap routes need regenerating. |
| The Elementor editor will not load since the update | Elementor called a function 6.9 removed, so the editor failed to load. Update Elementor to the release that restored compatibility. |
| A custom block lost a feature or stopped rendering | A block-internal change: the visibility key renamed blockVisibility to visibility, the Paragraph block text-align move, or Interactivity API changes. Update the block code or its plugin. |
| Media uploads or an old gallery or slider broke after 6.9 | Likely a plugin depending on the Flash fallback scripts (swfupload, swfobject) that 6.9 removed, or other deprecated media code. Update or replace that plugin. |
| You blamed the Abilities API but cannot find what it changed | The Abilities API is additive and backward compatible, it did not break your site. Look instead for a plugin or theme calling a removed deprecated function in the debug log. |
The four root causes
Every 6.9 breakage traces to one of these four. None of them is WordPress core being broken, and none of them is the Abilities API.
1. A plugin or theme calling a function 6.9 removed
This is the cause behind most critical-error reports. An older plugin or theme calls a deprecated function that 6.9 finally retired, and PHP raises a fatal the moment that code runs. The removed Flash scripts, the legacy Internet Explorer code, and the deprecated internals around menu walkers, classic widgets, media modals, and the customizer are the usual suspects. The debug log names the exact file in the failing plugin or theme. The fix is to update that extension to its 6.9-compatible release, replace it if it is abandoned, or temporarily deactivate it to restore the site.
2. A major plugin that broke on launch and needs its patch
WooCommerce, Yoast SEO, and Elementor all broke for some users on launch day. WooCommerce threw checkout fatals and cart display problems on certain setups, Yoast sitemaps started returning 404s, and the Elementor editor failed to load because it called a function 6.9 removed. These were not subtle, and the vendors patched them quickly. If a heavily used plugin broke, the answer is almost always to update it to the latest version, which restored 6.9 compatibility within days of the release. Update WooCommerce, Yoast, Elementor, and your other major plugins first before assuming anything deeper.
3. A block-internal change affecting custom or stale blocks
6.9 changed some block internals that custom and lightly maintained blocks can trip on. The visibility support key was renamed from blockVisibility to visibility, which collided with the existing Block Visibility plugin, the Paragraph block moved to WordPress built-in text alignment, and the Interactivity API received changes and client navigation improvements. A block built against the old behavior can lose a feature or stop rendering. The fix is to update the block code to the current support keys and Interactivity API, or to update the plugin that supplies the block, since the author likely shipped the same change.
4. An unsupervised auto-update onto an unready site
The reason 6.9 hit so many sites at once is that WordPress auto-updates core by default. A site auto-updated to 6.9 overnight while one of its plugins was still incompatible, and the owner woke up to a broken site they had not touched. This is not a separate bug, it is the delivery mechanism that turned a plugin incompatibility into a surprise outage. The lesson is process: stage major updates rather than letting them apply unsupervised, and keep plugins current so they are ready when core moves. We cover the safe sequence in the fix section.
DIY vs hand it off
When the debug log names one plugin with an available update, this is a quick self-fix. When the offending plugin is custom or abandoned, or you are locked out and unsure, handing it off is faster. If the left column matches you can likely do this. If the right column matches, get help.
Realistic on your own
- ✓The debug log names one plugin and an update is available
- ✓Updating WooCommerce, Yoast, or Elementor resolves it
- ✓You can reach wp-admin, or use the recovery mode email
- ✓You can rename a plugin folder over SFTP to deactivate it
- ✓You have a backup and ideally a staging site
- ✓You are comfortable updating plugins and re-testing
Hand it off, save the time
- ✗The offending plugin is custom or paid with no 6.9 update
- ✗The fatal is in your theme and needs a code fix
- ✗Several plugins fail at once and you cannot order the fixes
- ✗You depend on a plugin with no patch and need a safe rollback
- ✗You are fully locked out and the recovery email is not arriving
- ✗The site is a store losing orders every hour it is down
How to diagnose it
The debug log does most of the work. These steps take you from a broken site to the named cause in a few minutes.
When a fatal happens, WordPress emails a recovery link to the site admin address that loads a dashboard with the failing plugin paused and named. If it arrived, it often tells you the culprit immediately.
If you cannot use recovery mode, enable WP_DEBUG and WP_DEBUG_LOG in wp-config.php with display off, reload the site, and open wp-content/debug.log. The most recent PHP Fatal error names the file, and its path points at the plugin or theme. See our debug log guide for the exact steps.
If the failing path is in a third-party plugin or theme, that is your cause. The Abilities API is additive and does not break existing code, so do not spend time there. The fix is whatever extension the log names.
Look up the named plugin and see whether a newer version is available. Major plugins shipped 6.9 patches within days. If an update exists, that is very likely the whole fix.
On staging, switch to a default theme and deactivate plugins, then re-enable them one at a time, reloading after each. The plugin that brings the failure back is the cause. This catches cases the log does not make obvious.
How to fix it
Each branch stands alone. Pick the one your diagnosis pointed to.
If a plugin has a 6.9-compatible update: update it
This is the most common fix. Update the plugin the log named to its latest version. If you can reach wp-admin, update from the dashboard. If you are locked out, regain access first by renaming the plugin folder over SFTP to deactivate it, log in, update it, then re-activate. For the big three, update WooCommerce, Yoast SEO, and Elementor to their current releases, which restored 6.9 compatibility shortly after launch.
If the plugin is abandoned: replace it
If the offending plugin has no 6.9-compatible release and has not been updated in a long time, treat it as abandoned and swap it for a maintained alternative that does the same job. Deactivate the broken plugin to restore the site, install the replacement, and rebuild whatever the old plugin provided. Holding your whole site on an old WordPress version for one stale plugin is the wrong trade.
If a critical plugin has no patch yet: roll back to 6.8 carefully
When you depend on a plugin that genuinely has no 6.9-compatible version yet, reverting core to 6.8 buys time. Do it safely: take a full backup, roll back on staging or with a trusted rollback plugin, and confirm the site works before applying to production.
Treat this as temporary. WordPress 6.8 will stop receiving security updates over time, so the plan is to move back to 6.9 as soon as the plugin ships its fix, or to replace the plugin. A rollback is breathing room, not a resting place.
If a custom block broke: align it with the 6.9 changes
For a custom block, update its code to the changed block internals: the visibility support key is now visibility rather than blockVisibility, the Paragraph block uses built-in text alignment, and the Interactivity API behavior changed. If the block came from a plugin, update the plugin first, since the author likely already shipped the same adjustment.
Update safely from now on
- Clone the site to staging before any major core update.
- Apply the update on staging and exercise checkout, forms, the editor, and media.
- Update any plugins that need it, and resolve fatals there, not on production.
- Apply to production during a low-traffic window and watch the debug log for an hour.
- Consider disabling unsupervised auto-updates for major core versions, while keeping minor and security updates on.
Locked out, or the offending plugin is custom with no update?
Let us fix it in 2 hours →A real 6.9 recovery session
A composite from the 6.9 repairs we ran after the December 2025 release, with identifying details removed.
A marketing site woke up to the critical error message on December 2, having auto-updated to 6.9 overnight. The owner had read a blog post claiming the new Abilities API was breaking sites and had spent the morning trying to disable it, getting nowhere. The front end and wp-admin were both down.
We enabled the debug log over SFTP and reloaded the homepage. The newest fatal read Uncaught Error ... in /wp-content/plugins/elementor/, a call to a function 6.9 had removed. A second fatal pointed at an old slider plugin using the removed Flash fallback. The Abilities API appeared nowhere in the log, confirming it was a red herring. The real causes were two plugins, one major and one abandoned.
We renamed both plugin folders to get the site back, then updated Elementor to its 6.9-compatible release and re-enabled it cleanly. The abandoned slider had no update, so we replaced it with a maintained block slider and rebuilt the two sliders that used it. We also updated Yoast SEO, which had a sitemap fix in its latest version. The site was fully restored on 6.9, on a supported and secure version, with no rollback needed.
When to stop and hand it off
Four situations where DIY costs more than help. First, the fatal is in a custom theme or a paid plugin with no 6.9 update, so the only fix is editing code on a live site. Second, several plugins fail at once and you cannot tell which to fix first or in what order. Third, you depend on a plugin with no patch and need a safe rollback to 6.8 done without losing data. Fourth, you are fully locked out and the recovery email is not arriving. We read the log, identify every broken extension, update or replace each one, roll back safely only if a plugin genuinely needs it, and leave you on the supported version. Flat $49 to $149, done in two hours when scope fits, money back if we cannot.
Get a quote in 60 secondsWordPress 6.9 FAQ
Did WordPress 6.9 itself break my site, or is it a plugin?
Almost always a plugin or theme, not WordPress core. WordPress 6.9, released December 2, 2025, is itself stable and fully compatible with PHP up to 8.5. What it did was remove a batch of long-deprecated code and change a few internal behaviors, and any plugin or theme that still relied on the old code threw a fatal error the moment 6.9 went live. So the update did not introduce a bug, it exposed plugins and themes that had fallen behind. The practical consequence is that the fix is almost never to blame or revert WordPress, it is to find the specific extension that broke and update or replace it. The debug log names the exact file, which turns this from guesswork into a one-line diagnosis.
What actually got removed or changed in 6.9 that breaks older code?
The headline removals were old fallback code. WordPress 6.9 stripped out all remaining Flash support, including the swfupload and swfobject scripts from the media system, and removed legacy Internet Explorer code. It also changed some block internals: the block visibility support key was renamed from blockVisibility to visibility, which collided with the existing Block Visibility plugin, and the Paragraph block moved to WordPress built-in text alignment. Beyond those specifics, 6.9 removed or modified several deprecated internal functions that older themes and plugins still called, particularly around older menu walkers, classic widgets, media modals, and the customizer. A plugin that depended on any of these can fatal until it ships a compatible release.
Everyone says the Abilities API broke everything. Is that true?
No, and this is the most common misunderstanding about 6.9. The Abilities API is the headline new feature in 6.9, but it is additive and backward compatible. The WordPress core team states directly that it does not affect existing WordPress functionality and that plugins can adopt it incrementally without breaking existing code. It is a new registry that lets plugins, themes, and core declare their capabilities in a machine-readable way, mainly so automation tools and AI agents can discover what a site can do. It is not a replacement for the current_user_can permission system, and it does not change how existing permission checks work. So if your site broke after 6.9, the Abilities API is not the cause. The cause is a plugin or theme calling one of the deprecated functions that 6.9 removed. Blaming the Abilities API sends people debugging in the wrong direction.
WooCommerce, Yoast, or Elementor broke right after I updated. What do I do?
Those three were among the most visible casualties on launch day. WooCommerce saw checkout fatals and cart display problems on some setups, Yoast SEO sitemaps returned 404s, and Elementor's editor failed to load because it called a function 6.9 removed. In every case the fix was the same: update the plugin to the 6.9-compatible release its developer shipped in the days after launch. Major plugin vendors patched quickly. So the first move is to update WooCommerce, Yoast SEO, Elementor, and any other heavily used plugin to their latest versions. If you updated WordPress core through an auto-update and a plugin had not yet caught up, you may need to update that plugin manually over SFTP or temporarily roll core back while you wait for the patch.
I am locked out of wp-admin after the update. How do I even start?
A fatal during the update can take down the dashboard along with the front end. WordPress emails a recovery mode link to the site admin address when a fatal happens, which loads a special dashboard with the failing plugin paused, so check that inbox first. If you cannot use the link, you can still diagnose without the dashboard. Enable the debug log by editing wp-config.php over SFTP, then reload the site once and read wp-content/debug.log, where the most recent fatal names the exact plugin or theme file. To regain admin access immediately, rename the offending plugin folder over SFTP to deactivate it. Once you are back in, update that plugin to its 6.9-compatible version and re-enable it.
Should I just roll WordPress back to 6.8?
Rolling back is a legitimate temporary measure, not a destination. If a critical plugin you depend on has no 6.9-compatible release yet, reverting core to 6.8 on a tested basis gets you running again while you wait. Do it carefully: take a full backup first, roll back on staging or with a rollback plugin, and confirm the site works before applying to production. The catch is that 6.8 will eventually stop receiving security updates, and staying on it leaves you exposed, so treat the rollback as breathing room. The better long-term path for most sites is to update the offending plugin, replace it if it is abandoned, and move forward on 6.9, which is the supported and secure version.
How do I update safely so this does not happen again?
Test major core updates on staging before they reach production, and stage them rather than letting auto-updates apply a major version unsupervised. The pattern that caused most 6.9 emergencies was a site auto-updating to 6.9 overnight while a plugin was still incompatible, so the owner woke up to a broken site they had not touched. Before a major update, clone the site to staging, apply the update there, exercise every important flow including checkout, forms, and the editor, update any plugins that need it, and only then apply to production. Keeping plugins and themes current in general is the single best protection, because the plugins that broke on 6.9 were the ones that had drifted out of maintenance.
A custom block I built stopped working in 6.9. Why?
Custom and lightly maintained blocks are sensitive to the block-internal changes in 6.9. Two specific ones bite: the visibility support key changed from blockVisibility to visibility, so a block relying on the old key needs updating, and the Paragraph block moved to WordPress built-in text alignment, which can change how alignment is applied. The Interactivity API also received changes and client navigation improvements that can affect blocks built against the prior behavior. If your block stopped rendering or lost a feature, align its code with the current block support keys and the updated Interactivity API. If the block came from a plugin, update that plugin first, since the author likely shipped the same fix.
Sources and further reading
Every claim on this page traces back to the WordPress core announcements and developer documentation for 6.9, or the WordPress.com developer overview.