A Quick Recap: Why 7.0 Took So Long

The original 2025 roadmap called for three major releases ending with 7.0 by year’s end. That didn’t happen. Legal battles, organizational shifts, and Automattic stepping back from core contributions slowed everything down. WordPress 6.8 and 6.9 (“Gene”) shipped, but 7.0 got pushed to 2026.

The silver lining? The extra time gave the core team room to think bigger. WordPress 7.0 isn’t just an incremental bump — it marks a genuine turning point for the platform.

Real-Time Collaboration Arrives
(Gutenberg Phase 3)

The headline feature of 7.0 is the official launch of Gutenberg Phase 3: Collaboration. For the first time in its two-decade history, WordPress is evolving from a single-author writing tool into a collaborative platform.

Multiple users will be able to edit content simultaneously with real-time presence indicators showing who’s working where. Visual revisions let you compare page versions side by side, making it easy to review what changed and when. The collaboration features build on the commenting and annotation tools introduced in 6.9, and the team has hinted that deeper co-editing capabilities will continue to roll out incrementally through 7.1 and 7.2.

If you’ve ever juggled Google Docs alongside WordPress just to collaborate with your team, this release is for you.

AI Baked Into Core

WordPress 7.0 introduces a native AI Client and API — a provider-agnostic framework that lets plugins and themes tap into generative AI services without being locked into any single vendor. Think of it as a universal adapter: your site talks to the AI Client, and the Client talks to whichever AI provider you choose.

Even more interesting is the new MCP (Model Context Protocol) Adapter, which allows AI agents like Claude and Cursor to discover and interact with your site’s capabilities directly. Combined with a new Abilities API, this opens the door to AI-powered content generation, site management, and workflow automation that’s deeply integrated rather than bolted on.

The WordPress project has been clear about its principles here: transparency, user control, and alignment with WordPress values come first. AI is opt-in and configurable, not forced.

A Refreshed Admin Experience

The admin interface is getting a meaningful facelift through the continued expansion of DataViews and DataForms. These modern components replace the legacy WP List Tables with a cleaner, more app-like experience featuring inline filtering, flexible layouts, persistent custom views, and better visual consistency between the block editor and classic admin panels.

A new activity layout in DataViews, along with groundwork for registering third-party content types, signals that WordPress is serious about modernizing the admin without breaking backward compatibility. Expect cleaner typography, consistent spacing, and fewer full-page reloads as you manage your content.

New Blocks and Design Tools

Several new and improved blocks ship with 7.0:

• Icons Block — A native way to add and style icons without reaching for a plugin.
• Breadcrumbs Block — Built-in breadcrumb navigation that’s fully customizable within the editor.
• Enhanced Cover Block — Now supports video embed backgrounds for richer hero sections.
• Responsive Grid Block — A more flexible grid layout with proper responsive controls.
• Improved Heading Block — Additional styling and semantic options.

Behind the scenes, WordPress 7.0 also introduces the ability for PHP-only blocks and patterns to be generated server-side and auto-registered with the Block API, giving developers more flexibility in how they build and distribute block-based features.

Under-the-Hood Improvements

The technical changes in 7.0 are substantial:

• React 19 Upgrade — The block editor now runs on React 19, bringing performance gains and access to modern React features like concurrent rendering.
• Client-Side Media Processing — Image resizing and compression now happen in the browser before upload, reducing server load and speeding up the media workflow.
• Iframed Post Editor — The post editor will always render in an iframe regardless of block API version, improving style isolation and reducing conflicts between editor and front-end styles.
• PHP 7.4 Minimum — WordPress 7.0 drops support for PHP 7.2 and 7.3. The recommended version is PHP 8.3 or higher.

The 2026 Roadmap Beyond 7.0

WordPress is returning to a three-release cadence this year. After 7.0 in April, expect WordPress 7.1 around August 19 (timed to WordCamp US) and WordPress 7.2 in early December alongside the annual State of the Word address. Minor maintenance releases will fill the gaps on roughly six-to-eight-week cycles.

What Should You Do Right Now?

If you run a WordPress site, here’s how to prepare:

1. Test the beta. Spin up a staging environment and install WordPress 7.0 Beta to check your theme and plugins for compatibility. Don’t run it in production yet.
   
2. Check your PHP version. If you’re still on PHP 7.2 or 7.3, now is the time to upgrade. Talk to your host if you’re unsure. With FluxRunner, you’re in good hands: All FluxRunner WordPress websites get Php 8.4+ and MySQL 8.4+.
   
3. Audit your plugins. The React 19 upgrade and iframed editor may affect plugins that deeply customize the block editor. Test early.
   
4. Get excited about collaboration. If you work with a team, start thinking about how real-time editing could change your content workflow.

The Bottom Line

WordPress 7.0 represents the platform’s biggest leap forward in years. Real-time collaboration, native AI integration, a modernized admin, and serious performance improvements under the hood all point to a WordPress that’s ready for the next decade of the web. After a bumpy 2025, the project is back on track — and April 9 can’t come soon enough.

As for FluxRunner, we’re a modern day WordPress managed hosting service, and we’re ready for 7.0 from get go. You’ll simply enjoy seamless transition to the latest and greatest of WordPress.

What Is Object Caching?

Every time a visitor loads a page on your WordPress site, WordPress reaches into its database to fetch content, settings, user data, menus, and dozens of other pieces of information. For a typical page, this can mean 30 to 100 individual database queries happening in milliseconds. That is a lot of work happening in the background every single time someone visits your site.

