Key facts at a glance
WordPress 7.0 in 2026
Last updated
- What it is
- WordPress 7.0 released on May 20, 2026, after a delay for stability work. It is a major release. Minimum PHP is 7.4, with PHP 8.3 or 8.4 recommended.
- The headline breakage vector
- DataViews replaced the classic Posts, Pages, and Media list screens with a modern React-based interface. Any plugin that modified those list views through legacy hooks is at risk of breaking.
- The general cause
- Like any major release, 7.0 retires deprecated code. An older plugin or theme calling removed behavior throws a fatal and shows the critical error page. The fix is the extension, not core.
- The feature that is not here
- Real-time collaboration was pulled from 7.0 before release over surface area, race conditions, server load, and memory concerns. It is deferred to a later version, so its absence is intended.
- New, but opt-in
- Native AI Connectors under Settings then Connectors let you store credentials for OpenAI, Google Gemini, or Anthropic Claude. Dormant until you add an API key, so it is not breaking anything.
- The fix in one line
- Read the debug log or check the affected admin screen, then update the plugin it points to its 7.0-compatible release, replace it if abandoned, or roll core back to 6.9 on staging while you wait. WordPress is the supported version, the extension is the cause. Reverting is breathing room, not a destination.
Source: the WordPress developer notes for May 2026, the WordPress core 7.0 release schedule announcement, the WordPress PHP compatibility handbook, published 7.0 release coverage of the DataViews redesign, and our hands-on repairs. Get a quote in 60 seconds →
What WordPress 7.0 changed
WordPress 7.0 arrived on May 20, 2026 as a major release, and the core team took extra time to ship it, having delayed it earlier in the year to finish architectural and stability work. It recommends PHP 8.3 or 8.4 and keeps a minimum of PHP 7.4. As major releases go it is a large one, and most of what makes it consequential for site owners is the admin redesign rather than anything on the front end.
The centerpiece is DataViews. The classic Posts, Pages, and Media screens, the list tables that have looked largely the same for over a decade, were replaced with a modern, React-based interface offering grid and list views, inline filtering, and bulk actions without page reloads. That is a genuine improvement to use, but it is also a substantial change to a part of the admin that thousands of plugins customize. Alongside it, like every major release, 7.0 retired some long-deprecated code, which is the usual source of outright fatal errors for plugins and themes that had not kept up.
Because so many sites auto-update WordPress core, the failures arrived without warning. A site that was fine before the update could be showing a broken Posts screen, or the critical error page, the next morning with nobody having touched it. The owner did not change anything. WordPress changed the admin and removed code that one of their plugins depended on. Understanding that the cause sits in a specific extension, not in WordPress itself, is what makes the fix fast.
- May 20, 2026: WordPress 7.0 released, after a delay earlier in the year for stability work.
- DataViews: replaces the Posts, Pages, and Media list screens with a React-based interface.
- Real-time collaboration: removed from 7.0 before release and deferred to a later version.
- PHP: minimum 7.4, recommended 8.3 or 8.4. Pairing 7.0 with a host PHP upgrade is a common double hit.
DataViews, the big breakage vector
If your site broke in the admin rather than on the front end, DataViews is the first thing to suspect, and understanding it makes the fix obvious. For more than a decade, the Posts, Pages, and Media screens were classic list tables, and WordPress gave plugins a set of hooks to customize them: to add a custom column, a bulk action, a row action, or a filter. Huge numbers of plugins use those hooks, everything from SEO tools that add a score column to membership plugins that add a status filter to media plugins that add bulk operations.
WordPress 7.0 replaced those classic list tables with DataViews, a new React-based interface. The published 7.0 coverage is blunt about the consequence: any plugin that modifies the Posts, Pages, or Media list views through the legacy hooks is at risk of breaking. In practice that shows up as a custom column that has vanished, a bulk action that is gone, quick-edit that no longer works, or in the worst case a list screen that errors outright. The plugin is not broken in some deep way, it is simply still speaking to the old list-table system that 7.0 replaced.
If the problem is on the Posts, Pages, or Media screens, the cause is a plugin that customized them, and the fix is to update that plugin to its DataViews-compatible release. Plugin authors moved quickly after the 7.0 launch, so an update is usually available. If a plugin is abandoned and has not been updated for DataViews, replace it with a maintained alternative. This is admin-side, so your public site usually keeps working while you sort it out.
Which symptom matches yours
Find the row that matches what you see. Each one points at a specific cause and fix.
| Symptom | Most likely root cause |
|---|---|
| The whole site shows the critical error message right after the 7.0 update | A plugin or theme called code 7.0 removed and threw a fatal. The debug log and recovery email name the file. Update or deactivate that one extension. |
| The Posts, Pages, or Media screen looks broken, or your custom columns and bulk actions vanished | The DataViews replacement of the classic list tables. A plugin that customized those screens through legacy hooks needs its 7.0-compatible update. |
| Quick edit or inline edit on posts stopped working after updating | Another DataViews effect. The plugin or customization that powered the old list-table editing needs updating for the new React-based screens. |
| A custom admin screen or page-builder admin UI misbehaves since 7.0 | The admin modernization touched the dashboard. Update the plugin that provides that admin UI to its 7.0-compatible release. |
| WooCommerce, Yoast, or a page builder broke on the update | A major plugin that needs its patch. Update it to the latest 7.0-compatible release, which vendors ship quickly after a core launch. |
| You expected real-time collaboration in 7.0 and it is missing | Not a bug. The feature was removed from 7.0 before release over performance and stability concerns and deferred to a later version. |
| New Settings then Connectors or AI options appeared | The new native AI Connectors. Opt-in and dormant until you add an API key, so it is not breaking anything. Safe to ignore if unused. |
The four root causes
Every 7.0 breakage traces to one of these four. None of them is WordPress core being broken.
1. A plugin that customized the Posts, Pages, or Media screens
This is the cause unique to 7.0. DataViews replaced the classic list tables, and a plugin that added a custom column, a bulk action, a row action, or a filter through the old hooks can break under the new interface. The signature is a missing feature on those screens, broken quick-edit, or a list screen that errors, while the rest of the site is fine. The fix is to update that plugin to its DataViews-compatible release, or replace it if it is abandoned.
2. A plugin or theme calling code 7.0 removed
The standard major-version cause. An older plugin or theme calls a deprecated function that 7.0 retired, and PHP raises a fatal the moment that code runs, which WordPress shows as the critical error page. The debug log names the exact file in the failing plugin or theme. The fix is to update that extension, replace it if abandoned, or deactivate it to restore the site while you decide.
3. An admin customization or admin-only plugin
Because 7.0 modernized the dashboard, custom admin screens, page-builder admin interfaces, and plugins that heavily customize wp-admin can misbehave even if the front end is fine. A page builder, a custom dashboard, or an admin UI built against the prior behavior may need its 7.0 update. Update the plugin that provides that admin interface, and if it is a custom build, align it with the new admin.
4. An unsupervised auto-update onto an unready site
The reason 7.0 hit many sites at once is that WordPress auto-updates core by default. A site auto-updated to 7.0 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.
DIY vs hand it off
When the cause is one plugin with an available update, this is a quick self-fix. When the plugin is custom or abandoned, or several break at once, 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
- ✓A broken admin screen traces to one plugin with an available update
- ✓Updating WooCommerce, Yoast, or your page builder resolves it
- ✓The debug log names one plugin and a fix exists
- ✓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
Hand it off, save the time
- ✗A custom plugin or theme customizes the list screens and has no update
- ✗Several plugins break at once and you cannot order the fixes
- ✗The fatal is in your theme and needs a code fix
- ✗You depend on a plugin with no 7.0 update 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
Where it broke tells you where to look. Front-end critical error points at a fatal, an admin-screen problem points at DataViews.
If the public site shows the critical error, you have a fatal, go to the debug log. If the public site is fine but a Posts, Pages, or Media screen is broken or missing features, you have a DataViews plugin issue, go to the plugin checks.
For a fatal, WordPress emails a recovery link to the admin address that loads a dashboard with the failing plugin paused and named. If it arrived, it often identifies the culprit immediately.
If you cannot use recovery mode, enable WP_DEBUG and WP_DEBUG_LOG in wp-config.php with display off, reload, 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.
A missing custom column, filter, or bulk action belongs to a specific plugin, the SEO plugin, the membership plugin, the media plugin. That is the one that needs a DataViews-compatible update. Check it for a newer version.
Update the named plugin to its latest release, which is very likely the whole fix. Major plugins shipped 7.0 and DataViews compatibility quickly. If an update exists, apply it and recheck the screen or reload the site.
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 list screen broke: update the plugin that owns it
Identify the plugin behind the missing column, filter, or bulk action, and update it to its DataViews-compatible release. Most active plugins shipped that update soon after 7.0. If you are locked out of the screen, update the plugin from the Plugins page, which still works, or over SFTP. If the plugin is abandoned with no DataViews update, replace it with a maintained alternative that does the same job.
If a plugin throws a real fatal: update or replace it
Update the plugin or theme the debug log named to its latest 7.0-compatible version. If you are locked out, regain access first by renaming the plugin folder over SFTP to deactivate it, log in, update, and re-activate. If no update exists and the plugin is abandoned, replace it rather than holding the whole site back. For the big plugins, update WooCommerce, Yoast SEO, and your page builder to their current releases.
If a critical plugin has no 7.0 update yet: roll back to 6.9 carefully
When you depend on a plugin that genuinely has no 7.0-compatible version yet, reverting core to 6.9 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. Plan to move back to 7.0 as soon as the plugin ships its fix, or to replace the plugin, since staying on the older version only delays the migration. A rollback is breathing room, not a resting place. For the same recovery pattern on the previous release, see our WordPress 6.9 guide.
Update safely from now on
- Clone the site to staging before any major core update.
- Apply the update on staging and exercise the Posts, Pages, and Media screens, checkout, forms, and the editor.
- Update any plugins that need it, especially ones that customize the admin list screens, and resolve breakage 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 7.0 recovery session
A composite from the 7.0 repairs we ran after the May 2026 release, with identifying details removed.
An editorial team auto-updated to 7.0 and the public site was fine, but the Posts screen was a mess. Their custom workflow-status column was gone, the bulk action they used to assign articles had vanished, and quick-edit no longer worked, which brought their newsroom to a halt. They assumed 7.0 was broken.
Nothing was in the debug log, because nothing had fataled, the front end was healthy. The broken features all lived on the Posts list screen, which 7.0 had replaced with DataViews. The missing column, bulk action, and quick-edit all belonged to their editorial-workflow plugin, which was still customizing the screen through the old list-table hooks that DataViews no longer used. The plugin had shipped a DataViews-compatible update a week after the 7.0 launch, but auto-updates for plugins were off, so it had not installed.
We updated the editorial-workflow plugin to its DataViews-compatible release, and the custom column, the bulk action, and quick-edit all returned on the new screen. We checked the other admin screens, confirmed the SEO and media plugins were also current, and turned plugin auto-updates back on so the team would not fall behind a core release again. No rollback was needed, the site stayed on 7.0 throughout.
When to stop and hand it off
Four situations where DIY costs more than help. First, a custom plugin or theme customizes the Posts, Pages, or Media screens and has no DataViews update, so the only fix is editing code against the new interface. Second, several plugins fail at once and you cannot tell which to fix first. Third, you depend on a plugin with no 7.0 release and need a safe rollback to 6.9 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, adapt custom admin code to DataViews, 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 7.0 FAQ
Did WordPress 7.0 itself break my site, or is it a plugin?
Almost always a plugin or theme, not WordPress core. WordPress 7.0, released May 20, 2026, is a major release and a stable one, recommending PHP 8.3 or 8.4. What it did was change some foundations, most visibly replacing the Posts, Pages, and Media list screens with a new system called DataViews, and like every major release it also retired some long-deprecated code. Any plugin or theme that hooked into the old admin list screens, or that still called removed functions, can break the moment 7.0 applies. So the update did not introduce a bug, it exposed extensions that had fallen behind. The fix is almost never to blame or revert WordPress, it is to find the specific plugin that broke and update or replace it. The debug log and the affected admin screen tell you which one.
My Posts, Pages, or Media screen looks broken or lost features after updating. Why?
This is the signature WordPress 7.0 problem. 7.0 replaced the classic Posts, Pages, and Media list tables with DataViews, a modern React-based interface with grid and list views, inline filtering, and bulk actions without page reloads. The catch is that many plugins added their own custom columns, bulk actions, row actions, and filters to those old list tables using legacy hooks. WordPress documentation and release coverage warn that any plugin modifying the Posts, Pages, or Media list views through those legacy hooks is at risk of breaking under DataViews. So a missing custom column, a vanished bulk action, broken quick-edit, or a list screen that errors usually means a plugin that customized that screen has not yet been updated for DataViews. The fix is to update that plugin to its 7.0-compatible release, or replace it if it is abandoned.
The whole site shows a critical error after the 7.0 update. What now?
A sitewide critical error after a major update is a PHP fatal, almost always from a plugin or theme calling code that 7.0 removed or changed. WordPress emails a recovery mode link to the admin address that loads a dashboard with the failing plugin paused, so check that inbox first. If you cannot use it, enable the debug log by editing wp-config.php over SFTP, reload the site once, and read wp-content/debug.log, where the most recent fatal names the exact plugin or theme file. To get back in immediately, rename the offending plugin folder over SFTP to deactivate it. Then update that plugin to its 7.0-compatible version, replace it if abandoned, or roll WordPress back to 6.9 on staging while you wait for a fix. Our debug log guide walks the diagnosis step by step.
I expected real-time collaboration in 7.0 and it is not there. Did something go wrong?
Nothing went wrong, the feature was intentionally removed before release. Real-time collaboration, the Google-Docs-style co-editing in the block editor, was planned for 7.0 but the core team pulled it from the release over concerns around surface area, race conditions, server load, and memory efficiency. It remains a priority and is expected in a later version, so it will return, just not in 7.0. If you tested a 7.0 beta or release candidate earlier in 2026 and saw performance problems when opening the editor, that experimental feature was the likely cause, and it is no longer in the shipped 7.0. There is nothing to fix on your side, the final 7.0 simply does not include it.
New AI options appeared in my settings after updating. Are they a problem?
No, those are a new built-in feature and they are entirely opt-in. WordPress 7.0 added native AI Connectors under Settings then Connectors, letting you configure one set of credentials for OpenAI, Google Gemini, or Anthropic Claude that compatible plugins can then use. You have to manually enter an API key for a provider for anything to happen, so if you have not done that, the feature is dormant and is not affecting your site. It does not send your content anywhere on its own. If the new screen is simply unfamiliar, you can ignore it. If a plugin is prompting you to connect a provider, that is the plugin using the new shared-credentials system rather than asking for its own key.
WooCommerce, Yoast, or a page builder broke right after I updated. What do I do?
Update them first. Major plugins move quickly to support a new core version, so the usual fix for a heavily used plugin that broke on the 7.0 jump is simply to update it to its latest, 7.0-compatible release. This is especially true for plugins that touch the admin list screens or add admin UI, since DataViews changed that area. Update WooCommerce, Yoast SEO, your page builder, and any plugin that customizes the Posts or Pages screens, then retest. If a plugin has no 7.0-compatible update and has not been maintained in a long time, treat it as abandoned and replace it with a maintained alternative rather than holding your whole site on the previous WordPress version for one stale plugin.
Should I roll WordPress back to 6.9?
Rolling back is a legitimate temporary measure, not a destination. If a critical plugin you depend on has no 7.0-compatible release yet, reverting core to 6.9 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 staying on 6.9 only delays the issue, since you will eventually need to move to 7.0 for security and support. The better long-term path for most sites is to update the offending plugin, replace it if it is abandoned, and move forward on 7.0, which is the current supported version. Treat the rollback as breathing room to fix the real cause.
How do I update to a major version like 7.0 safely next time?
Stage it, do not let it apply unsupervised. The pattern behind most 7.0 emergencies was a site auto-updating to 7.0 overnight while a plugin was still incompatible, so the owner woke up to a broken site they had not touched. Before a major core update, clone the site to staging, apply the update there, and exercise every important flow: the Posts, Pages, and Media screens, checkout, forms, and the editor. Update any plugins that need it and resolve breakage on staging, not production. Pay special attention to anything that customizes the admin list screens, since DataViews is the most likely thing to break in 7.0. Only once staging is clean, apply to production during a low-traffic window and watch the debug log. Keeping plugins current and backups recent turns a failed update into a quick restore.
Sources and further reading
Every claim on this page traces back to the WordPress core announcements and developer documentation for 7.0, or published 7.0 release coverage.
- WordPress Developer: What is new for developers, May 2026
- Make WordPress Core: WordPress 7.0 release party updated schedule
- Cloudways: WordPress 7.0 features, DataViews, and PHP requirements
- Make WordPress Core: PHP Compatibility and WordPress Versions
- php.net: Supported Versions and end-of-life schedule