WordPress 7.0 Planning Kicks Off: Three Major Releases in 2026, AI Client on the Table, and PHP 7.4 Debated

WordPress release planning is shifting again. In a recent Core Committers Check-in, project leadership and core committers discussed returning to three major releases in 2026, with early planning already forming around WordPress 7.0.

The conversation wasn’t just about dates. The same meeting also touched on potential 7.0 feature candidates, the direction and scope of the long-running wp-admin redesign, and a renewed debate about raising the minimum supported PHP version-with PHP 7.4 explicitly mentioned as a target worth evaluating.

The meeting was held under the Chatham House Rule, which is worth keeping in mind: details are shared, but attribution is intentionally limited.

Why three major releases in 2026 is a notable change

Earlier, the public expectation for 2026 had been very different: WordPress Executive Director Mary Hubbard had previously indicated that only one major release would ship in 2026, citing “ongoing legal matters.” Those remarks were widely understood in the context of the WP Engine lawsuit, plus Automattic’s pause in WordPress contributions during the same broader legal dispute.

This latest committers’ check-in signals a reversal of that direction-at least in intention-toward a more familiar cadence.

What we know about the 2026 release cadence (and the likely 7.0 window)

Based on the published meeting notes on Make WordPress Core, the stated intention is to resume a three-release cadence in 2026, with WordPress 7.0 targeted for March or April.

A February release was explicitly ruled out. The reasoning was practical: it would push beta 1 into early January, a period when many contributors are still on holiday, and it would also collide with the reality that several in-progress features wouldn’t be ready in time.

Coordinating releases around flagship events: idea, not plan

There was also discussion about aligning major releases with flagship events-similar to WordPress 6.9 launching alongside the State of the Word. But the group highlighted the operational complexity: coordinating around travel schedules, time zones, and release squad and contributor availability can make an already tight process harder to run.

So, this is best understood as a possibility that’s been flagged for further discussion, rather than a committed plan.

Potential WordPress 7.0 features: what’s being discussed

Several items that had been scoped for WordPress 6.9 were raised as candidates for 7.0 instead. These included:

• Template activation
• The Tabs block
• Client-side abilities for the Abilities API
• Client-side media editing

But the largest slice of attention went to one particular initiative: the WordPress AI Client.

The WordPress AI Client: a serious candidate for core

If you’ve been watching the new AI efforts around WordPress, the AI Client is one of the AI Team’s four “Building Blocks,” and it’s now being considered for inclusion in WordPress core.

Version 0.1.0 of the WordPress AI Client shipped recently, and it’s positioned as a native, provider-agnostic way for plugins and themes to talk to AI services. “Provider-agnostic” matters here: it’s designed to avoid baking any single vendor or model into the API surface area.

What the AI Client actually does (in practical terms)

The AI Client adapts the broader PHP AI Client project to WordPress conventions. A few implementation details are particularly relevant if you build plugins or themes:

• It uses the WordPress HTTP API for outbound requests (so it fits existing WordPress networking and configuration patterns).
• It centralizes API keys in an “AI Credentials” screen rather than encouraging each plugin to invent its own settings UI.
• It handles model selection without forcing plugin authors to hard-code specific providers.

The notes also outline what’s expected in future iterations of the AI Client:

• Abilities API support
• REST endpoints
• A client-side Prompt Builder

Why core committers think it belongs in core

From a platform perspective, the argument is less “WordPress should ship AI features” and more “WordPress should ship the foundations so the ecosystem can build safely and consistently.” The meeting notes frame it as a way to encourage developers to build on solid shared primitives-explicitly naming the Abilities API as one of those foundations.

Because the AI client is a great way to encourage the ecosystem to build around solid foundations (such as the Abilities API), the ideal home for this is Core itself. The combining of these related APIs will unlock so many possibilities for developers and site owners.

Meeting notes (Make WordPress Core)

Constraints: core wants to stay agnostic

A key constraint was stressed clearly: WordPress “will always remain agnostic.” In other words, including a specific AI model-or only integrating with a subset of third-party services-is treated as unsustainable.

The group also noted that some longer-term opportunities could come from emerging machine-based or browser-level models, but no particular direction was selected.

Use cases in “default WordPress” are still a prerequisite

Before any decision is made, contributors want clearer “default WordPress” use cases (i.e., what a site owner can do out of the box without installing a plugin). Examples raised in the discussion include:

• Searching the media library for specific subject matter
• Generating newsletters based on recent content

The admin redesign: framed as a “fresh coat of paint,” not a rebuild

The wp-admin redesign continues to be a major thread in Gutenberg’s Phase 3: Collaboration roadmap, but the check-in included an important calibration: the effort is not aiming for a full overhaul.

Instead, attendees were told the redesign is intended as “a new coat of paint and refreshing what is already there.”

That clarification matters because earlier conversations (including the group’s July quarterly meeting) included experimenting with the redesign either inside the Gutenberg plugin or as a separate “MP7” plugin-echoing MP6, the 2013 “feature as a plugin” effort that heavily influenced the WordPress 3.8 admin refresh.

Historically, this work traces back to 2023, when Gutenberg Lead Architect Matías Ventura shared a vision for modernizing the admin experience and later demoed new layouts during the 2023 State of the Word.

An early preview of the redesign had been expected around WordPress 6.9, but it was shelved in September when the roadmap was updated to state it was “no longer planned based on the current state of work.”

There’s still no committed timeline for when the redesigned admin might land. The last major refresh was more than a decade ago, shipped in WordPress 3.8.

Minimum PHP version: the case for moving to PHP 7.4 (and why it’s complicated)

Another substantial topic was whether WordPress should raise its minimum required PHP version-specifically exploring “compelling reasons” to move the baseline to PHP 7.4.

The discussion focused on practical development constraints:

• Supporting older PHP versions forces WordPress to retain compatibility that adds bloat and slows development.
• A PHP 7.4 minimum would move the codebase toward more consistent typing, making it easier for developers-and even AI systems-to interpret and work with the code.
• Many third-party AI SDKs already require later PHP versions; keeping the minimum too low can block WordPress from using those libraries.

At the same time, the tone was explicitly about balance: progressing the platform without leaving users behind. No decision was made during the meeting.

Process follow-ups: what contributors want to resolve next

The meeting notes captured several concrete follow-up items-less about features, and more about how the project operates over the next cycle:

• Proposing more open and semi-open meeting formats
• Publishing the 2026 release schedule
• Confirming targeted features for 7.0 and possibly 7.1
• Assessing whether coordinating releases with in-person events is practical

What to watch if you build for WordPress

If the three-release plan holds, WordPress 7.0 could arrive as early as March or April, and the key technical questions are already visible: whether the AI Client becomes core infrastructure, how conservative the admin refresh will be, and whether the minimum PHP version can move to 7.4 without disrupting too many real-world installs.

For plugin and theme developers, the AI Client discussion is especially telling: the project is signalling that if “AI” becomes a meaningful part of WordPress, it should happen via stable, shared primitives (credentials management, HTTP integration, provider-agnostic APIs) rather than scattered one-off integrations.