Guess Who Got A Makeover?: What’s New In WordPress 7.0 and What It Means For Your Site.

If you've been running a WordPress site for more than five minutes, you know the update notifications never stop. Most of the time, you click update, nothing looks different, and life goes on. What's new in WordPress 7.0 is a different story. This is a milestone version, the kind that changes how the platform actually works, and it will affect you whether you're a DIY site owner, a small business owner who hired someone to build your site, or a complete beginner still figuring out what a “block” is.

The official release notes read as if they were written by developers for developers. (Because they were.) If you opened them and immediately closed the tab, I get it. So here's the plain-English version of every WordPress 7.0 update that matters, with my honest take woven in throughout.

First, the Big Picture

WordPress 7.0 shipped with more than 400 fixes and improvements across three major areas:

1. WordPress built the infrastructure for AI. You still bring your own. Not a plugin. A centralized connection layer built into the platform itself.
2. The dashboard got a serious visual and usability overhaul.
3. Designers and editors got more control over how things look and behave without needing a developer.

There's also a section below for the stuff that sounds like a foreign language. I'll translate that too, because even if you're not a developer, understanding what's happening under the hood helps you make better decisions about your site.

What Site Owners Need to Know

WordPress Now Has a Built-In AI Connection Hub

This is the biggest thing in 7.0, full stop.

WordPress now has a native AI client, which means it can connect to AI models like ChatGPT (OpenAI), Claude (Anthropic), or Google's AI directly from your dashboard. You go to Settings > Connectors, add your API key for whichever AI provider you want to use, and WordPress handles the routing from there.

What does that mean in practice? Before this, every AI-powered plugin had to build its own connection to an AI model from scratch. That meant you might have three plugins, each requiring its own API key setup, each talking to AI in a completely different way. Now there's a single central connection point that plugins can tap into. And because the system is “provider-agnostic” (translation: not locked to one AI brand), you choose your AI the same way you choose your email service.

My take: This is the foundation, not the finished house. Right now it's plumbing. The interesting part will be what gets built on top of it. Watch for plugins in the next 6-12 months that leverage this heavily. If you're not using any AI-powered plugins yet, you won't notice a difference today. But this is coming for all of us.

The Dashboard Looks Different (In a Good Way)

WordPress has a new admin color scheme called “Modern.” Higher contrast, cleaner typography, updated colors throughout: headers, the customizer, all of it. It's not a dramatic overhaul, but it feels more current and less like logging into a 2014 website.

Navigation between screens now slides with a smooth animation instead of hard-jumping. Small thing, but it makes the experience feel noticeably less clunky.

If you don't love the new look, you can switch it back. Go to Users > Profile in your dashboard and look for the color scheme picker. WordPress has offered multiple color options for years. Modern is just the new default.

There's a New Keyboard Shortcut That Actually Saves Time

Press ⌘K (Mac) or Ctrl+K (Windows/PC) anywhere in the dashboard, and a command palette opens. Think of it like a search bar that does things: jump to a page, start a new post, open a setting. You don't have to click through menus to get there.

If you've ever used the search bar in Notion or Spotlight on a Mac, it's the same concept. Once you get used to it, you'll use it constantly. This is the kind of small change that turns out to be a big deal for people who spend a lot of time on their dashboards.

You Can Now Compare Two Versions of a Page or Post Visually

WordPress has always had a revision history, meaning you could go back and see old versions of your content. But the old way of comparing revisions was clunky: mostly text-based, hard to scan, not particularly intuitive.

In 7.0, there's now a visual slider that lets you switch between two versions of a page or post and see exactly what changed, where. Color indicators show you the location and size of each change. Click a change, and it jumps to that spot on the page.

If you edit your own content frequently, or work with a team where multiple people touch the same pages, this is genuinely useful. No more squinting at two walls of text trying to spot the difference.

Fonts Finally Have a Dedicated Management Page

The Font Library now has its own dedicated page in the dashboard. Upload custom fonts, install fonts from Google Fonts, and manage everything from one place.

Previously, font management was scattered depending on your theme. Block themes had some access, classic themes had almost none, and the experience was inconsistent at best. Now it's centralized and works the same regardless of your theme type. This should have existed years ago.

You Can Hide Blocks by Device Type

This one is big for mobile layouts, and it's something site owners have been asking for forever.

You can now tell a specific block (a sidebar widget, a large image, a decorative element, a call-to-action box) to show or hide based on whether someone is on mobile, tablet, or desktop, without affecting the other views. No plugin. No custom code. It's right there in the block settings.

