WordPress 7.0: What Hosting Providers and Developers Need to Know [with FAQ]

WordPress 7.0 arrives on 9th April 2026, and for those of us who manage hosting environments and maintain client sites professionally, this release carries more weight than most. It marks the beginning of Phase 3 of the Gutenberg project, introduces architectural changes that will ripple through the plugin and theme ecosystem, and raises the minimum PHP version for the first time in some years. There’s a lot to work through, and the time to start is now, not after the release is live.

PHP 7.4 is the new minimum. Check your environments ahead of April.

This is the most immediately practical concern for any hosting provider or agency. WordPress 7.0 drops support for PHP 7.2 and 7.3. Sites running those versions will be held on the 6.x branch and will not receive the 7.0 update. PHP 8.3 or above is recommended for best performance.

If you’re managing a stack of client sites, now is the time to audit which ones are still on older PHP versions. Leaving sites on unsupported PHP branches creates security exposure over time, so this is a nudge worth acting on regardless of the WordPress update itself. We’d recommend getting any remaining PHP 7.x sites migrated to 8.1 or higher as a priority.

Real-time collaboration has hosting implications

The collaboration infrastructure in WordPress 7.0 is designed to be flexible across different hosting environments. The default sync mechanism uses HTTP polling, which means it works out of the box on shared hosting without any additional configuration. That’s a sensible default.

However, environments that support WebSockets can enable faster syncing for a noticeably better collaborative editing experience. Developers can also register custom transport layers via the sync.providers filter. At the infrastructure level, it’s worth understanding that the collaboration feature is disabled when classic meta boxes are present on a post. Any plugins relying on classic meta boxes will need to migrate to registered post meta with show_in_rest enabled before their users can take advantage of collaborative editing.

DataViews replaces WP List Tables. Test your plugins.

The DataViews component is progressively replacing the traditional WP List Tables for Posts, Pages and Media. This is a significant change for any plugin that hooks into legacy list views. The groupByField string parameter has been replaced by a groupBy object that now supports field, direction and showLabel properties.

If you maintain plugins that customise Posts, Pages or Media list views, this needs testing against RC2 before the stable release. If you manage client sites with third-party plugins that do the same, it’s worth checking whether those plugins have already issued 7.0-compatible updates.

The Block API is maturing fast

WordPress 7.0 moves Block API v3 into the reference model position. Blocks that rely on global document queries or .wp-admin selectors should be flagged for migration. More pressingly, the iframed editor is expected to be enforced in WordPress 7.1, so anything that hasn’t been migrated by then will have a compatibility problem.

The Interactivity API gains a new watch() primitive in 7.0, which allows subscription to reactive state changes at the store level independently of the DOM. This is useful for analytics event tracking and side-effect management on client-side navigations. If you’re building anything that relies on detecting navigation or state changes on the front end, it’s worth exploring.

Client-side media processing changes the upload flow

Image processing now happens in the browser before upload. Resizing and compression are handled client-side, with support for AVIF, WebP and MozJPEG output. The practical effect is reduced server load for media-heavy sites and faster upload experiences for users, particularly on high-resolution photography or product image workflows.

From a hosting perspective, this is a straightforward win. Fewer large raw files hitting the server on upload means less processing overhead and reduced storage footprint for unoptimised originals. It’s worth communicating this improvement to clients who run image-heavy sites, as they’ll notice the difference.

The AI Connectors framework: governed, extensible, provider-agnostic

The new AI integration layer in WordPress 7.0 is built on the Abilities API that arrived in 6.9. It introduces a standardised interface that any plugin or theme can use to connect to AI services, with OpenAI, Google AI and Anthropic shipping as default provider plugins. Additional providers can be registered via the connections-wp-admin-init hook.

For hosting providers, the key point is that there’s no vendor lock-in built into core. Administrators control which providers are active through a single Settings menu screen. For developers, this means AI-powered features can be built on a stable, sanctioned foundation rather than fragmented plugin-level integrations, and they’ll be manageable by site owners without developer intervention.

This is early infrastructure. The immediate practical applications are things like AI-assisted meta description generation, bulk alt text creation and editorial assistance. The longer-term implications are considerably broader, but the groundwork being laid now is the right kind: governed, extensible and hosted within the site’s own administrative structure.

The refreshed admin and the Command Palette

The Omnibar now carries the Command Palette across the entire admin interface, not just the block editor. This is a developer experience improvement as much as a user experience one. Keyboard-driven navigation across the full admin is a meaningful time-saver when working across environments or managing multiple sites.

For hosting providers offering managed WordPress services, the DataViews update is worth highlighting in client communications. The app-like browsing experience for Posts, Pages and Media is noticeably more modern and will likely reduce the volume of “how do I find X?” support queries from clients used to the old list table interface.

What to do before 9th April

The preparation checklist for anyone managing WordPress sites professionally is fairly clear. Audit PHP versions across all managed environments and get anything below 7.4 migrated. Test plugins that hook into Posts, Pages or Media list views against the DataViews API change. Check for any plugins using classic meta boxes and assess migration timelines. Review Block API usage for anything relying on global document queries or .wp-admin selectors.

For client sites where a cautious update approach is preferred, staging environment testing before applying 7.0 to production is the right call, particularly for sites with complex plugin stacks or custom development.

How we’re approaching it at O’Brien Media

We’ve been working through our hosting environment ahead of the April release. That means auditing PHP versions across customer sites, identifying any that sit below the 7.4 threshold, and flagging anything in our plugin stack that interacts with list tables or classic meta boxes.

Where action is needed, we’re contacting customers directly. That includes anyone whose site will be affected by the PHP version change, and anyone where the front-end or editor changes in 7.0 are likely to require attention before or after the update is applied. Our customers won’t need to come to us; we’ll come to them.

A release worth getting right

WordPress 7.0 is a platform inflection point. The collaboration infrastructure, the AI layer, the Block API maturation and the admin overhaul are all pointing in the same direction: a CMS that can serve as the foundation for genuinely modern, team-based content workflows. Getting sites updated cleanly and taking advantage of what 7.0 offers is the work in front of us between now and April.

If you have questions about how this release affects a site we host or maintain for you, get in touch ahead of the release date. Get in touch with on 01793 239239 or email [email protected] and we’ll be happy to talk it through.