WordPress 7.0 was scheduled to release on April 9, 2026. On March 31, the core team announced a delay of a few weeks to finalize the data storage architecture for the real-time collaboration feature. A revised schedule will be published by April 22. WordCamp Asia in Mumbai proceeds as planned on April 9 through 11. The release does not.

The week the delay was announced, Cloudflare launched EmDash, a TypeScript CMS it built in two months using agentic AI, released under the MIT license, and described in its own announcement as a “spiritual successor” to WordPress. EmDash runs natively on Cloudflare Workers, scales to zero, and sandboxes plugins in V8 isolates. Joost de Valk, the former CEO of Yoast and one of WordPress’s most prominent recent critics, is among its early supporters. The strategic intent is not subtle: Cloudflare is building a CMS to route content workloads onto its own infrastructure and away from the hosting stack where WordPress currently lives.

WordPress 7.0 is not a direct response to EmDash, which arrived too recently for that. But the features it ships, particularly real-time collaboration, a native AI client layer, and browser-based agent support, are exactly the capabilities a CMS needs to remain competitive with an AI-native alternative. The delay matters not because a few weeks changes anything operationally, but because it reflects the degree of difficulty in shipping those features reliably. For hosting companies that have built managed WordPress products, the combination of a delayed major release and a credibly resourced competitor entering the market is the context in which the 7.0 launch will land.

What Hosting Companies Need to Do Now

The revised release schedule will be announced by April 22. That announcement will trigger customer questions, upgrade pressure, and compatibility testing across the customer base. The time between now and that announcement is preparation time. Here is what needs to happen before it.

The most time-sensitive task is PHP version mapping. WordPress 7.0 drops support for PHP 7.2 and PHP 7.3. Sites running either version will not receive the automatic update to 7.0; they will remain on the WordPress 6.9 branch. The 6.9 branch receives security backports when possible, but it is not the actively maintained security release branch. The WordPress core team noted that combined usage of PHP 7.2 and 7.3 had dropped below 4% of monitored WordPress installations globally. The relevant figure for any individual hosting company is its own customer distribution, not the global average. Providers with older small business or legacy e-commerce customers will have a higher proportion. Those customers need outreach before the release, not after. A customer who finds themselves on an unsupported branch after a release they did not consciously opt out of is a support ticket and a trust problem.

The second task is deciding the WebSocket question. Early coverage of WordPress 7.0 described real-time collaborative editing as requiring WebSocket support. That characterization is incorrect. WordPress 7.0 ships HTTP polling as the default transport, which works on any standard hosting environment without additional configuration. Polling batches updates every four seconds when a user edits alone, every one second when collaborators are present. WebSocket support is an optional enhancement that reduces latency; WordPress VIP has already deployed it. A managed WordPress product needs a documented position on which tier of the feature it delivers. Shared hosting with HTTP polling is a supported configuration. WebSocket-enhanced collaboration is a differentiator. Neither is a requirement; not having decided is the problem.

Third, any custom caching layer needs to be verified against 7.0 behavior. Real-time collaborative editing was confirmed during development to interfere with persistent post caches during active sessions. The team addressed this before release through changes to the meta registration API, but hosting companies running their own caching implementations should verify behavior against their own stack once the next release candidate is available.

Fourth, plugin compatibility testing needs to run before the release date is confirmed, not after. The WordPress 7.0 admin has been visually updated and DataViews components have changed. Any plugin that renders inside wp-admin needs testing. The new minimum PHP version also needs to be reflected in hosting control panels, auto-upgrade logic, and documentation before customers encounter it.

The Real-Time Collaboration Feature: What Actually Ships

Real-time collaboration ships as opt-in in 7.0. Customers will not encounter it by default. When enabled, collaborative editing is limited to two simultaneous users in the base implementation, though this can be configured. Any post where classic metaboxes are present disables collaboration automatically to prevent data loss, meaning customers with legacy plugin-heavy sites will see collaboration active on fewer posts than they might expect.

The feature uses Yjs, a conflict-free replicated data type library, for merging simultaneous edits. The default HTTP polling transport means no infrastructure change is required from the hosting side. For managed WordPress providers, the decision is whether to offer WebSocket support as a plan differentiator, and if so, whether to implement it before the 7.0 release or treat it as a roadmap item.

The AI Client: What It Means for Hosting Product Teams

WordPress 7.0 ships the WP AI Client, a server-side PHP SDK that standardizes how AI capabilities are integrated into WordPress. It is provider-agnostic: the SDK handles model selection, provider communication, and response normalization. WordPress core ships with three featured provider plugins for Anthropic, Google, and OpenAI, all installable from the plugin directory. API keys are managed through a new Settings, Connectors admin screen. All AI calls go outbound to third-party APIs. There are no new server infrastructure requirements.

For hosting product teams, the question is what this means for the managed WordPress offer. The WP AI Client makes it straightforward for any plugin developer to build AI-powered features into WordPress. That is good for the ecosystem and good for differentiation at the plugin level. It does not create infrastructure obligations. What it does create is customer expectation: sites running on managed WordPress plans will increasingly include AI-powered plugins, and the hosting provider’s job is to ensure those plugins function reliably within the resource constraints of the plan.

The Competitive Picture

EmDash is at version 0.1. It is not a WordPress replacement today for the hundreds of millions of sites running on the existing stack. Migration requires rewriting themes and plugins from scratch in TypeScript, which creates a high barrier for existing WordPress users. The competitive threat is not to existing WordPress installs but to new projects, particularly developer-led projects where the choice of CMS is made fresh and the Cloudflare Workers infrastructure is already in use.

The structural concern for hosting companies is longer term. Cloudflare’s model is to make EmDash the CMS that brings workloads onto its own network. A developer who builds on EmDash is a developer who does not need managed WordPress hosting, managed PHP, or LAMP-stack infrastructure at all. At scale, that is a different market than the one managed WordPress hosting currently serves. At current scale, EmDash v0.1 is a developer preview. The question for hosting product strategy is whether to treat it as a signal worth monitoring or a threat worth responding to now.

WordPress 7.0’s real-time collaboration and AI client features move the platform in the right direction competitively. A delayed major version, a technically ambitious feature set, and a new entrant positioning directly against the platform are all present at the same time. For hosting companies whose product lines are built around WordPress, that combination is worth having a view on before the release date is confirmed.