Here's a real example of how you'd use this: Say you have a wide promotional banner that looks great on desktop but gets cut off and looks broken on mobile. In 7.0, you hide that block on mobile and build a different, mobile-optimized version that only shows on smaller screens. Two blocks, each doing one job, each visible only where it belongs. Clean.

If you've ever tried to make your WordPress site look right on a phone and felt like you were fighting the entire platform, this is the feature you've been waiting for.

Gallery Images Now Open in a Lightbox With a Slideshow

If you use the Gallery block, your images can now open in a full lightbox overlay with a slideshow option, built in, no plugin needed.

Here's how it works: Add a Gallery block to a post or page. Click the link icon in the toolbar. Select “enlarge on click.” Done. When visitors click an image, it opens full-size in an overlay, and they can click through the rest of the gallery as a slideshow.

Before 7.0, getting this behavior required a plugin like Envira Gallery or a similar one. Now it's native.

You Can Embed a Video as a Section Background

The Cover block (the one that lets you put text over an image, commonly used for hero sections and banners) now also supports video backgrounds.

Previously, you needed a page builder plugin or custom code to pull this off. Now you add a Cover block, upload or embed a video instead of an image, and your text floats over it. That's it.

User Registration Got More Secure by Default

When you add a new user to your WordPress site, you assign them a role: Subscriber, Contributor, Author, Editor, or Administrator. Each role has different levels of access, with Administrator being the highest.

In 7.0, the Administrator and Editor roles have been removed from the default role selector when adding new users. This matters because accidentally giving someone admin access is one of the most common security mistakes WordPress site owners make, and it can have serious consequences. Removing those options from the default dropdown makes the mistake much harder to stumble into.

If your site previously had Administrator or Editor set as the default role, WordPress Site Health (found at Tools > Site Health) will flag it after updating, so you can correct it.

What's New in WordPress 7.0 for Developers: Decoded

Here's where the official release notes go full developer-speak. I'm going to translate each item, because even if you're not writing code yourself, understanding what these changes do helps you have smarter conversations with the people who are.

WP AI Client and “Connectors API

You already know about the AI hub from the section above. The WP AI Client is the software that manages the connection between WordPress and the AI provider you've plugged in. Think of it as the switchboard operator: it receives requests from plugins, routes them to the appropriate AI model, and returns the response.

The Connectors API is the set of rules and infrastructure that makes all of this work securely. It's what handles storing your API keys securely, registering with different AI providers, and ensuring the right plugin talks to the right model.

What it means for you: You don't touch any of this directly. But if a plugin you use adds an AI feature, it can do that without requiring you to set up a separate AI account just for that plugin. It all flows through the same central connection you set up once.

What it means for developers: There's now a standardized, officially supported way to build AI into WordPress plugins. No more reinventing the wheel for every project. The API handles authentication, routing, and model preferences consistently across the entire ecosystem.

Client-Side Abilities API

This one sounds intimidating, but the concept is straightforward. “Client-side” just means it runs in your browser rather than on WordPress's server. When you load your WordPress dashboard, your browser is the client. The server is the computer running your website behind the scenes.

The Abilities API is a catalog system. It lets AI-powered plugins say “here's what I can do” and then check “which AI model is best equipped to do it?” So instead of a plugin blindly sending every task to the most powerful (and expensive) AI model available, it can match the task to the most appropriate model. Simple task, lightweight model. Complex task, more capable model.

What it means for you: AI features in plugins should get smarter, faster, and cheaper to run over time. You likely won't see a settings page for this. It just works better in the background.

What it means for developers: You can now build plugins that are genuinely intelligent about which AI capabilities they use and when. The command palette in the dashboard also hooks into this system, so AI-powered actions can surface right where users are already working.

Iframed Editor

An iframe is essentially a window inside a window. Imagine a picture frame hanging on a wall: the frame is your WordPress dashboard, and the picture inside it is your post editor. An iframed editor runs inside that kind of contained frame.

Why does this matter? Because when your editor runs inside its own isolated frame, it's protected from styling conflicts. Here's what that means in practice: your theme has its own fonts, colors, and layout rules. Plugins also add their own styles. Without an iframe, all of those styles can bleed into your editor and make things look wrong, move things around, or cause unexpected behavior while you're trying to write and edit. The iframe keeps all of that out.

In 7.0, the iframed editor is now enforced when all blocks in a post use the current Block API (version 3 or higher). If any older blocks are present, WordPress automatically falls back to the non-iframe version to maintain compatibility.

What it means for you: Your editing experience should be more stable and consistent. If something in your editor looks slightly off after updating to 7.0, the most likely cause is an older plugin that adds blocks to your editor but hasn't been updated yet. Check your plugins list and update anything with available updates. If the problem persists, that plugin may not yet be compatible with 7.0.

