March 2026 was the busiest month for WordPress news in two years
March 2026 was the busiest month for WordPress news in two years. Between WordPress.com announcing AI agents that publish on a user’s behalf, the WordPress 7.0 release moving into its extended Release Candidate window, and the post-WordCamp Asia fallout about AI’s role in the ecosystem, there is a genuine amount worth digging into. Here is the signal separated from the noise, based on what I saw in client conversations throughout the month and what actually changed in the stacks I maintain.
1. WordPress.com AI agents: the story underneath the headline
TechCrunch framed the announcement as “AI writes your posts now,” and the social media cycle took it from there. The actual announcement is more nuanced and more interesting. WordPress.com now lets users grant scoped AI agents permission to draft, schedule, and publish content through the platform’s existing REST API, using OAuth-style delegated credentials. The agent runs remotely (Automattic is not doing inference in your browser) and the user approves or revokes the agent’s token like any other API key.
The important details most coverage missed:
- It is API-gated, not platform-wide. Self-hosted WordPress sites do not get this unless they install a plugin that exposes the same flow.
- Capabilities are explicit. An agent can be granted
publish_postsbut deniedmanage_options. The capability model is the existing WordPress one, just applied to non-human actors. - Logs are visible. Every agent-initiated action shows up in the site’s audit trail with the agent name, the action, and the timestamp. Nothing happens invisibly.
For site owners, this means the decision is not “do I want AI to write my posts?” but “do I want to delegate posting capability to external systems?” That has been the model for Zapier, Make, and IFTTT integrations for over a decade. The difference is that an LLM is on the other end of the API call instead of a human-scripted workflow. If you are already comfortable with Zapier pushing to WordPress, you already have the mental model for this.
What to do if you run client sites: audit existing Application Password usage and make sure your plugin stack logs REST API writes. The tools to review agent activity exist in WordPress core already, they are just underused. See the Application Passwords documentation for the capability model that applies here unchanged.
2. WordPress 7.0: Connectors API, Pattern Overrides, and MCP
The 7.0 Release Candidate window is unusually long. The core team extended it specifically because Connectors API testing revealed plugin compatibility issues that would have broken hundreds of integrations on release day. The delay is a good call, not a failure. Shipping 7.0 on time and breaking every plugin that uses the REST API would have been worse for the ecosystem than shipping it a month late with compatibility issues resolved.
Three features to know about in 7.0:
Connectors API. This is a first-class way for plugins to expose data to blocks, AI agents, and the editor. Think of it as a permissioned data provider abstraction. A plugin registers a “connector” (for example, “CRM contacts” or “product catalog”) and blocks or the editor can pull from it with a consistent interface. If you maintain a plugin that exposes custom data, you will want to ship Connectors support in your first 7.0-compatible release.
Pattern Overrides. Lets you mark parts of a pattern as editable per-instance while locking the surrounding structure. This is the feature WordPress agencies have been asking for since patterns first landed in 6.0. It means you can ship a header pattern with a locked layout and an editable tagline, and every page built from the pattern gets consistent structure with per-page copy. The feature is quietly one of the biggest productivity wins for agencies building design systems on WordPress.
MCP server support. The Model Context Protocol lands in core as an optional server mode for integrating WordPress with LLM toolchains. This is what makes agent-driven workflows practical from the self-hosted side. The self-hosted story was the missing piece in Automattic’s WordPress.com AI announcement, and MCP in core closes the gap.
If you maintain a plugin, spin up a 7.0 RC environment now rather than waiting for the final release. The compatibility issues being found in RC testing cluster around plugins that deeply hook into the block editor or the REST API, which are exactly the plugins most likely to need a fix. My guide to the next-gen plugin build tool covers the tooling changes that land alongside 7.0 and are worth preparing for simultaneously.
3. WordCamp Asia 2026: the AI conversation nobody was ready for
From hallway conversations to session Q&A, roughly 90 percent of every substantive conversation at WordCamp Asia was about AI. Not hype. Anxiety. Agency owners were worried about margin compression. Freelancers were worried about project scope being eaten by AI-generated output. Core contributors were worried about review process contamination when contributed patches are partially AI-authored.
Three unresolved tensions came out of the event, and they are going to shape WordPress community policy over the next year:
- Who reviews AI-authored core patches? Core contribution guidelines have not been updated for 2025-2026’s reality that many patches start as AI drafts. The review process assumes human authorship, but the author field no longer reliably indicates who wrote the code.
- What happens to boutique-agency pricing? Agencies whose margin came from “we configure WordPress faster than a freelancer” are watching that moat erode. Configuration speed is no longer a competitive advantage when a client can prompt an AI tool directly.
- Does the community need an AI-disclosure norm for contributions? No consensus, but the conversation is active. Expect a Make/WordPress post in April or May laying out a formal position.
4. Plugin ecosystem: quiet consolidation
Two plugin acquisitions in March did not get front-page coverage but matter for the ecosystem:
- A large hosting provider acquired a mid-tier page-builder plugin. History says the plugin now prioritizes its new parent’s hosting, so if your stack depends on it, treat it as a vendor lock-in risk and have a migration plan ready.
- A SaaS form handler consolidated two mid-size WordPress form plugins under one brand. Pricing tiers have already changed. Audit your renewals in April to make sure you are not over-paying for features that used to be in a cheaper tier.
Also quietly, several popular community plugins transitioned to a dual-license model, which keeps the plugin GPL but moves the addons behind a commercial license. Read your plugin update notices carefully. Some updates now require a paid license for features that were previously free.
5. Core releases and security
WordPress 6.7.2 shipped a security fix for a low-severity XSS vulnerability in the block directory browser. Nothing was exploited in the wild as of the announcement. Auto-updates handle it if you have them enabled, and you should have them enabled. If you do not, this is the moment to enable them.
The Gutenberg plugin reached version 21.4 with incremental improvements to the Interactivity API, the block inserter, and pattern search. If you use the Gutenberg plugin on production (a risky choice but occasionally necessary), hold at 21.2 until 7.0 ships. The in-flight work between 21.3 and 21.5 is where most regressions have historically landed.
What I am watching in April
Three stories to track over the next 30 days:
- WordPress 7.0 release date confirmation. The current target is late April, but “when it is ready” always wins. Watch the release schedule post on make.wordpress.org for the official date.
- Automattic’s response to self-hosted parity. If agent support only lives on WordPress.com, that is a meaningful competitive moat, and one the self-hosted community will push back on. Expect a blog post or plugin release in April.
- Plugin compatibility reports. The Plugin Check plugin now flags 7.0 compatibility issues automatically. Expect a surge of compatibility updates as reports land over the next few weeks.
If you run client sites, the April work is getting ready for 7.0 without waiting for it. Review your plugin stack, run 7.0 RC on a staging site, and document which plugins need compatibility updates. The teams that do this work in April will have a smooth 7.0 launch day. The teams that skip it will spend the first week of May firefighting.
The bottom line
March 2026 was the month where the abstract “AI will change WordPress” conversation became concrete. Agents are here. Capability delegation is the new model. The plugins you depend on are being repositioned around it. The teams that will do well are the ones treating this as an API and permissions problem, because that is what it actually is, not as a philosophical one about whether AI belongs in WordPress at all. The philosophy is already settled. The implementation is what is left to figure out.
For how I am actually running AI alongside WordPress development on client work, see my guide to AI code review for WordPress plugins, which covers the concrete prompt patterns and CI integration I use every week.
AI in WordPress api-first architecture CMS Comparison
Last modified: April 14, 2026
