WordPress 7.0 Armstrong shipped: AI infrastructure, Abilities API, and what actually changed

Update, May 23, 2026: WordPress 7.0 codenamed Armstrong has shipped. The release closes Phase 3 of the Gutenberg roadmap with foundational AI infrastructure (Abilities API + AI Services Registry + AI Client), a modernised dashboard, Command Palette everywhere, block-level custom CSS and the Icons block. Real-time collaboration was removed during RC testing and does not ship in 7.0. This guide is the post-release recap; older roadmap sections below remain for historical reference, not as a description of what is enabled on a 7.0 install today.

WordPress 7.0 “Armstrong” shipped in May 2026 after a longer-than-usual release-candidate cycle. The release was built by more than 900 contributors. Headline change is AI infrastructure in core: the Abilities API surface for safe admin operations, the AI Services Registry for hosted-model integration, and the WordPress AI Client around which third-party plugins are now standardising. Modernised admin dashboard, Command Palette available everywhere in wp-admin, block-level custom CSS, and the Icons block also shipped. Real-time collaboration was removed from this release during RC testing and is not part of the upgrade.

For a sharper polemic on what the 7.0 AI surface means for plugin authors specifically, see our piece on why shipping an MCP server in your WordPress plugin is the AI move that survives. For the post-release security implication, see our reading of the GuardingWP State of WordPress Security 2026 report which puts the new AI key surface in context with the 53% unpatched-CVE baseline.

Track make.wordpress.org/core and the official wordpress.org/news feed for follow-up patch releases.

Learn more about professional WordPress development at WPPoland.

#WordPress 7.0 release date and codename

WordPress 7.0 codenamed Armstrong shipped in May 2026 after an unusually long release-candidate cycle (RC4 landed on May 14, 2026, with the final release following shortly after). The “Armstrong” name continues WordPress’s tradition of naming major releases after jazz musicians.

If you are planning a production upgrade, the safest window is still two to four weeks after the final release, once the initial patch cycle catches compatibility issues reported by early adopters.

#What actually shipped in 7.0 Armstrong

This is the confirmed feature list from the wordpress.org release announcement, not the earlier roadmap intent. Anything on the older roadmap that is missing here did not ship in 7.0.

• AI infrastructure in core. The Abilities API for safe admin operations through structured intents, the AI Services Registry for connecting hosted-model providers (Anthropic, OpenAI, Vercel AI Gateway, self-hosted), and the WordPress AI Client which third-party plugins now build against. This is the platform change that defines the release.
• Command Palette everywhere. Cmd-K / Ctrl-K opens the Command Palette on every wp-admin screen, not just the block editor. Power-user keystroke surface is now first-class.
• Block-level custom CSS. Each block can carry its own CSS, scoped to that block. Removes a long-standing reason to drop down to a custom theme.
• Icons block. A native block for embedding SVG icons from a curated library, with theme-aware colour tokens.
• Modernised dashboard. Refreshed admin landing surfaces, with the agentic-AI experiments visible behind a feature flag.
• PHP 7.4 minimum runtime. Sites still on older PHP must upgrade their server environment before updating to 7.0.
• More than 900 contributors. WP Charitable Product Manager David Bisset publicly thanked the contributors and “their spouses, partners, families, pets, coping mechanisms, and guidance counselors that supported them” - which is the most honest line written about a major WordPress release in years.

What did not ship and is no longer expected on the 7.0 line:

• Real-time collaboration was removed from this release after release-candidate testing. The earlier roadmap description further down in this guide is preserved as historical context.

#Security: protect AI provider API keys from day one

Patchstack founder Oliver Sild posted publicly on X around the release: “there will be an absolute rush by hackers to steal API keys.” The risk is concrete. A compromised wp-admin credential on a 7.0 install no longer just lets an attacker change content; it also lets them drain a four- or five-figure monthly token bill against your AI provider before the invoice catches it. Justin Nealey separately flagged that the WP AI Client has no built-in throttle and multiple plugins sharing one key can blow through the token cap in under a minute.

The control surface to apply is straightforward and the same control surface a finance team would apply to any newly minted billable credential:

• Scope API keys per connector, not per site. One key per provider per connector. Rotate on a published cadence.
• Apply rate limits at the gateway, not in the plugin. If your provider supports per-key rate limits (Anthropic, OpenAI, Vercel AI Gateway all do), set them low enough that anomalous consumption is visible against one billing cycle.
• Alert on anomaly token spend inside the cycle, not at month-end. Most providers expose a billing-day API; wire it into your monitoring.
• Audit log the connector usage at the WordPress side. The Abilities API surfaces operation IDs; log them in a separate stream from regular wp-admin audit log.