What it means for developers: If you're building or maintaining blocks, make sure they're declared as Block API version 3 or higher in block.json. Older blocks won't break, but they'll opt the entire editor out of the iframe, which is not the experience you want to ship.

Block Hooks for Custom Post Types

A block hook is a feature that lets a block automatically insert itself in the right place on a page, without needing to be placed manually each time. Think of it like a default template rule: “whenever this type of content appears, always show this block alongside it.”

Custom post types are content types that go beyond the standard Posts and Pages that WordPress ships with. If a developer has set up your site with a portfolio section, a testimonials section, a team member directory, or a services catalog, each of those is probably a custom post type. They look like regular content in the dashboard, but they're built separately and stored separately.

Before 7.0, block hooks worked well for standard posts and pages but had limitations with custom post types. The fix in 7.0 moves the logic to a better place in the codebase so it works consistently across all content types.

What it means for you: If your site has custom content types built by a developer, blocks associated with those content types (like a “related items” block, or a sidebar that always appears with a specific content type) should now appear more reliably and in the right place.

What it means for developers: The block hooks logic has moved from individual post type filters to the REST controller. If you've built custom block hook logic tied to specific post type filters, test your implementation after updating.

PHP-Only Block Registration

To understand this one, you need to know that WordPress runs on two separate layers: the server (PHP) and the browser (JavaScript). When a developer builds a custom block, they've traditionally had to write code in both languages: PHP to handle what happens on the server, and JavaScript to handle what appears in the editor and on the page.

That's double the code, double the potential for something to go wrong, and double the maintenance work every time something needs to change.

WordPress 7.0 now allows blocks to be created and registered using only PHP. The system handles the JavaScript side automatically. You declare the block's attributes and a render function in PHP, and add ‘autoRegister' => true to the block's settings, and WordPress exposes it to the editor without requiring a separate JavaScript build process.

What it means for you: Custom blocks built by your developer should take less time to build and have fewer moving parts that can break. Simpler architecture means faster delivery and easier maintenance. If you're paying a developer by the hour to build custom functionality, this is the kind of change that can meaningfully affect your project timeline.

What it means for developers: This is a genuine quality-of-life improvement for server-rendered blocks. The auto-registration workflow is clean, and the automatic DataForm inspector controls are a nice bonus. Worth evaluating for any new block projects.

Interactivity API: watch() Function

The Interactivity API is a system that WordPress introduced to let blocks respond to user actions on the page without requiring a full page reload. Before this existed, making something on a page react to a user's action (like filtering a list, toggling content, or updating a count) required either a heavy JavaScript framework or a clunky reload-the-whole-page approach.

The new watch() Function in 7.0 extends this further. It lets a block subscribe to a piece of data and automatically re-run a process whenever that data changes. Like a formula in a spreadsheet: when one cell changes, everything that depends on it updates automatically.

What it means for you: More dynamic behavior on your site without the performance cost. Things like live search filters, real-time inventory counts, interactive quizzes, or content that updates based on user input all become more viable as native WordPress features rather than requiring third-party tools to pull off.

What it means for developers: The watch() function pairs well with the existing state and derived primitives. If you're building anything that needs to react to state changes across components, this fills a real gap. The data-wp-watch directive also integrates cleanly into the existing DOM-based API.

DataViews and DataForms

DataViews is the system WordPress uses to display lists of content inside the dashboard. Think about how the All Posts screen looks, or the Media Library, or the list of pages in the Site Editor. That interface, the way items are displayed, filtered, and sorted, is DataViews.

DataForms is the companion system for editing individual items in a structured way.

In 7.0, both got improvements: a new Activity layout for showing chronological updates, a new Details layout for more comprehensive item views, improved modal appearance, and the ability for third-party plugins to register their own field types into the system.

What it means for you: If you spend time in the Site Editor managing pages, patterns, or templates, the interface for doing that is more polished and capable. The Activity layout, in particular, is useful for sites with frequent content changes across a team.

What it means for developers: The Field API registration for third-party types is the significant one here. You can now integrate custom data types into DataViews in a consistent, officially supported way rather than hacking around the existing interface.

Pattern Editing and contentOnly Mode

Patterns are reusable layouts you can save and drop into any page or post. Think of them like templates for sections of your site: a testimonial layout, a three-column feature section, a call-to-action block. Build it once, reuse it everywhere.

“contentOnly mode” is a setting that locks a pattern's structure, so that people editing the page can change only the text and images within it, not the layout, colors, spacing, or design. It's a guardrail. A developer or designer defines the pattern as it should look, and editors can fill in the content without accidentally breaking the design.

