August 16-19, 2026 | Phoenix Convention Center, Phoenix, Arizona
WordCamp US 2026 returns for another year, this time in Phoenix, Arizona, for four days, August 16 to 19. It comes at a moment of real energy for WordPress, as artificial intelligence reshapes everyday workflows, the business of building and maintaining sites is shifting, and new people keep discovering the platform every day. Four tracks address this moment, covering AI, Honing Your Skills, Technical WordPress, and Beginner WordPress. Between them, there is something for everyone, whether you lead an agency, freelance for local clients, write code for a living, or are building your very first site. Whatever draws you in, you will leave Phoenix better equipped and better connected than ever.
Phoenix itself rewards anyone who adds a day or two to their trip. The capital of Arizona sits in the Sonoran Desert and pairs a lively downtown with a rich arts and food scene. The Roosevelt Row arts district is known for its galleries, murals, and independent restaurants. It is also home to one of the largest art walks in the region. Nearby, Chase Field and the Footprint Center host professional baseball and live shows, and the surrounding desert offers striking scenery at places like Papago Park and the Desert Botanical Garden.
Start with Contributor Day
The week begins with Contributor Day, a full day set aside for giving back to the project that makes everything else possible. Attendees will gather in teams to improve WordPress itself, from Core code and documentation to design, training, accessibility, and translation.
WordPress is so unique because we’re not just a product; we’re a movement.
Matt Mullenweg, WordPress Cofounder
Contributor Day is open to everyone, whatever your skills, and whether or not you have ever contributed before. Come and experience the open source collaboration that is at the heart of the project. Signing up in advance helps us prepare our veteran contributors and provide you with the best experience.
Explore Real-World Projects on Showcase Day
Day 2, Showcase Day, is dedicated to real-world WordPress projects and focuses on how teams develop features, manage publishing, and run demanding sites at scale. It brings to life the kind of work collected in the WordPress Showcase, the directory of standout sites built on the platform, from global brands like Disney to community publishers and institutions like NASA. Past WordCamp US Showcase days have brought teams from the likes of Wikimedia and CANCOM to explain how they manage large, high-traffic systems. Other sessions took a builder’s perspective on catching bugs faster with automated testing and even running the Block Editor inside a custom app.
Dive Into Two Conference Days
The two main conference days will bring a full slate of sessions across four tracks. First among them is the AI track, which treats the technology as a tool to handle with care rather than a headline to chase. Its sessions set guardrails for AI-assisted development, prepare for a web where AI agents become the visitors a site must serve, and weigh the legal and ethical questions of putting AI tools in the hands of clients. Speakers from companies like Elementor will be taking a look at where the web is heading, while keeping the focus on what teams can adopt today without giving up control of their work.
The Technical WordPress and Honing Your Skills tracks cover the craft and business of building with WordPress. On the technical side, sessions dig into modern development workflows, automated testing with tools like the browser-based WordPress Playground, and plugin pipelines. The Honing Your Skills track adds practical guidance on pricing, maintenance, and how the agency model is changing as clients ask for more. The Beginner WordPress track keeps the door open for newcomers, with approachable sessions that make your first WordCamp less daunting. Hands-on work runs through all of these tracks, so alongside the talks, attendees will find workshops and working sessions where they can build something real and leave ready to apply it to their own projects.
Not all of the value happens in the session rooms. On the show floor, the Happiness Bar is a free, drop-in help desk where you can sit down with a volunteer WordPress expert and work through whatever has you stuck. The Sponsor Hall next door is where many of the best unplanned conversations happen, and its Career Corner gives anyone weighing their next move a relaxed place to browse the job board, meet company reps, and see who is hiring across the ecosystem.
Plan Your Trip to Phoenix
Getting to Phoenix is straightforward. The Phoenix Convention Center sits in the heart of downtown, less than five miles from Phoenix Sky Harbor International Airport (PHX) and about 15 minutes away on the Valley Metro light rail. WordCamp US has a room block at the Sheraton Phoenix Downtown, close to the convention center, so book your hotel before the block fills, and reserve your ticket if you have not already. The full event lineup and details live on the WordCamp US 2026 site, and the conference closes with an evening social before everyone heads home.
Whether attending in person or following along online, share your experience and help welcome others to the WordPress community. Use the #WCUS and #WordPress hashtags to tell your story on social.
In this Open Web Conversations episode, host Anne Bovelett chats with lawyer Carlo Piana about open source software’s legal challenges, AI’s impact on coding, and the importance of proper licensing and attribution.
In episode 132 of the Gutenberg Changelog podcast, host Birgit Pauli-Haack and guest Ellen Bauer explore the latest updates within the WordPress ecosystem. The conversation centers on the releases of Gutenberg 23.4 and 23.5, the recent WordPress 7.0.1 maintenance update, and the strategic roadmap for the upcoming WordPress 7.1.A significant portion of the episode is dedicated to major merge proposals destined for WordPress 7.1 that aim to evolve the core software.
These include “Core Abilities” for AI agent integration, the new “Knowledge” post type for managing site standards and guidelines, and “Design System Theming” to enhance consistency and accessibility via CSS custom properties. The hosts also discuss the shift toward mandatory iframing for the post editor in block-based themes, a critical architectural change designed to improve content rendering.Beyond core architecture, the episode highlights user-focused improvements such as enhanced responsive editing controls, which now allow for granular canvas resizing without preset limits. They also touch on media-related updates, including aspect ratio controls in the media editor, and improvements to the Icon block.
With WordPress 7.1’s Beta 1 approaching, Birgit and Ellen emphasize the importance of community involvement, encouraging developers and site owners to participate in ongoing “Call for Testing” efforts. Whether discussing React 19 status or new grid layout properties, the episode serves as a comprehensive briefing for anyone looking to stay current with the rapidly changing landscape of the block editor and WordPress core development.
After a four-week break — courtesy of a sciatic nerve with strong opinions — I’m happy to be back in by office chair and in your inbox. There is plenty to catch up on.
Beyond the updates on the new WordPress and Gutenberg versions, you’ll find stories below from WordPress veterans on migrating to and working with block themes on client sites and dive into more complex theme solutions or
Don’t let me keep you from your light summer reading.
Have a splendid weekend ahead!
Yours, Birgit
Developing Gutenberg and WordPress
The team around release lead Aaron Jorbin pushed WordPress 7.0.1 Maintenance release out the door to update millions of WordPress sites. The update covers 17 Trac tickets and 14 Gutenberg PRs. The full list is available in the RC 1 announcement post from last week.
In WordPress 7.0.1 Fixes Registration Spam, wp_kses() CSS Corruption, and 7.0 Admin Design Glitches, I cover the most important fixes for end users and developers of this release. You’ll learn how the registration-spam loophole got closed, which admin design glitches were sanded off, and why developers can finally remove their wp_kses() CSS workarounds. Update your sites soon if auto-updates aren’t enabled.
Ryan Welcher compiled What’s new for developers (July 2026), and it’s all about the 7.1 cycle getting real: Beta 1 lands July 15, final release August 19 at WordCamp US. You’ll want to test responsive styling, the React 19 runtime flag, and Unicode email addresses now. Also on your radar: merge proposals for Core Abilities and Guidelines, the 40px component default, icons inheriting color, and Playground’s MCP support.
Berislav “Bero” Grgičak announced what’s new in Gutenberg 23.5, released July 1. The headliner: you can now drag the editor canvas to any width, with the device preview dropdown and resize handles working together for responsive editing. The experimental Media editor gains a magnified crop canvas, pixel-snapping handles, and Cover block support. Also notable: text shadows in Global Styles, flip and rotate controls for the Icon block, and a minimum WordPress version bump to 6.9.
For the next episode of the Gutenberg Changelog, I sat down with Ellen Bauer to chat about what’s coming next for WordPress. We dug into the latest Gutenberg plugin releases (23.4 and 23.5) and the recent WordPress 7.1 update. Plus, we walked through some big merge proposal, like the Design System Theming. our excitement around responsive styling coming to WordPress. It’s a packed episode full of news you won’t want to miss! The episode will land in your favorite podcast app over the weekend.
WordPress 7.1 roadmap and more calls for testing
Anne McCarthy published Roadmap to WordPress 7.1., scheduled for August 19, 2026. Longstanding styling gaps are being tackled: responsive styling and interactive-state styling let you adjust blocks per viewport or on hover — no custom CSS required. You’ll also find new Playlist, Table of Contents, and Tabs blocks, a smarter command palette, a Design → Identity screen, the admin bar inside the editors, a media editor modal, and expanded Unicode support for email addresses.
Also mentioned Real-time collaboration, Knowledge Guidelines, React 19 upgrade, Classic block deprecation have been punted since the posts came out. Beta 1 arrives July 15 and will settle which of the other Roadmap features are in and which will be punted to a future release.
Nikunj Hatkar, this year’s team rep of the Core Test team, posted a call for testing responsive styling. You’ll be able to style blocks differently for tablet and mobile right in the editor — no custom CSS or media queries needed. The underlying PR unifies the resizable canvas with the device-preview switcher. Fire up the linked WordPress Playground instance, walk through the four test scenarios, and share what feels intuitive or broken. Plugin and theme developers should test their canvas integrations, too.
Dennis Snell published a call for testing Unicode email addresses. With initial support merged, is_email() and sanitize_email() now accepting non-ASCII addresses like grå@grå.org, and validation aligns with the Web Hypertext Application Technology Working Group (WHATWG) spec. You’ll want to check your plugins and themes: the new WP_Email_Address class gives you structured access to local and domain parts, and a snippet lets you disable Unicode support until third-party integrations catch up.
Three Merge Proposals
Core contributors put together three merge proposal for new features to be added to Core for public comment.
Jorge Costa published a merge proposal to expand WordPress Core Abilitiesin WordPress, adding three read-only abilities covering settings, content, and users. Building on the Abilities API from 6.9, they give the AI Client real tools to call, so agents can understand your site’s configuration, posts, and people. Settings and post types opt in through a dedicated flag, and management abilities are planned for a later WordPress version.
Greg Ziółkowski published a merge proposal for Guidelines built on Knowledge, a new custom post type headed for WordPress 7.1. Knowledge gives your site one shared home for standards, memories, and notes — with revisions, capabilities, and REST access built in. Guidelines is the first feature on top, letting you capture voice, tone, and per-block rules right where writing happens. Although, originally aimed at WordPress 7.1, in their latest comment, Anne McCarthy indicated that it needs to simmer some more before it’s considered for inclusion in WordPress Core.
Andrew Duthie published a merge proposal for Design System Theming, bringing design tokens and a new theme component to WordPress. Built by the Gutenberg Components Team, it turns hard-coded admin styles into CSS custom properties, so your plugins and screens stay consistent and accessible. A color ramp tool generates harmonious, accessible scales from just two seed colors, and the user color scheme reaches the Site Editor — with dark mode on the horizon.
Plugins, Themes, and Tools for #nocode site builders and owners
Anne Katzeff published a tutorial exploring the WordPress Cover Block for parallax scrolls. You’ll learn how the Fixed Background setting turns a Cover block into a layered parallax effect — background, middle ground, and foreground text moving at different speeds. The post steps through nesting a second Cover block, switching which layer scrolls, and improving text readability with grouped backgrounds. A video tutorial rounds it out. She also demos her process in this YouTube video.
Carrie Dils shared a case study, One Header, Two Themes, on phasing a legacy Elementor site toward Full Site Editing without a rebuild or content freeze. Using ThemeSwitcher Pro to run two themes side-by-side, she built one shared header in a plugin that both themes render. You’ll learn from five real-world snags — WooCommerce’s hooked blocks, cascade conflicts, routing gaps, query-string bypasses — and why shipping the shared layer first de-risks everything after.
Gina Lucia compared WordPress block themes vs page builders on the Ollie blog. You’ll get a clear-eyed walkthrough of what classic themes, page builders, and block themes each handle — scope, design control, performance, lock-in, and maintenance — with side-by-side tables. Her conclusion: block themes combine sitewide design control with visual editing natively, so you rarely need a page builder anymore, though migration costs and team habits can justify keeping one.
Elliott Richmond explained why he spent 16 months turning 400+ holiday cottages into WordPress blocks. The kate & tom’s site moved from ACF flexible content to a native block theme, freeing the marketing team from waiting on custom widgets. You’ll appreciate his candor: 10,590 widgets migrated via a purpose-built plugin, re-run against fresh production snapshots, with flaky conversions fixed by hand. Even untuned, PageSpeed jumped from 22 to 67.
Wes Theron published a video tutorial, How to Create and Edit Navigation Menus in WordPress, for anyone getting comfortable with block themes. In under ten minutes, you’ll learn how to edit your menu with the Navigation block, add pages, posts, categories, and custom links, and build dropdown menus. Timestamps let you jump straight to the part you need — handy if dropdowns are the only thing standing between you and a finished header.
Theme Development for Full Site Editing and Blocks
Henrique Iamarino shared how the Automattic Design team built a WordPress theme without ever opening Figma. You’ll follow the making of Crafted, a production-ready theme created almost entirely in the WordPress Editor: Global Styles for typography and spacing, Create Block Theme to save edits to theme files, WordPress Studio for local review, and an AI assistant for finishing-touch hover CSS. His takeaway: the Editor is now a professional design surface.
Justin Tadlock explained how to dynamically load template parts in block themes on the Developer Blog. Instead of maintaining a pile of near-identical templates, you can hook into the render_block_data filter and swap a template part’s slug on the fly — say, a different sidebar per post category. His walkthrough covers early returns, fallback behavior, and file setup, and the technique works for headers, footers, and banners, too.
“Keeping up with Gutenberg – Index 2026” A chronological list of the WordPress Make Blog posts from various teams involved in Gutenberg development: Design, Theme Review Team, Core Editor, Core JS, Core CSS, Test, and Meta team from Jan. 2024 on. Updated by yours truly.
Jeff Paul announced what’s new in AI 1.1.0, the latest release of the canonical AI plugin. Two experiments headline, type-ahead text suggests inline ghost text as you write in the block editor, and key encryption secures your AI Connector API keys in the database. You’ll also find smarter content readiness checks with locale-aware counting, more control over guest comment moderation, a new core/read-settings Ability, and a peek at 1.2.0 plans.
Now also available via WordPress Playground. There is no need for a test site locally or on a server. Have you been using it? Email me with your experience.
Questions? Suggestions? Ideas? Don’t hesitate to send them via email or send me a message on WordPress Slack or Twitter @bph.
David Snead, director of the Secure Hosting Alliance and a long-time Internet policy leader, shares his perspective on the complexities that emerge when technological solutions like age verification are implemented in the digital infrastructure space. Dave’s reflection highlights how the push for more secure, regulated environments can unintentionally create barriers for vulnerable or less tech-savvy […]
Otter Blocks 3.2.0 is now live, bringing AI that builds full sections and pages, a redesigned AI writing toolbar, AI form autoresponders, a completely rebuilt Design Library, a new Content Slider block, more reliable forms, and full WordPress 7.0 support. This release focuses on the slowest part of building in the block editor: getting started….
AI assistants like Claude Code, Cowork, and ChatGPT are incredible productivity boosters, and if you wished that you could connect these AI tools with WordPress directly, then you’re not alone.
Lately, I have been using WordPress MCP by WPVibe to let my AI assistant manage my website, and it’s truly amazing how much time this saves. You can simply ask it to create a post, upload image, handle admin tasks, and more from a single conversational prompt.
In this step by step tutorial, I’ll show you how to connect your favorite AI tools with WordPress using MCP along with sharing a few work examples, so you can see what becomes possible when you combine WordPress + AI.
You can use the quick links below to jump to any section:
MCP stands for Model Context Protocol. It is as an open standard that lets AI assistants connect to outside tools and services.
Think of it as a universal adapter. Instead of every AI tool building a custom integration with every service, they all speak the same language, so any tool and service that support MCP can work together.
With a WordPress MCP, your AI assistant can see what your website supports and carry out tasks from a plain-text prompt. It does this using a connection WordPress already has built in (the REST API), so there’s nothing extra to install.
You can use WordPress MCP to manage your WordPress site and perform tasks including:
Draft and publish posts – Create blog posts as drafts, set titles, add categories and tags, and publish when you’re ready.
Upload media – Pull images from any public URL directly into your WordPress media library.
Manage categories and tags – Create or rename taxonomy terms and assign them to posts.
Run admin tasks – Flush your site cache, check which plugins are active, and activate or deactivate plugins.
Use plugin abilities – On WordPress 6.9+, many plugins register their own actions the AI can discover and run automatically
Each of these can be done from a plain-text prompt from your favorite AI tool like Claude Code, Cursor, ChatGPT, etc. I’ll show you the exact prompts once you’re fully set up.
What You Need Before Getting Started
Self-hosted WordPress 6.9 or later – With the REST API enabled (it’s on by default). You need version 6.9 or later for plugin abilities API which is allows you to use AI to manage plugins like AIOSEO, WPForms, etc.
A publicly accessible site – Your site must be reachable on the internet because local development sites won’t work unless exposed via a tunnel.
A free WPVibe account — You’ll create this during setup.
An HTTPS-enabled site — WordPress application passwords require SSL and they won’t function on http:// sites. See our guide on how to add SSL and HTTPS to WordPress.
Step 1. Set Up MCP on Your WordPress Website
The easiest way to add MCP to a self-hosted WordPress site is with WPVibe.ai. It’s free and runs on a hosted server, so there’s no infrastructure to configure. It also works with every major AI tool through a single setup.
You can read our full WPVibe review for a deeper look at everything it can do, but this guide covers what you need to get connected.
Other ways to set this up: There’s also an official WordPress MCP Adapter, which pairs with the new Abilities API in WordPress 6.9, but it’s built for developers and needs manual configuration.
Along with connecting your AI tools, the WPVibe plugin unlocks WP-CLI commands, theme file editing, and the plugin abilities that I talk about later in this guide.
Once activated, go to Vibe AI » Vibe AI in your WordPress dashboard. You’ll see the MCP server URL and a three-step setup guide.
Keep this tab open. You’ll need the URL in the next step.
Step 2. Connect Your AI Tools to WordPress
With WPVibe set up, connecting your AI tool takes under a minute. You add the same server URL to any AI client you use: https://mcp.wpvibe.ai/mcp.
You’ll find instructions on how to do this in the official WPVibe documentation. But let me show you exactly where to find that setting in some popular AI platforms.
Connecting Claude
If you’re just getting started, I recommend beginning with Claude.
The simplest method is to add the WPVibe URL once via Claude.ai on the web, and it syncs automatically to Claude Desktop, Claude Code, and the Claude mobile apps with no separate setup needed.
Note: On Team and Enterprise workspaces, only an Owner or Admin can add connectors. Individual members on those plans can authenticate with WPVibe once the admin has added it, or use the Claude Code method in step 3 below.
Free, Pro, and Max plans: In Claude.ai, go to Customize » Connectors. Click the + button, select ‘Add custom connector’, and paste https://mcp.wpvibe.ai/mcp.
Team and Enterprise (admin only): Go to Organization settings » Connectors. Click ‘Add’, select Custom » Web, and paste the WPVibe URL.
Claude Code (any plan): In your terminal, run claude mcp add --scope user wpvibe --transport http https://mcp.wpvibe.ai/mcp. Then, open Claude Code, type /mcp, select wpvibe, and choose ‘Authenticate’.
Once saved, follow the on-screen prompt to authorize your WordPress site.
Connecting ChatGPT
WPVibe is available directly in the ChatGPT App Marketplace, so both free and paid users can connect without copying server URLs or editing config files.
In ChatGPT, click ‘Apps’ in the sidebar and search for WPVibe. Then click ‘Connect’ on the app page and sign in with your WPVibe account when prompted.
After connecting, ChatGPT pre-fills ‘@WPVibe’ at the start of each message. You can delete it with backspace for prompts unrelated to WordPress. Leave it in place when following the authorization step below.
Connecting Cursor
Cursor adds MCP servers through a JSON config file. In Cursor, go to Settings » MCP and click the ‘Add new global MCP server’ button. This opens the mcp.json file.
WPVibe will appear in the MCP list once it connects.
Connecting Windsurf
In Windsurf, open the Cascade panel and click the ‘Plugins’ icon (puzzle piece). Search for WPVibe, click ‘Enable’, and complete the sign-in flow when prompted.
To configure manually instead, edit ~/.codeium/windsurf/mcp_config.json and add the following, then restart Windsurf:
Note: Windsurf uses serverUrl (not url) in its config file. Using the wrong key will cause the connection to fail.
Authorize Your WordPress Site
With the MCP URL added to your AI client, go back to Vibe AI » Vibe AI in your WordPress dashboard.
Under step 3, you’ll find a ready-to-copy prompt with your site’s URL already filled in.
Paste that prompt into your AI chat. Your AI assistant will call WPVibe and return a one-click authorization link. Simply click it to approve the connection.
You never see or copy a password. WordPress and WPVibe handle the credentials securely in the background.
What You Can Do Once You’re Connected (Worked Examples)
Once your AI tool is connected to WordPress, here are the first prompts I tried, including one for WooCommerce store owners.
My examples are from Claude Code terminal, but these will work with whichever AI tool you connected.
1. Write and Draft a Blog Post
Type this into your AI tool: ‘Create a draft WordPress post titled “How to Start a Blog” with an intro paragraph explaining why blogging is still worth it.’
Your AI assistant calls the WordPress REST API, saves the post as a draft, and returns a confirmation with a link to edit it in wp-admin.
Nothing goes live until you choose to publish it yourself.
2. Upload a Photo to Your Media Library
Type: ‘Upload this image to my WordPress media library: [paste a public image URL]. Set the alt text to “A person working at a laptop”.’
WPVibe validates the source URL, downloads the image, and adds it to your media library with the alt text you specified.
You can reference it in any post from there.
Note: The prompt above uses a public URL, which is the simplest approach. Uploading a local file from your computer works too, but WPVibe will generate a browser upload link as an intermediate step.
3. Manage Your WooCommerce Store
WooCommerce 10.9 ships with native MCP support, which exposes product and order abilities through the same standard that WPVibe uses.
If your site runs WooCommerce, try: ‘Draft a new product called “Summer T-Shirt” with a short description and a price of $29.95.’
The product saves as a draft in your store. Beyond creating products, your AI can also query orders, update their status, and add order notes, so you can handle routine store admin from the same chat window.
You can see the example below.
The next three examples go beyond WordPress’s built-in actions. On WordPress 6.9 or later, plugins can register their own actions (called ‘abilities’) that your AI discovers automatically, so if you use these tools, you can drive them from the same chat.
4. Optimize Your SEO with AI
If you use AIOSEO, then you can ask your AI to handle common SEO tasks from the chat window. It can check TruSEO scores, generate meta titles and descriptions, and run SEO audits.
My starting point was to ask it to find every post missing a meta description and write one for each.
Try this prompt: ‘Find all posts missing meta descriptions and write and apply them in one go.’
Your AI checks every post, writes the missing meta descriptions, and applies them through AIOSEO in one step.
If you use SeedProd, then your AI can manage your coming soon page, maintenance mode, and landing page settings without going into wp-admin.
For example: ‘Check if maintenance mode is currently active’ or ‘Enable the coming soon page.’
6. Build a Form with AI
If you use WPForms, then your AI can build forms from a plain-English description.
Try: ‘Create a contact form with name, email, and a message field.’ WPForms creates the form in your dashboard, ready to configure and embed.
Before using this, make sure you enable write access under WPForms » Tools.
WPForms Lite supports basic field types. Paid plans add phone, date/time, file upload, and more.
See What Your Site Can Do
You don’t have to guess which of your plugins support this. Because WPVibe automatically discovers every registered ability, you can just ask your connected AI: ‘What can you do on my WordPress site?’
It will list the abilities your installed plugins expose, so the answer stays accurate no matter which plugins you run.
Is WordPress MCP Safe?
I had the same concern when I first tested this. Here’s how WPVibe handles security.
WordPress manages the connection using application passwords, a built-in feature that creates a separate password for each external tool you connect. The AI only gets the permissions of the user account you connected.
So, it’s worth connecting with a limited, non-admin account rather than your main administrator login. If you create a dedicated Editor-role user for the connection, then the AI can only do what an Editor can do.
WPVibe encrypts your application password before storing it, using a separate key for each site, and keeps it on secure servers hosted by Cloudflare. Every connection between your AI client, WPVibe, and your WordPress site is encrypted too, so your credentials are never exposed along the way.
WPVibe also doesn’t store your conversation content. It stays within your AI client.
On the WordPress side, new posts always save as drafts and deletions go to the trash rather than permanent deletion.
To fully revoke access at any time, go to Users » Profile in your WordPress dashboard and scroll down to the Application Passwords section to delete it.
Troubleshooting Connection Issues
Connecting your AI client to WordPress is the step that trips people up most often.
If the connection fails or WPVibe doesn’t appear, then work through these checks:
WPVibe isn’t in your client’s tool or MCP list – Restart the AI client after saving the config. New MCP servers only load on a fresh start.
The connection fails silently in Windsurf – Windsurf uses the serverUrl key, not url. The wrong key produces no error message, so double-check it.
Application passwords won’t authenticate – Your site must run on HTTPS. Application passwords don’t work over http://.
Your AI client can’t reach the site – The site has to be publicly reachable. A local development site won’t connect unless you expose it through a tunnel.
Authorization keeps failing – Re-check that you pasted the correct MCP server URL: https://mcp.wpvibe.ai/mcp.
Frequently Asked Questions About WordPress MCP
Is WPVibe free?
Yes. WPVibe has no API key costs and everything in this guide works on the free plan. There is now a paid Pro plan (early-access pricing, $99 per year) that adds higher daily usage limits and priority support, not new features, so you don’t need it for anything covered here.
Does WordPress MCP work with all AI tools?
WPVibe works with Claude.ai (web), Claude Desktop, Claude Code, ChatGPT, Cursor, and Windsurf. Because MCP is an open protocol, any new AI tool that adopts the standard will work with the same WPVibe setup automatically.
Does WordPress MCP work with WordPress.com?
No, not through WPVibe. WordPress.com has its own built-in MCP setup that works differently. This guide covers self-hosted WordPress (WordPress.org) only.
Do I need WordPress 6.9 to use MCP?
No. You can create posts, upload media, and run admin tasks on WordPress 6.0 or later. WordPress 6.9 is only required if you want to use plugin abilities like those from All in One SEO or SeedProd.
Can I connect more than one WordPress site to WPVibe?
Yes. WPVibe supports multiple sites under one free account. Install the Vibe AI plugin on each additional site and complete the site authorization step. Your existing WPVibe account covers all your sites.
What happens if I disconnect WPVibe from my site?
You can remove a site from WPVibe in the plugin admin or on wpvibe.ai at any time. To fully revoke access, also delete the credential under Users » Profile » Application Passwords.
HTML and XML are markup languages based on plaintext files. This means that any given character could be part of a syntax form (a tag, a comment, a character reference, etc…) or it could be representing itself the way it reads in the file literally.
<tag>· Text node</tag>
Whenever a character might be ambiguous, both languages require explicit indication of the intent of the character. In HTML this occurs via escaping, while XML allows escaping or wrapping the content in a marked section, specifically a CDATA section.
<tag>
<![CDATA[<tag>· Text node</tag>]]>
These terms confuse me at times, especially since CDATA and CDATA sections are distinct forms of the same content, and it’s easy to conflate each term. This post is here to disambiguate the terms, their meanings, and why they exist.
One of the first jobs of a parser for any plaintext-oriented format is to determine if the next input character represents real text or is part of a syntax form that carries special meaning. If it’s a syntax form we would call it markup, but if the characters are part of real text meant for display or rendering or reading then we call it data.
Anything that is not syntax is data.
The interpretation of the next character depends on the region of the document in which it’s parsed. While the rules for syntax forms are complicated1, this post will focus on the data forms.
PCDATA — “parsed character data”
May form: tags, comments, sections, character references, literal text.
Characters in this region could be data or could form the start of a new markup element. It’s “parsed” because it needs parsing before determining what it represents.
The HTML specification renames this to Data, which is simpler and a bit harder to search for. In XML, however, it’s used in a document-type definition (DTD). When an element may contain content — text — its data model must include #PCDATA. Otherwise the only characters allowable within that element are other elements, comments, and whitespace. XML documents are required to be valid SGML documents, so its own specification adopts the terminology from SGML’s.
Those who have worked with DTDs might note that elements in XML may contain #PCDATA while attributes contain CDATA instead. First of all, the # is there only to make it explicit that PCDATA is referring to the reserved keyword, rather than a <pcdata> element. Secondly, there’s a good reason for this, which is that attributes can only contain text — they can’t contain other elements of markup. If an attribute value could contain a <span> element, for example, then the attribute value would need to be #PCDATA instead, but this is prevented by design.
PCDATA actually contains more than just literal text and elements. In addition to comments, processing instructions, and other node-like syntax, one important feature of PCDATA is the character reference. These make it possible to represent characters that would conflate with syntax (such as ‘<’ — <) or which might be cumbersome to enter on a keyboard (such as ‘§’ — §). When parsing, each character in these sequences neither creates an element nor displays as the text itself; rather, the entire sequence is parsed and translates into the character it refers to.
HTML pre-specifies a fixed set of named character references, but any Unicode code point may be referenced by its decimal or hexadecimal numeric index. While XML also allows referencing code points by their index2, it only pre-specifies the five named characters which correspond to its main markup introducers: <, >, &, ', and ". In XML, any additional named character references are created through the DTD by defining entities.
CDATA — “character data”
May form: [character references], literal text.
If a character isn’t markup, then it’s character data, which means that it’s representing its literal self or it’s part of a character reference. Once the parser has entered this region it will not create markup elements.
CDATA is the most confusable kind of character data; this is because there are many kinds of CDATA that share the same name:
XML attributes may contain CDATA, where character references are decoded.
XML CDATA sections only contain CDATA, but character references are not decoded.
HTML kind of has the same CDATA sections, but only in foreign elements (inlined SVG and MathML elements).
SGML elements may be declared to have a CDATA content model, in which case all content until the appropriate closing tag is to be parsed as character data, where character references are not decoded.
CDATA sections contain only literal text
Many people are familiar with CDATA sections, but it took me far longer to understand them than my intuition led on. They are the vestige of SGML “marked regions” which tell the parser to handle a specific range of bytes in a special way. The CDATA section is one of those, which tells the parser to completely turn off until it reaches ]]>.
<![CDATA[literal characters only in here]]>
It had other marked sections, however, which served different purposes.
<![IGNORE[everything in here is ignored; it doesn’t exist.]]>
<![INCLUDE[in here things <em>do</em> exist as normal.]]>
<![RCDATA[read on to learn about RCDATA!]]>
The IGNORE and INCLUDE sections may seem strange, since SGML already has comments, and INCLUDE effectively does nothing, but the sections can be marked by replaced entities, making for conditional inclusion which can be overwritten via command-line arguments when invoking the SGML parser.
<!ENTITY % review-only "IGNORE">
...
<![%review-only;[
<aside>
Add `-Dreview-only=INCLUDE` when building drafts.
This note won’t appear otherwise.
</aside>
]]>
XML only retained CDATA sections from SGML, while HTML never included them. They are useful because they are so easy to parse. All characters inside of them are to be treated as literal text, up until the first occurrence of the terminating ]]>. Unlike elements, the marked sections do not nest.
There are no CDATA sections in HTML
The Internet is full of discussions about the use of CDATA sections in HTML, but there are no such things, mostly. HTML itself is an amalgam of pure HTML and embedded SVG and MathML. Content inside of those embedded SVG and MathML elements is parsed differently, and within this “foreign content” there areCDATA section nodes.
When something which look like a CDATA section appears in an HTML document, it’s transformed into a “bogus” HTML comment and considered a snippet of malformed markup. To make things more confusing, the parsing rules differ inside an HTML document for these regions depending on whether they are found within HTML elements or foreign elements.
When a real CDATA section appears within SVG and MathML, it parses as in XML or SGML — everything is literal text until the nearest ]]>.
When a malformed CDATA look-alike appears in an HTML element, it gets special treatment — the parser only turns off until the nearest >. This means that these sections end even without a closing ]]>, and when they do, all of their contained content disappears from the page.
That small difference confuses naïve parsers and is a regular source of bugs.
<div><![CDATA[There are no tags in here.]]></div>
<svg><text><![CDATA[<none> here either.]]></text></svg>
<div><![CDATA[But there <em>are</em> tags in here]]></div>
the section ends here ╯ ╰ start of a real end tag
The following is the equivalent markup to the third line.
<div><!--But there <em-->are</em> tags in here]]></div>
SGML contains CDATA regions outside of marked CDATA sections
SGML made it possible to define more kinds of content than XML does for a given element. For example, an element in SGML can be declared to have a CDATA content model, in which case the element itself behaves like a CDATA section. All characters after the opening tag are treated as literal text until the parser finds the nearest appropriate end tag3. XML rejected this ability because it increases the complexity of the parser and requires that every document also contains a full DTD when parsing. For example, if an element were declared to have CDATA content, then a <at> b would represent that literal string; on the other hand, if it were declared like any other normal element, it would have three children: “a ”, the <at> opening tag, and “ b”.
<!ELEMENT verbatim - - CDATA>
...
<verbatim>
There are <no> tags in here, because this is CDATA,
but you wouldn’t know without reading the DTD,
overcomplicating the demands on the parser.
</verbatim>
These kinds of elements do exist in HTML, though a few were modified when HTML5 was standardized in 2008. Inside of the elements, the parser essentially turns off, which makes them easy to parse and can help avoid the need to extensively escape content. These elements are, of course, <script> and <style>4.
Were it not for the CDATA declared content model, every angle bracket and ampersand would have to be escaped in included JavaScript and CSS. In XHTML this was required, because it had no CDATA declared content model (since it was XML)5.
All text in XML is CDATA
Herein lies the most-confusing aspect of discussing CDATA — XML contains CDATA sections as well as CDATA as normal text. After parsing there is no distinction between <tag> and <![CDATA[<tag>]]> in the parsed content.
Many XML generators (or serializers) provide two mechanisms for creating text content: one wraps text in a CDATA section and leaves the text as it came (apart from avoiding including the terminating sequence); the other escapes syntax characters instead. While there are times where it would be appropriate to intentionally pick one over the other, a good library design would at least offer a third mechanism (if not only providing this third mechanism) which simply produces CDATA, itself determining when to wrap and when to escape6, and whether or not to produce chunks of wrapped text interspersed with chunks of escaped text.
The real difference between these two kinds of CDATA is purely presentational in the source document, as the XML snippet below only contains one text node, not two. Creating CDATA does not imply creating a CDATA section!
There’s one more confusing designation for characters in the HTML and XML input streams: RCDATA. RCDATA is almost identical to CDATA, except that in contexts where CDATA does not decode character references and entities, RCDATA will decode them into CDATA. This is confusing, because in the context of an XML attribute, the CDATA designation in a DTD automatically implies that character references are decoded, unlike the CDATA sections in content.
To this end there are no RCDATA attributes, since character references are always decoded inside attribute values. The RCDATA declaration is like the SGML CDATA content declaration: all characters following the opening tag for this element will be treated as text until the nearest matching closing tag (the difference being only that character references are recognized and decoded).
It’s worth remembering that XML rejected the CDATA content type because of how it complicates parsing, and it also rejected the RCDATA type. On the other hand, RCDATA was incorporated into HTML, but statically so. HTML has no configurable DTD, but in its specification two elements contain RCDATA content:
TITLE
TEXTAREA
While it’s easy to comprehend the way that <textarea> works, and that’s probably because we are used to entering text into one on a web page, the behavior of <title> is consistently confused in all manner of programming languages, platforms, and HTML-parsing code.
The TITLE element only contains character data — it cannot contain other markup. The parsing is among the easiest sections of an HTML document to parse: once the <title> opening tag is detected, the parser can capture everything until the nearest </title> closing tag. Everything it captured is literal text, after decoding character references.
<!-- the title is "<title>" -->
<title><title></title>
<!-- equivalent HTML -->
<title><title></title>
This complicates content management systems like WordPress which allow posts to have HTML in their post titles, because a page can show richly-formatted article titles which cannot be represented in the browser tab’s label, and care must be taken to extract the plaintext content from that HTML before display in those contexts.
Coda
HTML and XML both speak about different kinds of characters in their source documents and content models, which traces from the complicated ways that SGML documents could be constructed. SGML’s complexity almost always stems from the central idea that computers should do extra work to remove the hassle for humans to enter structured content in plaintext documents.
HTML, inspired by SGML, adopted some of the names and mechanisms for parsing those regions of text in distinct ways, but codified a single parsing standard independent of SGML. When XML was later developed, it was meant to form a simplified subset of SGML. This subset flipped the tradeoffs, leaning on humans performing extra work to remove the hassle for computers to parse structure in plaintext documents. For these text forms, this meant rejecting a few of the constructs while retaining others.
This is also another demonstration of how balanced tags are not enough to have well-behaved HTML with a naïve parser. A well-formed XML document may be parsed with a terse PERL script and regular expression, but HTML relies heavily on the context in which characters are found. Any HTML parser must know the special rules for each kind of element’s content model.
In summary
When it’s unclear whether a character forms text or markup, that is PCDATA. Once parsed, there is no PCDATA anymore; it’s either a form of DATA or MARKUP.
All text nodes in HTML are “DATA.”
“CDATA” just means “character data” and means that after parsing, the content is text. It does not indicate whether character references are to be decoded or not; that comes from the region in the document, based on its context.
All text nodes in XML are CDATA, but only after being parsed.
CDATA sections offer a convenient way to avoid escaping, but are indistinguishable from the equivalent escaped text.
HTML contains two special RCDATA elements which only and always contain a single text node child: <title> and <textarea>. Everything until the closing tag will be parsed as text, even if it looks like markup.
This post is already long and still over-simplifies the picture. SGML is a rich and robust specification and includes NDATA and SDATA, HTML includes a latchingPLAINTEXT parsing mode in which the rest of the entire document is parsed as literal character data, and there are other surprising goodies in how entities interact with the character mode.
Thanks for making it through to the end, or jumping directly here if you couldn’t wait.
As an example, each part of a tag — its name, attribute names, attribute values — carries its own parsing rules. The same is true for comments, DOCTYPE declarations, and every other syntax form. ︎
XML only allows character references to the characters in its “character set,” which is almost all Unicode code points, but excludes some control characters and U+FFFE and U+FFFF. ︎
Because SGML was designed to minimize the amount of necessary syntax, it’s not necessary to have a full end tag for an open element, but that’s a simple-enough model to understand the concept. ︎
The <style> element is straightforward, but the <script> element has its own complicated modification of the CDATA content model. It’s mostly CDATA, but makes it possible to escape the closing tag so that very old pages won’t break. HTML also applies this parsing mode for the <iframe>, <noembed>, <noframes>, and <noscript> elements (as well as for the deprecated <xmp> element), but these nominally should have no content inside of them (or shouldn’t be used); applying the CDATA content model prevents creating other elements as their children. ︎
Frustratingly, in XHTML one must escape JavaScript and CSS in the page to avoid parsing failure, while in HTML one must not. This alone makes for a complicated stage in any reliable HTML/XHTML converter. ︎
Wrapping a language like HTML inside a CDATA section is a convenient way to represent the HTML visually and retain the ability to easily modify it, but entities present a problem. The serializer must either pre-translate the entity into its resolved character content, losing the macro-like behavior and its name; or leave the entity in place, thus nullifying it because it will not be recognized as an entity on parse. However, in such a situation, a serializer is free to terminate the CDATA section, append the entity, and open a new one to continue. ︎
As mentioned in the discussion about CDATA, embedded SVG and MathML elements can contain CDATA sections, but these are not technically HTML elements. ︎
WordPress 7.0.1 is now available. As the first maintenance release of the 7.0 cycle, it’s strictly a bug-fix release: every included ticket addresses either a regression introduced during 7.0 development or an issue intentionally deferred at the end of the cycle.
The release ships fixes for 17 core Trac tickets and 14 Gutenberg PRs. Because this is a maintenance release, sites with automatic background updates enabled will update to 7.0.1 automatically — everyone else should update as soon as possible. Here’s what stands out for each audience.
Kudos to release lead Aaron Jorbin and his team for pushing this release over the finish line and getting it into hands of WordPress users quickly.
The most important fixes for end users
Registration page spam is shut down (#63085). The account registration page could be abused to send “Login details” spam emails from your site. This is arguably the most impactful fix in the release for anyone running a site with open registration — it protects both your users’ inboxes and your domain’s email reputation.
The 7.0 admin reskin gets its rough edges sanded off. WordPress 7.0’s refreshed admin design shipped with a handful of visual glitches that this release cleans up:
Form elements are now standardized in the mobile viewport (#64999)
The image editor’s scale and crop inputs no longer mismatch in size, and the info icon uses the new color scheme (#64937, #65428)
The publish settings panel no longer crowds its primary action buttons together (#65286)
The Media Library’s loading spinner is properly aligned in the modal filter toolbar, and the search bar no longer jumps position after a search (#65275, #65296)
A “black flash” that briefly appeared on wp-admin pages before the interface finished loading is gone (Gutenberg #78493)
Emoji behave correctly again. Two related fixes: the emoji detection script is once more printed in the admin (#65310), and certain characters are no longer incorrectly replaced by Twemoji images (#64318).
Accessibility improvements to the new revisions experience. The Visual History / Revisions feature introduced in 7.0 receives several accessibility fixes: focus now moves to the revisions slider when entering revisions mode, and changed blocks are marked with a CSS outline as a secondary, non-color indicator — important for users with low vision or color blindness (#65122, Gutenberg #77530, #78393, #79691).
The most important fixes for developers
wp_kses() no longer corrupts valid CSS (#65270). Since 7.0 RC4, wp_kses() could mangle legitimate background-image: url(…) declarations into a broken style=")" attribute. If your theme or plugin outputs inline background images through KSES-filtered content, 7.0.1 restores expected behavior — any workarounds you shipped can now be removed.
global-styles-inline-css can be dequeued again (#65336). Since 7.0, developers were unable to remove the global styles inline stylesheet. If your build pipeline or performance optimization strips this and re-serves it another way, that control is back.
PHP 8.5 compatibility fix in wp_get_attachment_image_src() (#64742). An incorrect array access triggered issues under PHP 8.5. If you’re testing sites on newer PHP versions, this removes one blocker.
A removed Navigation function returns as a deprecated shim (Gutenberg #78484).block_core_navigation_submenu_render_submenu_icon() was removed in 7.0, breaking themes and plugins that called it directly. It’s restored as a deprecated shim — but treat this as your migration notice, not a reprieve. Update any code that references it.
Editor state management fixes reduce false “unsaved changes” warnings. Two Gutenberg fixes matter here:
controlled/mode block changes are now marked non-persistent (#79350), and
related navigation entities are no longer dirtied during passive renders (#79000).
Together these should mean fewer spurious dirty states and a cleaner undo history — a quality-of-life improvement if you build with template parts and navigation blocks.
Block Visibility: “hide everywhere” keeps working after a block opts out of visibility support (#65389). If you register blocks that disable visibility support, previously hidden instances now stay hidden as expected.
How to update
You can update directly from Dashboard → Updates in your site’s admin, run wp core update with WP-CLI, or download WordPress 7.0.1 from WordPress.org and install it manually. Sites that support automatic background updates for minor releases will begin updating on their own shortly.
The full ticket list is available in the release candidate announcement, Trac report 4, and the 7.0.x editor tasks board on GitHub.
What’s next: WordPress 7.1
With 7.0.1 out the door, attention turns to the next major release: WordPress 7.1 is scheduled for August 19, 2026. To see what’s planned for the release, check out the Roadmap to 7.1 on the Make WordPress Core blog.
This minor release includes fixes for 31 bugs throughout Core and the Block Editor, addressing issues affecting multiple areas of WordPress including the block editor, admin ui, and media. For a full list of bug fixes, please refer to the release candidate announcement.
WordPress 7.0.1 is a short-cycle maintenance release. The next major version of WordPress will be 7.1; it is scheduled for release on 19 August 2026 at WordCamp US.
If you have sites that support automatic background updates, the update process will begin automatically.
WordPress 7.0.1 would not have been possible without the contributions of the following people. Their asynchronous coordination to deliver maintenance fixes into a stable release is a testament to the power and capability of the WordPress community.
To get involved in WordPress core development, head over to Trac, choose a ticket, and join the conversation in the #core channel. Need help? Check out the Core Contributor Handbook.
August 16-19, 2026 | Phoenix Convention Center, Phoenix, Arizona
The latest episode is 
︎