How to Check Your Sites for WordPress 7.0 Compatibility

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 one floor requirement: PHP 7.2 and 7.3 are dropped (minimum moves to PHP 7.4). The database minimum stays at MySQL or MariaDB 5.5.5, although WordPress now recommends MySQL 8.4 or MariaDB 10.11 and later. Sites below the PHP minimum 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, 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 PHP minimum 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?

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.

The database minimum did not move. WordPress 7.0 still runs on MySQL or MariaDB 5.5.5, even though Oracle ended MySQL 5.7 extended support in October 2023 and MySQL 8.0 support on 30 April 2026. 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 will not hit this with 7.0, because WordPress kept the 5.5.5 floor. If a later release does raise it, most hosts already moved to MySQL 8 or a current MariaDB during the Joomla migration wave. If your host came through the Joomla 5 transition, you’re probably fine. If they didn’t, well, that tells you something about your host.

Sites on PHP 7.2 or 7.3 Stay on the 6.9 Branch

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:

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+ (still works, but both reached end of life in 2026), red for anything older (WordPress 7.0 still runs on it, but it is past end of life)
• Auto-update status - whether AUTOMATIC_UPDATER_DISABLED is 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 appears 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+K opens 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

The Phased Rollout Plan for 7.0

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:

1. Run the WordPress 7 Compatibility Checker to identify sites below PHP 7.4 or on an end-of-life database, then coordinate hosting upgrades
2. Test on staging with the latest RC/beta, especially if you use custom meta boxes or heavily customized themes
3. Review plugin compatibility - major WordPress releases sometimes break plugins that rely on internal APIs
4. 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.