How to Check Your Sites for WordPress 7.0 Compatibility

Update (3 April 2026): WordPress 7.0 has been delayed.
The WordPress core team extended the 7.0 release cycle on March 31 to allow more time for real-time collaboration architecture decisions. On April 2, a follow-up post confirmed that pre-release versions are paused through April 17 and a revised schedule will be published by April 22. The original April 9 date no longer applies. All requirement changes below remain unchanged.
WordPress 7.0 was originally scheduled for April 9, 2026, but the release has been delayed while the core team reworks the real-time collaboration architecture. It raises two big floor requirements: PHP 7.2 and 7.3 are dropped (minimum moves to PHP 7.4), and MySQL 8.0 is now the minimum database version (up from 5.5.5 in WordPress 6.9). Sites that don’t meet either requirement will not be offered the auto-update.
If you manage a portfolio of WordPress sites, these are the kind of changes that catch you off guard. A site on old PHP, or a shared host still running MySQL 5.7, and suddenly that site is stuck on 6.9 while everything else moves forward. mySites.guru flags exactly which sites are affected. The Sites Overview shows PHP versions, MySQL/MariaDB versions, and WordPress versions for every connected site. Sites below the 7.0 minimums stand out immediately. If you’re not a subscriber yet, the free audit reports PHP versions too.
What Changed Between WordPress 6.9 and 7.0?
| Component | WordPress 6.9 | WordPress 7.0 | Changed? |
|---|---|---|---|
| PHP (minimum) | 7.2.24 | 7.4 | Yes |
| PHP (recommended) | 8.3 | 8.3+ | No |
| MySQL | 5.5.5 | 8.0 | Yes |
| MariaDB | 10.6 (recommended) | 10.6 | No |
| HTTPS | Recommended | Recommended | No |
| Web Server | Apache or Nginx | Apache (mod_rewrite) or Nginx | No |
The PHP change is the one that will actually affect sites. PHP 7.2 and 7.3 usage dropped below 4% of monitored WordPress installs, which is below the 5% threshold the WordPress project uses for dropping support. The official announcement went up in January.
MySQL also gets a formal minimum bump. WordPress 6.9 technically allowed MySQL 5.5.5, though MySQL 5.7 extended support from Oracle ended back in October 2023. If your hosting provider is still running MySQL 5.x, that’s a bigger problem than WordPress compatibility.
What happened when Joomla required MySQL 8?
Joomla went through this exact pain already. When Joomla 5 launched in October 2023 with MySQL 8.0.13 as its minimum, budget shared hosts weren’t ready. HostGator told users they’d need to move to a VPS at roughly 6x the cost. GoDaddy’s response to “when will shared hosting get MySQL 8?” was basically “we don’t know.” SiteGround didn’t even start their MySQL 8 rollout until April 2024, six months after Joomla 5 launched, and the migration took 63 days and 1,228 engineering hours across roughly 3 million databases.
The result was a two-year window where Joomla users on cheap shared hosting were stuck: their host wouldn’t upgrade MySQL, they couldn’t upgrade to Joomla 5, and Joomla 4 was marching toward end-of-life. Many switched to MariaDB (which hosts offered more readily) or changed providers entirely.
WordPress users are unlikely to hit this as hard. WordPress was still allowing MySQL 5.5.5 until now, so the jump to 8.0 sounds dramatic, but most hosts upgraded to MySQL 8 during the Joomla migration wave. If your host survived the Joomla 5 transition, you’re probably fine. If they didn’t, well, that tells you something about your host.
What Happens to Sites on PHP 7.2 or 7.3?
They don’t break. WordPress won’t force an incompatible update. Instead:
- WordPress 7.0 will not be offered via the automatic update mechanism. Auto-updates skip these sites entirely.
- Security patches for 6.9.x will continue, so sites aren’t left exposed. They stay on the 6.9 security branch.
- Manual updates are blocked too. The Dashboard > Updates screen will tell the site owner to upgrade PHP first.
The risk isn’t immediate breakage. It’s drift. A site stuck on 6.9 gradually falls behind on features, plugin vulnerability patches, and eventually security coverage when the 6.9 branch reaches end of life.
How Do You Check PHP Versions Across All Your Sites?
Checking one site is easy: Dashboard > Tools > Site Health. Checking 50 or 500 is not.
WordPress 7 Compatibility Checker
We built a dedicated WordPress 7 Compatibility Checker that lists every connected WordPress site and colour-codes each one against the 7.0 requirements. You can open it from the command palette (Cmd+K or Ctrl+K) by typing “wordpress 7”, or with the keyboard shortcut c then 7.
If you’re already a mySites.guru subscriber, you can open this tool right now:
Check all your WordPress sites for 7.0 compatibility
Open WordPress 7 Compatibility Checker
Colour-codes every connected site's PHP version, database version, and auto-update status against the WordPress 7.0 requirements. Sites that need attention are flagged immediately.
For each site, the tool shows:
- PHP version - green if 8.3+ (recommended), yellow if 7.4+ (minimum), red if below 7.4
- Database version - green for MySQL 8.4+ or MariaDB 11.4+ (current LTS releases), yellow for MySQL 8.0+ or MariaDB 10.6+ (official minimum), red if below
- Auto-update status - whether
AUTOMATIC_UPDATER_DISABLEDis set in wp-config.php, so you know which sites might auto-upgrade to 7.0 before you’re ready - Server hostname - quickly spot which hosting provider or server needs attention
Sites that need action stand out immediately. Filter by hostname to see all sites on one server, or by PHP version to group sites that need the same upgrade. For a closer look at how the colour coding works and what each column means, see the WordPress 7 technical requirements check walkthrough.
The Sites Overview also shows PHP and database versions for every connected site if you need a broader view across both WordPress and Joomla. If you’re not a subscriber yet, the free audit reports PHP versions too.
From there, coordinate with hosting providers to upgrade PHP on the affected servers before the release. The delay gives you extra time to prepare. Most hosts let you change PHP versions from cPanel or Plesk without a support ticket.
What Else is New in WordPress 7.0?
PHP and MySQL are the operational headaches, but 7.0 ships a lot more than version bumps.
Real-Time Collaboration
Phase 3 of the Gutenberg roadmap lands here: real-time collaborative editing in the block editor. Multiple users can edit the same post simultaneously, with changes synced using Yjs (a conflict-free data merging library).
The default transport is HTTP polling, which works on every host with no special server configuration. Hosting providers can optionally enable WebSocket support for lower latency via the sync.providers filter.
One caveat: posts that use classic meta boxes will fall back to traditional post locking instead of real-time collaboration. If you have custom meta boxes, migrate them to register_post_meta() with show_in_rest => true or you won’t get the collaborative editing.
During the beta/RC period, collaboration is controlled by the WP_ALLOW_COLLABORATION constant in wp-config.php. After the stable release, it should be on by default.
AI Infrastructure
WordPress 7.0 ships a provider-agnostic AI client (WP_AI_Client_Prompt_Builder) that lets plugins call OpenAI, Anthropic, Google, and other LLM providers through a unified PHP API. A new Connectors API at Settings > Connectors centralizes credentials for external services.
There’s also an MCP Adapter that exposes WordPress “Abilities” as Model Context Protocol tools at /wp-json/mcp/v1/, authenticated via Application Passwords. If you’ve been following the MCP spec, this is WordPress giving plugins a standardized way to talk to AI agents.
You can disable all AI features with a single config option if you don’t want LLM integration on a site.
Everything Else
- Images are now resized and compressed in the browser before upload (client-side media processing), which reduces server load
- Blocks can be shown or hidden per screen size (mobile, tablet, desktop)
- The Posts, Pages, and Media screens use new DataViews (list/grid toggle) instead of
WP_List_Table - A “Modern” admin color scheme replaces “Fresh” as the default. The old scheme is still available.
Cmd+K/Ctrl+Kopens a Command Palette in the admin bar for quick navigation- New blocks: Breadcrumbs, Icons, Gallery lightbox, Grid (responsive), Cover (video embeds)
- The Font Library now works with classic and hybrid themes, not just block themes
Should You Update to WordPress 7.0 When It Lands?
If you’ve been testing during the RC cycle, yes - update production sites as soon as the stable release is available. If you haven’t been following the pre-release builds, test on a staging site first and update production once you’re confident.
The delay actually works in your favour here. Use the extra time to:
- Run the WordPress 7 Compatibility Checker to identify sites below PHP 7.4 or MySQL 8.0, then coordinate hosting upgrades
- Test on staging with the latest RC/beta, especially if you use custom meta boxes or heavily customized themes
- Review plugin compatibility - major WordPress releases sometimes break plugins that rely on internal APIs
- Plan mass upgrades - once you’re confident, mySites.guru lets you roll out WordPress updates across all sites from one place
If you want to control the rollout more tightly, you can enforce minor upgrades only or disable automatic updates entirely so sites don’t auto-update to 7.0 before you’re ready.
Further Reading
- Extending the 7.0 cycle - announcement of the release delay (March 31)
- The path forward for WordPress 7.0 - revised timeline details, pre-release pause through April 17 (April 2)
- WordPress 7.0 RC2 announcement - release candidate (March 26, hard string freeze)
- WordPress 7.0 RC1 announcement - first release candidate notes
- Dropping PHP 7.2 and 7.3 - Make WordPress Core announcement
- AI Client dev note - WP_AI_Client documentation
- Connectors API dev note - new Settings > Connectors screen
More on keeping PHP and WordPress current in our WordPress and Joomla security guide.