Object caching solves this problem by storing the results of those database queries in a fast, temporary memory store. Instead of hitting the database every time, WordPress checks the object cache first. If the data is already there, it serves it instantly without touching the database at all. The site responds faster, uses fewer server resources, and handles traffic spikes far more gracefully.

Think of it like a notepad sitting on your desk. Rather than walking to the filing cabinet every time you need a piece of information, you write it down on the notepad for quick access. Object caching works the same way for your website.

What Is Redis Cache and How Does It Work?

Redis is the most widely used technology behind persistent object caching for WordPress. It is an open-source, in-memory data store that holds data in RAM rather than on a hard drive. Because RAM is much faster than reading from a disk or running a database query, Redis can serve cached data in microseconds.

By default, WordPress has a built-in object cache that only lasts for the duration of a single page request. Once that page finishes loading, the cache is thrown away. The next visitor has to start the whole process from scratch. Redis changes this by making the object cache persistent. It keeps that cached data alive between page loads, so repeat queries are served from memory instead of the database every single time.

This makes a huge difference for dynamic WordPress sites, especially WooCommerce stores, membership sites, and any site with logged-in users. These types of sites cannot rely solely on page caching because each user session is unique. Object caching is where the real performance gains come from in these cases.

Why Do Competitors Charge So Much for Object Cache?

Object caching requires a dedicated Redis server or process running alongside your website. That takes server memory and infrastructure to support. Most managed WordPress hosts treat this as a premium add-on because it costs them more to provision. Some charge $25 to $50 per month for a basic Redis add-on, and enterprise-tier plans at certain hosts can push the cost to $100 per month or more just for this one feature.

Hosts like WP Engine, Kinsta, and Pagely have historically gated Redis behind their higher-tier plans. That means small businesses, bloggers, and growing sites are often left paying slow database-driven response times on plans that do not include object caching. You end up paying more just to get performance that should come standard.

How FluxRunner Includes Object Cache on Every Plan

At FluxRunner, object cache is not a bolt-on feature. It is baked into the infrastructure for every WordPress site we host, from our entry-level Starter plan at $8 per month all the way up to our Full Power plan. You do not need to request it, pay extra for it, or configure it yourself. It is simply on and working from day one.

This is possible because of the way FluxRunner is built. Each WordPress installation on our platform runs on its own dedicated resources, including its own CPU allocation, dedicated RAM, and SSD storage. Every site gets the infrastructure it needs to run object caching without fighting for shared resources with other websites on the same server.

Our platform is powered by the Flux Network, the world’s first 100% decentralized blockchain-powered Web3 cloud. Sites are distributed across multiple nodes with dedicated resources per installation. This architecture naturally supports persistent in-memory caching because each site has isolated, consistent access to its own resource pool. There is no shared memory environment that would make object caching unreliable or expensive to scale.

What This Means for Your WordPress Site Speed

The real-world impact of object caching on WordPress performance is significant. Sites with object caching enabled typically see database query times drop by 50 to 80 percent. Page load times improve across the board, and the improvement is most noticeable on pages that rely heavily on dynamic content like product listings, account dashboards, and search results.

For WooCommerce stores, object caching means faster product pages, quicker cart updates, and smoother checkout experiences. For content-heavy sites, it means faster archive pages, category listings, and widget-heavy sidebars. For membership sites, it means logged-in users get fast, responsive pages rather than slow database-heavy loads on every click.

Google also factors page speed into its ranking algorithm. A faster site means better Core Web Vitals scores, which can directly contribute to improved search rankings. With object caching included on every FluxRunner plan, you get a performance advantage that many sites on competing platforms are paying a premium to access.

Object Cache vs Page Cache: What Is the Difference?

It is worth understanding how object caching differs from standard page caching, since both are common caching strategies for WordPress.

Page caching saves a fully rendered HTML version of a page and serves that static file to visitors instead of rebuilding the page from scratch each time. It is very effective for public-facing pages that do not change often and look the same for every visitor. Most WordPress caching plugins, like WP Rocket or W3 Total Cache, primarily focus on page caching.

Object caching works at a deeper level. It caches individual database query results, options, transients, and other computed data used by WordPress and its plugins. It is particularly useful for dynamic pages that cannot be fully cached as static HTML, such as cart pages, account pages, and pages that vary based on the user who is logged in.

In practice, the two types of caching work best together. Page caching handles the public-facing static content efficiently, while object caching handles the dynamic, database-heavy backend work. FluxRunner provides object caching as standard, giving you the foundation to layer other caching strategies on top.

Get Enterprise-Level Performance Without the Enterprise Price Tag

Object caching used to be a feature reserved for high-budget hosting plans or technical users who could set up their own Redis server. FluxRunner changes that by including it on every plan as a standard part of what managed WordPress hosting should be.

Whether you are running a personal blog, a growing WooCommerce store, or a high-traffic business website, you get the same performance infrastructure. No upgrade required. No add-on fees. No configuration needed.

If you are currently paying a competitor extra for object caching, or running a WordPress site without it at all, FluxRunner plans start from just $8 per month. That includes dedicated resources, object cache, multi-node redundancy across the decentralized Flux Network, and everything else you need to run a fast, reliable WordPress site. Check out FluxRunner’s plans and see what you have been missing.