These map directly onto the supply-chain controls already required by NIS2 Article 21 paragraph 2 letter d for in-scope entities. Treat the new AI surface as a new class of ICT third-party arrangement, register it accordingly.

#WordPress 7.0 roadmap

WordPress 7.0 sits at the end of Phase 3 of the Gutenberg project’s four-phase plan:

Phase 4 will bring native multilingual capabilities, which means WordPress will finally handle content translation at the core level instead of relying on plugins like WPML or Polylang. For agencies managing multilingual sites today, this is the feature to watch on the post-7.0 roadmap.

#AI in WordPress now that 7.0 has shipped

The honest version of “AI features in WordPress 7.0” starts with what already works in 6.x, because that is what real sites are running.

Available today, in production WordPress:

• Yoast and Rank Math both ship AI-assisted writing helpers (titles, meta descriptions, internal link suggestions) built on third-party model APIs.
• Jetpack AI Assistant offers in-editor generation, summarization, and translation. Quality varies by language and prompt.
• Standalone content generation plugins exist across a wide quality range; useful for drafts, dangerous when wired straight to publish without human review.
• Automattic and contributor teams are running Phase 3 experiments, including collaborative editing and editor-side AI calls, in the Gutenberg plugin ahead of any merge into core.

A pragmatic architecture for adding AI to a WordPress site today, which will likely survive whatever 7.0 ships:

• Expose a small REST API endpoint per provider (OpenAI, Anthropic, Google, or a self-hosted model). Keep provider-specific code behind one interface so swapping models is a config change, not a rewrite.
• Run anything slower than a few seconds through Action Scheduler, not a synchronous request. This is the same pattern WooCommerce uses; it scales.
• Store API keys as wp-config.php constants or via a managed secret store loaded at boot. Never put live keys in plugin options or .env files committed to a repo.
• Cache responses keyed on a hash of the prompt plus model version. AI calls are expensive and frequently repeated.

Failure modes worth designing against from day one:

• API key leakage through plugin auto-updates or backups that include wp-content dumps.
• Rate-limit failures during traffic spikes, which silently degrade the editor experience if there is no fallback.
• Hallucinated facts, citations, or product specs published without a human review step. The cost of one bad page in search is higher than the cost of any review workflow.

If 7.0 introduces a core abilities or connectors layer, the same boundaries apply: the API surface changes, the failure modes do not. For ethics and editorial framing, see the AI content ethics guide for publishers.

#What’s actually known about 7.0 right now

Strip out the marketing framing and the picture is narrower than most “complete guide” posts suggest.

Confirmed for the May 2026 release candidate line:

• RC4 and the Field Guide document Abilities API infrastructure, admin changes, and PHP 7.4 as the minimum supported version.
• Real-time collaboration was removed from this release after RC testing. Treat any collaboration marketing copy as historical roadmap context.
• AI Experiments 1.0 is targeting a plugin release alongside core, with admin approval required before plugins can use stored AI credentials.

Still moving during the final release week:

• Which AI connector UI details ship in core versus the AI Experiments plugin.
• Late plugin and theme compatibility fixes discovered on staging stacks.

For agencies and product teams shipping in 2026, the practical takeaway is simpler than any feature list: build on WordPress 6.x using forward-compatible patterns (block themes, theme.json, the REST API, Action Scheduler for background work) so the 7.0 migration is incremental rather than a rewrite.

#What’s New in WordPress 7.0

WordPress 7.0 introduces dozens of new features and improvements across the entire platform. The most transformative shipping changes center on AI integration through the Abilities API and a comprehensive admin interface redesign. Real-time collaboration was deferred after RC testing (see the historical section below).

#Key Feature Highlights

The Abilities API stands out as the most innovative addition, providing developers with standardized methods for integrating AI services directly into WordPress workflows. This API handles authentication, rate limiting, content sanitization, and context management - eliminating the need for each plugin developer to build these complex systems independently.

#Real-time collaboration (removed from 7.0 - historical roadmap)

Historical roadmap context (May 2026): Real-time collaboration was removed from WordPress 7.0 after RC testing. The following describes earlier roadmap intent, not features you can enable on a 7.0 upgrade today.

Earlier roadmap materials described real-time collaboration as a multi-user block editor experience: simultaneous editing, presence indicators, and operational transformation for merge conflicts.

#How Real-Time Collaboration Works

The collaboration system uses WebSocket connections to maintain persistent communication between users editing the same content. When a user makes changes, operational transformation algorithms ensure that concurrent edits merge directly without data loss. Each collaborator receives a unique color-coded cursor and presence indicator, making it easy to see who is working on which section.

Key collaboration features include:

• Presence Indicators: See who is currently viewing or editing content
• Colored Cursors: Track exactly where other users are working
• Inline Comments: Add contextual feedback without leaving the editor
• Activity Feed: View recent changes and who made them
• Conflict Resolution: Intelligent merging when users edit the same block