In 7.0, contentOnly mode is applied more broadly by default, especially for patterns that previously had no restrictions on editing their inner blocks. There are also new controls for opting out of it in specific situations, and a new parent-child tree view for certain block types that makes it easier to understand how a complex pattern is structured.

What it means for you: If you use patterns on your site and notice after updating that certain blocks inside a pattern can no longer be edited the way they used to be, this is the most likely explanation. The fix depends on how the pattern was originally built. If a developer set up your patterns, loop them in. If you built the patterns yourself, check the pattern settings for contentOnly options.

What it means for developers: If you're building patterns for clients or distributing them in themes, audit your patterns after updating. Any pattern where inner blocks were previously freely editable may now default to contentOnly behavior. Make sure blocks that should be editable have "role": "content" declared in block.json so they stay accessible in the editor.

CodeMirror Update to v5

CodeMirror is the code editor that appears whenever you edit code directly inside WordPress: the Custom CSS field in the Customizer, the HTML editor in a block, or the theme file editor if you use it.

It's been updated to version 5, along with several related tools used for checking code quality (CSSLint, HTMLHint, JSONLint). The old JavaScript parser (Esprima) has been replaced with Espree, which adds support for modern JavaScript syntax.

What it means for you: If you paste custom CSS into the Customizer's Additional CSS field, or occasionally edit HTML in the block editor, the code editor experience is cleaner and catches more errors. The difference is subtle for light use, but noticeable if you spend real time in those fields.

What it means for developers: The Espree swap is the practical change here. ES6+ syntax is now properly supported in the linter, which matters if you're working in the theme file editor or writing JavaScript directly in WordPress admin contexts.

PHP Minimum Version Now 7.4

PHP is the programming language that WordPress runs on. It lives on your web server, not your computer, and your host manages which version is active.

WordPress has officially dropped support for PHP 7.2 and 7.3. Those versions are end-of-life, meaning they no longer receive security updates from PHP's own developers. Running WordPress on them was already a security risk. Version 7.4 is now the minimum required to run WordPress 7.0.

To check what PHP version your site is running: go to Tools > Site Health in your WordPress dashboard, click the “Info” tab, and expand the “Server” section. Your PHP version will be listed there.

Most reputable hosts are running PHP 8.x by now, well above the 7.4 minimum. If you're on a managed WordPress host (WP Engine, Kinsta, Flywheel, Cloudways), you almost certainly meet this requirement and may not need to do anything. If you're on budget shared hosting you haven't looked at in years, check before you update.

What it means for you: If your PHP version is below 7.4, updating to WordPress 7.0 could break your site. Check first. Most hosts let you switch PHP versions yourself in the hosting control panel, or you can ask support to do it for you.

What it means for developers: If you're maintaining client sites, audit PHP versions before rolling out the 7.0. update. Also worth noting: PHPMailer (the library WordPress uses to send email) has been updated to 7.0.2 in this release, which includes a bug fix for sender address handling.

Should You Update?

Yes, but not immediately, not without a backup, and not late Friday night. You know the drill.

The standard protocol applies here, as with every major WordPress update. And given what's new in WordPress 7.0, it's worth taking this one seriously:

1. Back up your site first. Full backup: files and database. If your host doesn't do this automatically, use a plugin like UpdraftPlus.
2. Update your plugins and themes before updating WordPress core, or at a minimum, verify they're compatible with 7.0.
3. Check your PHP version. Tools > Site Health > Info > Server. You're looking for PHP 7.4 or higher.
4. Test on a staging environment if you have one. If you don't know what that means, ask your host. Many managed hosts offer one-click staging.

If you're on managed WordPress hosting (WP Engine, Kinsta, Flywheel, etc.), they'll typically handle a lot of this and roll out major versions in a controlled way. If you're on shared hosting, managing everything yourself, wait a few weeks. Let the plugin ecosystem catch up on compatibility updates first.

Conclusion

WordPress 7.0 is the most consequential release in a long time, and what's new in WordPress 7.0 goes well beyond surface-level changes. The AI infrastructure alone puts WordPress in a different category than it was six months ago, not because AI features are everywhere yet, but because the plumbing is now in place for them to arrive fast. The dashboard improvements are overdue and welcome. The design and editing features give site owners real control that previously required plugins, a developer, or both.

The under-the-hood changes matter even if you never touch them yourself, because they affect what your site can do, what your developer can build, and how reliably all of it holds together.

This is a version worth updating to. Just do it right.

THIS SITE USES AFFILIATE LINKS. THERE’S NO EXTRA COST TO YOU, BUT I RECEIVE A SMALL COMMISSION WHEN YOU USE THEM.

What's New in WordPress 7.0 FAQ

---

PIN ME!