#Collaborative Workflows

The real-time collaboration feature integrates deeply with WordPress’s existing user role and permission system. Administrators can configure which user roles can collaborate, set up approval workflows, and define who has final publishing authority. This makes WordPress 7.0 suitable for enterprise editorial teams, newsrooms, and marketing departments that require structured content approval processes.

For agencies and developers, the collaboration system exposes JavaScript APIs that allow custom implementations. You can build specialized collaboration features tailored to specific client needs, such as custom notification systems, advanced approval workflows, or integration with external project management tools.

#AI Integration & Abilities API

The Abilities API represents WordPress’s formal entry into the AI-powered content management era. This comprehensive framework provides developers with tools to integrate AI services natively into WordPress, creating intelligent content workflows that were previously impossible or required complex third-party integrations.

#Understanding the Abilities API Architecture

The Abilities API operates on a provider-agnostic model, meaning it can work with any AI service that implements the standard interface. Whether you’re using OpenAI’s GPT models, Anthropic’s Claude, Google’s Gemini, or a self-hosted LLM, the API provides consistent methods for content generation, analysis, and modification.

Core components of the Abilities API include:

// Registering an AI ability
add_filter( 'wp_abilities_register', function( $abilities ) {
    $abilities['content_generation'] = [
        'provider' => 'openai',
        'capability' => 'edit_posts',
        'endpoint' => 'https://api.openai.com/v1/chat/completions',
        'rate_limit' => 100, // requests per hour
    ];
    return $abilities;
} );

// Using an AI ability in your code
$response = wp_abilities()->request( 'content_generation', [
    'prompt' => 'Generate a blog introduction about WordPress 7.0',
    'max_tokens' => 150,
    'temperature' => 0.7,
] );

#Built-In AI Features

WordPress 7.0 ships with several AI-powered features enabled by default when API keys are configured:

1. Smart Content Suggestions: AI analyzes your content and suggests improvements for readability, SEO, and engagement
2. Auto-Alt Text Generation: Automatically generates descriptive alt text for uploaded images
3. Content Summarization: Create excerpts and summaries with one click
4. Translation Assistance: AI-powered translation suggestions for multilingual sites
5. Code Generation: Generate custom CSS, template parts, and block patterns from natural language descriptions

#The New “Connectors” Page

One of the practical areas to watch is the dedicated “Connectors” direction. For site teams, the useful question is how AI providers are configured, who can access credentials, and whether the setup can be audited without depending on several unrelated plugins.

#Privacy and Security Considerations

The Abilities API also raises privacy and governance questions. Site administrators should check which content types can be processed by AI, how credentials are stored, what gets logged, and whether sensitive customer data could leave the site through an AI workflow.

#Admin Interface Redesign

WordPress 7.0 continues the admin modernisation work that started around the block editor and Site Editor. For larger sites, the practical question is not whether the admin feels newer, but how the changes affect custom post types, editorial plugins, permissions, and internal publishing workflows.

#Design Philosophy

The redesign follows a “content-first” philosophy that minimizes distractions and puts the focus on creating and managing content. The classic WordPress admin menu has been reimagined as a collapsible sidebar that can be hidden to maximize screen real estate. Dashboard widgets are now modular blocks that users can rearrange, resize, or remove based on their preferences.

Areas to test include:

• Navigation paths: Check the admin journeys editors and operators use every day
• Contextual actions: Verify that plugin actions still appear where teams expect them
• Dark Mode: Native dark mode support for reduced eye strain
• Keyboard Shortcuts: Comprehensive keyboard navigation for power users
• Mobile-First: Fully responsive design that works directly on tablets and phones

The admin refresh already covers a wide surface area, but it stays in motion through the beta: core can still refine details ahead of the April target.

#Customization and Extensibility

Developers can extend the new admin interface using familiar WordPress hooks and filters, along with new React-based APIs. Custom admin pages can now be built as React components that integrate with the core interface. The REST API powers all admin interactions, making it easier than ever to build headless or decoupled WordPress applications.

#PHP 7.4 Requirements & Benefits

WordPress 7.0 raises the minimum PHP requirement from 5.6 to 7.4. For new builds this is routine, but older installations still need a hosting, plugin, theme, and custom-code check before production upgrades.

#Why PHP 7.4?

PHP 7.4, released in November 2019, introduced language features that WordPress 7.0 now depends on for tighter performance:

• Preloading: OPcache preloading reduces startup time by 30-50%
• Typed Properties: Improved code reliability and IDE support
• Null Coalescing Assignment Operator: Cleaner, more maintainable code
• Spread Operator in Arrays: Better performance for array operations
• FFI (Foreign Function Interface): Potential for high-performance extensions

#Performance Improvements

Sites upgrading to WordPress 7.0 with PHP 7.4 typically see:

#Checking Your PHP Version

Before upgrading to WordPress 7.0, verify your PHP version through the WordPress admin dashboard under Tools > Site Health > Info > Server. If your server runs an older PHP version, contact your hosting provider to upgrade. Most reputable hosts already support PHP 7.4 or higher, often through simple control panel settings.

#How to Prepare Your Site

Preparing for WordPress 7.0 requires careful planning to ensure a smooth transition. Follow this comprehensive checklist to minimize downtime and prevent issues.

#Pre-Migration Checklist

1. Audit PHP Compatibility

   • Check current PHP version in Site Health
   • Contact hosting provider if upgrade needed
   • Test PHP 7.4 on staging environment

2. Inventory Your Extensions

   • List all active plugins and themes
   • Check WordPress.org for 7.0 compatibility badges
   • Contact developers for unverified extensions
   • Identify alternatives for incompatible plugins

3. Review Custom Code

   • Search for deprecated functions in custom themes/plugins
   • Update code using WordPress 7.0 coding standards
   • Test custom post types and taxonomies

4. Backup Everything

   • Database backup via phpMyAdmin or WP-CLI
   • File backup including wp-content directory
   • Test backup restoration procedure

5. Set Up Staging Environment

   • Clone production site to staging
   • Perform test upgrade on staging first
   • Verify all critical functionality

#How to prepare without guessing the migration

Writing a step-by-step “how to migrate to 7.0” guide before 7.0 has shipped is dishonest. The version-specific commands, the database upgrade routine, the new admin settings: none of it is final. Anyone publishing exact migration steps today is filling in blanks with assumptions.

What you can do now is reduce future migration cost regardless of what 7.0 looks like. The work is unglamorous and pays back on every release, not just this one.

Audit the parts of the stack most likely to break on a major upgrade:

• Themes still using functions.php template tags in place of block themes. Convert to block themes or plan the lift.
• Custom Gutenberg blocks built against early @wordpress/scripts versions. Pin and test against the latest stable.
• Page builders with their own rendering layer. These are the most common cause of “we cannot upgrade” debt.
• Custom REST endpoints without versioning. Add /v1/ namespacing now so a future bump is non-breaking.

Set up the boring infrastructure that lets you upgrade quickly when 7.0 does ship:

• A staging environment that mirrors production PHP version, plugin set, and content volume. Database parity matters more than people expect.
• Automated backups with a tested restore path. An untested backup is theatre.
• Plugin and theme updates running on a regular cadence, not deferred until the next major. Sites stuck on 6.0 are stuck because nobody updated 6.1 through 6.8.
• A short list of plugin authors you trust, with email contacts. When 7.0 ships, you will want to know within a week which of your plugins are tested against it.

When 7.0 actually reaches RC on the official release calendar, the upgrade path is the same one that has worked for every major WordPress release: run it on staging first, watch the error log, wait two to four weeks past general availability before touching production for client sites, and read the official field guide post on Make WordPress before assuming any third-party guide (this one included) reflects what actually shipped.

#Troubleshooting Common Issues

Despite thorough preparation, issues may arise during or after migration. Here are solutions to common WordPress 7.0 problems.

#PHP 7.4 Compatibility Issues

White Screen of Death

• Check PHP error logs for fatal errors
• Identify incompatible plugins by deactivating all and reactivating one by one
• Update or replace plugins using deprecated PHP functions

Deprecated Function Warnings

• Install Query Monitor plugin to identify deprecated calls
• Update custom code replacing deprecated functions
• Suppress warnings in production using error_reporting settings

#AI Integration Problems

Abilities API Not Responding

• Verify API keys are correctly configured
• Check rate limits haven’t been exceeded
• Ensure firewall allows connections to AI provider endpoints

Slow AI Response Times

• Implement caching for AI-generated content
• Use local AI models for sensitive data
• Configure fallback providers

#Real-time collaboration (historical troubleshooting notes)

WebSocket Connection Failures

• Verify hosting supports WebSocket connections
• Check firewall isn’t blocking port 443 for secure WebSockets
• Test with caching plugins disabled

Editing Conflicts

• Ensure all users have unique sessions
• Clear browser cache and cookies
• Check for plugin conflicts with heartbeat API

#What to do in the 7.0 release week

With RC4 published, the useful work is operational: staging upgrade, plugin compatibility checks, WooCommerce and LMS flow tests, and a rollback plan before production.

Watch the Make WordPress core blog, Gutenberg release notes, and the trac milestone for last-minute field-guide changes. For an existing project on 6.x, keep block themes, theme.json, and the REST API as the forward-compatible baseline.

If you want help auditing a stack for upgrade readiness, our WordPress development team does that work for production sites every release cycle.