WordPress’s Troubled Real-Time Collaboration Feature via @sejournal, @martinibuster

WordPress delayed the release of the highly anticipated version 7.0 of the CMS because the real-time collaboration (RTC) feature was not yet stable. The delay has caused some to question whether the feature is necessary in the core, while others say that the delay is a symptom of deeper issues within WordPress itself.

Real-Time Collaboration (RTC)

The Gutenberg project has been on a four-phase development track: Gutenberg block editor (phase 1), Full Site Editing (phase 2), Collaboration (phase 3), and multilingual capabilities within core (phase 4).

WordPress 7.0, initially due to be released on April 9, was supposed to be the rollout of phase 3, as well as other important features that make it easier to use AI within WordPress.

RTC enables multiple users to simultaneously edit content and block-based design within the block editor, a functionality that will be useful to publishers and agencies.

RTC Has Been Tested

The commercial side of WordPress, Automattic’s WordPress.com, has made RTC available to beta testers since October 2025. These beta testers are enterprise-level customers of WordPress VIP. WordPress’s documentation states that RTC works best with native WordPress blocks and implies that the feature could be buggy with blocks that don’t strictly abide by best practices.

A post on the official WordPress.org site provides this information about RTC performance:

“The most consistent feedback: real-time collaboration works seamlessly when sites are built for modern WordPress. Organizations using the block editor with native WordPress blocks and custom blocks developed using best practices reported smooth experiences with minimal issues.

One technical lead at a major research institution noted their team has invested in a deep understanding of Gutenberg and, as a result, “…have not run into any issues.”

…Multiple teams tested the limits by:

Adding dozens of blocks simultaneously.

Copying large amounts of existing content in parallel.

Having entire teams edit the same post together (one team specifically noted “this is so fun”).

In these stress tests with native blocks and modern custom blocks, real-time collaboration held up remarkably well.”

Those tests were with a version that reused existing tables to store the editing events. That method resulted in multiple bugs, leading to a delay after it was decided to create a dedicated table for the RTC feature in the database used by WordPress sites in order to improve stability.

The beta-tested version of RTC had to limit the number of users who could simultaneously edit together.

A GitHub issue ticket explains what’s wrong with the old version of RTC:

“It is known to be limited on a performance and scaling basis, but provides an easy way to see collaboration working.

By limiting the provider to a set low number of collaborators by default, the chance of overloading is reduced.”

So that’s one of the issues being solved by introducing a new database table. Once that is done, the RTC feature will need to be tested, and this is the area that WordPress web hosts will be concerned about.

Symptom Of Deeper Issues?

Joost de Valk, founder of Yoast SEO, recently published a blog post that made the case that WordPress is in need of rewriting existing code to make it more secure, modern, and efficient. He called attention to the troubled state of real-time collaboration as a symptom of the problems with the core itself.

He wrote:

“The recent deferral of WordPress 7.0 illustrates the problem in real time. The release was delayed because the team needs to revisit how real-time collaboration data is stored — the initial approach of stuffing it into postmeta wasn’t going to hold up. They’re now considering a custom table. This is exactly the pattern: a new feature runs into the limits of the existing data model, and the team has to work around it or pause to rethink.”

That’s one person’s opinion, and not everyone shares it. A lively discussion on the Post Status Slack channel showed that some in the WordPress community strongly disagreed that WordPress needs to be refactored.

Impact To WordPress Hosts

A concern I have heard privately is that RTC could have a negative impact on shared hosting providers. But it’s hard to know because the RTC feature is still evolving from what was tested on WordPress.com, which is supposed to make it more stable.

Shared hosting environments will have to make a decision as to how to accommodate this feature.

• How will the hosting environment be affected by thousands of RTC customers editing all at once?
• Will they need to limit how many users can edit within the block editor?
• Will they have to place an upper limit of simultaneous editors for one tier of customers and a higher limit for other customers?

Should RTC Be A Plugin?

WordPress professional Matt Cromwell (LinkedIn profile) recently published an opinion piece that called attention to whether RTC should even be in the WordPress core and should instead be developed as a plugin. His reasoning is based on WordPress’s core philosophy that any new feature introduced into the core should be something that the majority of WordPress users will need.

The reason for that design philosophy is to make WordPress usable for the majority of users and not ship with features that most will not use. This keeps WordPress lean. His article quotes the official WordPress design philosophy:

“Design for the majority
Many end users of WordPress are non-technically minded. They don’t know what AJAX is, nor do they care about which version of PHP they are using. The average WordPress user simply wants to be able to write without problems or interruption. These are the users that we design the software for as they are ultimately the ones who are going to spend the most time using it for what it was built for.”

Cromwell writes:

“If a feature isn’t needed by the vast majority, it belongs in a plugin. It is the reason WordPress remains lean enough to power 43% of the web.

Real-time collaboration fails this test spectacularly.”

Although Cromwell insists that this feature wouldn’t be used by the majority, an argument could be made that this is a feature that people want. For example, the Atarim collaboration plugin, with the free version currently installed on over 1,000 websites, states that the plugin has been used on over 120,000 websites by agencies and freelancers.

It could be that RTC is indeed an important feature, especially to designers, agencies, and editorial teams working together on articles.

AI In WordPress

The four-stage WordPress roadmap was created six years ago in 2018, and there was no way to know then how important AI would be today. Yet arguably it’s AI, not collaboration, that’s the most anticipated integration for WordPress 7.0. Nevertheless, real-time collaboration will very likely land in WordPress 7.0, enabling freelancers and agencies to work together with clients as well as with internal teams spread out across countries. That seems like a valid reason to ship a stable feature within core as opposed to within a plugin.

Featured Image by Shutterstock/Summit Art Creations

Mullenweg To Cloudflare: Keep WordPress Out Of Your Mouth via @sejournal, @martinibuster

WordPress co-founder Matt Mullenweg responded to Cloudflare’s announcement of EmDash as the spiritual successor to WordPress by invoking Will Smith’s Oscars slap. Cloudflare’s CEO responded by doing exactly what Mullenweg told him not to do.

Spiritual Successor To WordPress

Mullenweg’s first criticism of the new EmDash was the claim that it was the spiritual successor to WordPress. He made the point that WordPress can be installed and used on virtually any device and on any platform, saying that this was a part of their mission to democratize publishing by making it easy to deploy on almost any kind of infrastructure.

Although he didn’t say it out loud, the implication is clear: WordPress can be deployed everywhere, and EmDash is not as flexible.

Matt aimed his next comment straight at Cloudflare:

“You can come after our users, but please don’t claim to be our spiritual successor without understanding our spirit.”

The Compliment Sandwich

Back in the early 2000s, Googlers were famous for their friendliness and smiles. I don’t think it was a calculated thing; the smiles were not a persona; it was genuine. I believe that many of the Googlers who had interactions with the SEO community were genuinely friendly and truly wanted to help people with their SEO issues. When I lived in San Francisco, I had many visits at Google and had nothing but positive experiences.

Matt affects that same kind of persona where he speaks with a smile. But he also does it while being critical of things, which is a kind of dissonant thing to witness. His response to Cloudflare is the written equivalent of that approach.

It follows compliment sandwich pattern:

• Positive statement
• Criticism or negative point
• Another positive statement

Done correctly, with tact and genuine empathy, it can soften criticism. It’s a valid approach to providing critical but helpful feedback.

Matt accused Cloudflare of using EmDash as a way to promote their infrastructure, but he did it with a smile.

He criticized:

“I think EmDash was created to sell more Cloudflare services.”

Then he switched over to the positive statement:

“And that’s okay! It can kinda run on Netlify or Vercel, but good stuff works best on Cloudflare. This is where I’m going to stop and say, I really like Cloudflare! I think they’re one of the top engineering organizations on the planet; they run incredible infrastructure, and their public stock is one of the few I own. And I love that this is open source! That’s more important than anything. I will never belittle a fellow open source CMS; I only hate the proprietary ones.”

Then he criticized Cloudflare again:

“If you want to adopt a CMS that will work seamlessly with Cloudflare and make it hard for you to ever switch vendors, EmDash is an incredible choice.”

That last part is a backhanded and sarcastic compliment, implying that EmDash is a way to trap users within Cloudflare’s infrastructure. Mullenweg offered a bullet-point list of additional criticism mixed with compliments.

Keep WordPress Out Of Your Mouth

Mullenweg ended his blog post with a conciliatory-sounding paragraph that ends abruptly with a phrase that invoked Will Smith’s Oscars slap:

“Some day, there may be a spiritual successor to WordPress that is even more open. When that happens, I hope we learn from it and grow together. Until then, please keep the WordPress name out of your mouth.”

Mullenweg is doing something between the lines there. Whether he did it intentionally or not, he’s invoking Will Smith’s infamous moment at the Oscars, when he slapped Chris Rock across the face and told him to keep his wife’s name out of his mouth. That phrase subtly invokes a violent image, with Mullenweg playing the role of Will Smith slapping Cloudflare across the face.

By using that specific phrase, Matt Mullenweg was, intentionally or not, invoking the conflict by comparing Cloudflare’s use of the “WordPress” name to an insulting personal attack.

Understated Irony

After being told to keep WordPress out his mouth, Cloudflare co-founder and CEO Matthew Prince responded on X by saying it’s a fair criticism and then immediately putting WordPress in his mouth. Prince tweeted:

“Think this is a fair critique from @photomatt of EmDash.

I remain hopeful it’ll bring a broader set of developers into the WordPress ecosystem.”

What Prince did there was politely defy Mullenweg by tweeting the word “WordPress” in his response after being told to keep it out of his mouth while simultaneously adopting the persona of someone trying to “help” the person who just slapped him. In the context of the Oscar reference, it’s as if Chris Rock had responded to the slap by calmly saying, “I hope this incident brings more viewers to your next movie.”

Was that meant as understated irony? If so, it’s a master class.

Featured Image by Shutterstock/Prostock-studio

6 Reasons Why Cloudflare’s EmDash Can’t Compete With WordPress via @sejournal, @martinibuster

Cloudflare announced a new content management system called EmDash that it says is the “spiritual successor to WordPress.” Could EmDash be your next content management system? Here are six reasons why EmDash may be the content management system of tomorrow… but not today.

1. EmDash Is Not User Focused

Cloudflare’s biggest selling point for its new CMS, as stated in the title of the announcement, is that it solves the WordPress security problem. Over 25% of the announcement focuses on discussing plugin security.

The remaining 73% of the announcement is dedicated to:

• Background information about the evolution of web development.
• Putting WordPress within the context of the history of web development.
• The technical architecture.
• Security and authentication.
• Readiness for the x402 standard, which enables users to monetize agentic website traffic.

There are over 2,700 words in that announcement, and the only part that arguably has direct importance to actual users like bloggers, businesses, and other publishers is the part about plugin security. The rest of the content is developer- and coder-focused and not user-focused at all.

There are many reasons to choose a CMS, and while security is important to businesses and online publishers, there are other reasons that are far more important.

2. The Case For Plugin Security

Cloudflare explains that WordPress plugin security is compromised because plugins are granted full access to a website’s internal files and database. This lack of boundaries means that if a single plugin has a flaw or malicious intent, it can compromise the entire site. The announcement explains that the vast majority of security vulnerabilities (96%) originate from third-party plugins.

What the announcement doesn’t say is that the vast majority of WordPress plugin vulnerabilities are not likely to be exploitable at scale. Only 17% of plugins are high severity, and of those, many of them are not installed on many websites.

Research from Patchstack WordPress security shows that in 2025:

“1,966 (17%) vulnerabilities had a high severity score, meaning they were likely to be exploited in automated mass-scale attacks.

…Furthermore, our Zero Day program found 33 highly critical vulnerabilities in Premium components, compared to only 12 in free components.”

There are many WordPress vulnerabilities discovered every day, but most of them are low risk and are found on plugins that are not widely used. If plugin security is EmDash’s main selling point, it’s not much of a selling point in the real world.

Cloudflare’s solution for improving plugin security is solid and well designed. However, a reasonable argument could be made that Cloudflare’s case for plugin security is overstating its importance in the overall scheme of what users actually need.

3. EmDash Is Built To Solve Infrastructure Problems

In a post on X, Jamie Marsland of Automattic acknowledged that EmDash offers innovative solutions but argues that its focus is on solving infrastructure issues and is not focused on the daily problems that an actual CMS user (like a restaurant owner or a recipe blogger) would be interested in.

Marsland makes the point that developers may care about “cleaner abstractions” and “isolate runtimes,” but small business owners care about things like bookings, SEO, and customer acquisition. He uses the analogy of EmDash being a “tidy desk” for people who aren’t actually looking to tidy their desks but rather are focused on using a CMS that helps them run a business.

Marsland explained:

“…when very smart people rebuild something from scratch, they tend to fix the problems they can see most clearly.
And the problems Cloudflare sees are very real:

• Plugin security (sandboxing, isolation)
• Serverless scaling
• Modern developer experience
• AI-native programmability

All of which make perfect sense… If you are looking at the world from inside an infrastructure company.

…If you are a developer, this feels like someone has finally tidied your desk. The problem is that most people are not trying to tidy their desk.

They are trying to run a business from it while:

• replying to emails
• posting on social
• updating their website
• wondering why traffic dropped”

4. EmDash May Not Be User Friendly

EmDash is built on Astro, which technically is not a CMS; it’s a web framework. EmDash wraps Astro around a graphical user interface (GUI) for content management that may feel familiar to anyone who has used WordPress. But setting it all up is not as easy as WordPress’s famous five minute setup because it can involve connecting to a GitHub repository and configuring database settings. The same is true for getting the site to look how a user wants it to look.

It has a GUI for managing content, but it does not (yet) have a point-and-click website builder the way most modern content management systems like WordPress and Wix do.

5. Command Line Interface

I’m old enough to remember what using a desktop computer in 1980 was like. The interface was essentially a command line interface, with a cursor impatiently blinking at the user, waiting for cryptic commands to make it do something. It was not until 1983 that Apple introduced a graphical user interface (GUI) that made interacting with a computer easy for everyday users.

If you like typing cryptic commands to make a computer function, then EmDash’s command line interface is for you. At this point, users won’t be able to get away from it because users currently cannot set up an EmDash site from scratch without resorting to a CLI. Even the “one-click” deployment options in the Cloudflare Dashboard eventually require technical configuration that is usually handled via the terminal.

6. EmDash Is Not Ready For Most Users

I was quite excited to read Cloudflare’s announcement about a “spiritual successor” to WordPress, but the more I read, the more it became apparent that EmDash is not the solution I am looking for. Yes, I want a fast-performing website. Yes, I want a site that is secure and won’t surprise me one day with Japanese text.

But I don’t want to deal with a CLI, and I do want an easy-to-use interface for setting up and building an attractive website for myself. EmDash is not ready for general use. It’s still in early developer beta. The version number on it is 0.1.0, so at this point it’s literally not for the average user.

Hopefully, some day it will be a viable competitor to WordPress, but EmDash is not that right now.

Featured Image by Shutterstock/Ollyy

WordPress Delays Release Of Version 7.0 To Focus On Stability via @sejournal, @martinibuster

WordPress 7.0, previously scheduled for an April 9th release, will be delayed in order to stabilize the Real-Time Collaboration feature and assure that the release, a major milestone, will “target extreme stability.” Much is riding on WordPress 7.0 as it will ship with features that will usher in the age of AI-driven content management systems.

Prioritization Of Stability

Matt Mullenweg, co-founder of WordPress, commenting in the official Making WordPress Slack workspace, said the release should step back from its current trajectory and prioritize stability, calling for a longer pre-release phase to get the real-time collaboration (RTC) feature working correctly. The delay is expected to last weeks, not days, and is described as a one-off deviation from WordPress’s planned date-driven schedule.

Mullenweg posted:

“Given the scope and status of 7.0, I think we should go back to beta releases, get the new tables right, lock in everything we want for 7.0, and then start RCs again. Date-driven is still our default, but for this milestone release we want to target extreme stability and exciting updates, especially as AI-accelerated development is increasing people’s expectations for software.

This is a one-off, I think for future we should get back on the scheduled train, with an aim for 4-a-year in 2027, to hopefully reflect our AI-enabled ability to move faster.”

Extended Release Candidate Phase Replaces Beta Reversion

To avoid technical compatibility issues, the project will remain in the release candidate phase, extending the testing period through additional RC builds as needed.

The proposal to return to beta releases was rejected because it would break PHP version comparison behavior, plugin update logic, and tooling that depends on standard version sequencing. Continuing with RC builds preserves compatibility while allowing more time for testing and fixes.

Real-Time Collaboration

The delay is largely due to the Real-Time Collaboration feature, which introduces new database tables and changes how WordPress handles editing sessions. Contributors identified risks related to performance, data handling, and interactions with existing systems.

A primary concern is that real-time editing currently disables persistent post caches during active sessions, a performance issue the team is working to resolve before the final release.

Database Design Raises Performance Concerns

A key part of the discussion focused on how to structure the database for Real-Time Collaboration (RTC).  A proposed single RTC table would support 1. real-time editing updates and 2. synchronization. But some contributors noted that the workloads for real-time editing and synchronization are fundamentally different.

Real-time collaboration generates high-frequency, bursty writes that require low latency (meaning updates happen with very little delay).

While synchronization between environments involves slower, structured updates that may include full-table scans.

Combining both patterns within one table risks performance issues and added complexity. Contributors discussed separating these workloads into separate tables optimized for each use case, but no decision has been made.

Gap In Release Candidate Testing Raises Concern

The discussion in the WordPress Slack workspace also raised concern over whether there was enough real-world release candidate testing, and database schema changes increase the risk of failures during upgrades. The solution of using the Gutenberg plugin for testing was rejected because database changes could affect production sites and require complex migration logic. Instead, the project will use an extended RC phase to increase testing exposure and gather feedback from a wider group of users.

Versioning Constraints

The proposal to delay version 7.0 led to additional issues. PHP version comparison rules and related tooling complicated returning to beta versions. It was agreed that staying within the release candidate sequence (ergo RC1, RC2, RC3) avoids these issues while allowing continued iteration, so it was decided to continue with release candidates.

Future Release Cadence Remains

The delay is described as a temporary exception. Matt Mullenweg said the project intends to return to a regular release schedule, with a goal of delivering roughly four releases per year by 2027 as development speeds increase with AI-assisted workflows.

Implications For Developers And Users

Developers should expect continued changes to the Real-Time Collaboration feature and its supporting database structures during the extended release candidate phase. The longer testing period provides more time to identify issues before release. For site owners and hosts, the delay shows that WordPress is prioritizing stability over schedule while introducing more complex real-time and synchronization features.

Impact Of RTC On Hosting Environments

Something that wasn’t discussed but is a real issue is how real-time collaboration might affect web hosting providers. They need to test that feature to see if it introduces issues on shared hosting environments. While RTC will be shipping with the feature turned off by default, the impact of it being used by customers in a shared hosting environment is currently unknown. A spokesperson for managed WordPress hosting provider Kinsta told Search Engine Journal they are still testing. Given how the feature is still evolving, Kinsta and other web hosts will have to continue testing the upcoming WordPress release candidates.

I think most people will agree that the decision to delay the release of WordPress 7.0 is the right call.

Is WordPress Too Complex For Most Sites? via @sejournal, @martinibuster

Joost de Valk, the co-founder of the Yoast SEO plugin, provoked a discussion and some controversy with a recent blog post that posited that the concept of needing a content management system (CMS) to publish a website is increasingly outdated. This insight came to him after migrating his site to a static Astro-based website with the help of AI.

Joost wrote that the reality today is that many businesses and individuals need nothing more complicated than a static website and that a CMS is overkill for those simple needs.

He affirmed that CMSs are vital for building complex websites, but he also makes the case that the complexity problem that a CMS solves is not representative of the needs of most websites:

“Let me be clear: there are real use cases where a CMS earns its complexity. …These aren’t edge cases. They represent a lot of websites.

But they don’t represent most websites. Most websites are a handful of pages and maybe a blog.”

His article shares eight key observations:

1. Creating a website was never exclusively a conversation about a CMS
2. Yet CMS options are more widespread than ever website options
3. Growing trend right now is away from CMS
4. Joost de Valk joined the trend away from a CMS to Astro.
5. Static HTML websites are as SEO-friendly as CMS-based websites.
6. Simplicity outperforms complexity for many needs.
7. Content Management Systems remain the best choice for complex requirements.
8. The case for a CMS will become less relevant once users are able to chat with an AI in order to publish content.

Joost explained that last point:

“I built this entire Astro site with AI assistance. The next step, editing content through conversation, is not a big leap. It’s a small one.

…When editing a static site becomes as easy as sending a message, the CMS’s core advantage for the majority of websites disappears.”

For some, it might be difficult to imagine publishing a website without a CMS, and others believe that WordPress SEO plugins provide an advantage over other platforms. But for those of us who have been in SEO for a long time, we know from experience that static HTML sites are generally faster than any CMS-based website.

Before WordPress existed and became viable, I used to spin up static HTML sites from components I hand coded, including PHP-based websites. Those sites ranked exceptionally well and easily handled DDoS-level traffic. Although I didn’t have to deal with Schema structured data because it hadn’t been invented yet, automating title tags and meta descriptions across a website was a relatively trivial thing to do. No plugins are necessary to SEO a static HTML website, and this is one of the insights that de Valk discovered after transitioning his blog away from WordPress.

He shared:

“I built Yoast SEO, so you’d think this is where a static site falls short. It doesn’t. Everything Yoast SEO does on WordPress, I can do in Astro. XML sitemaps, meta tags, canonical URLs, Open Graph tags, structured data with full JSON-LD schema graphs, auto-generated social share images: it’s all there. In fact, it’s easier to get right on a static site because you control the entire HTML output. There’s no theme or plugin conflict messing with your head tags. No render-blocking resources injected by something you forgot you installed. What you build is what gets served.

The SEO features that a CMS plugin provides aren’t magic. They’re HTML output. And any modern static site generator can produce that same HTML, often cleaner.”

It’s true, the web pages Joost’s blog serves today are a fraction of the size of what they were when published using WordPress. One URL on de Valk’s website that I checked (/healthy-doubt) went from over 1,400 lines of code to only 180 lines of code. Furthermore, something de Valk didn’t mention is that the Astro-based HTML rendered with only eight minor HTML validation issues. WordPress sites tend to render with scores and even hundreds of invalid HTML issues.

Although Google can crawl and index the code that underlies the average WordPress website, invalid HTML nevertheless runs counter to the most fundamental goal of SEO: to make it easy for search engines to crawl, parse, and understand the content.

Article Provoked Controversy

Many developers responded against Joost’s article but many others agreed with him.

Dipak Gajjar (@dipakcgajjar) tweeted:

“A properly configured WordPress site with object cache and a CDN in front is already near-static in terms of delivery. You just get the CMS on top for free.

Good luck @jdevalk convincing a non-technical client to push markdown files to Git just to publish a blog post. WordPress exists because content management is a real problem. Static tools solve the developer experience, not the client experience.”

@cameronjonesweb asked:

“Hands up who thinks it’s a great idea to make their clients update their website content by committing markdown files to GitHub…”

@andrewhoyer pushed back on Joost’s article:

“Blogs would never have become popular without software. Only a tiny fraction of people can edit HTML and CSS by hand. Just because a few of us can doesn’t make static sites a good option.”

But it wasn’t all verbal tomatoes getting thrown at Joost, there were some roses tossed his way, too.

Alex Schneider (@Aslex) agreed that AI is lowering the barrier to creating and maintaining static websites.

Schneider tweeted:

“Static sites aren’t just for people who know HTML anymore. AI tools already let anyone generate and publish content to static sites with zero coding. And let’s be honest, traditional blogs are dying anyway.”

@LusciousPotate shared their opinion that WordPress is outdated:

“Constant WordPress updates, constant plug-in updates, constant security issues. It’s old, the tech stack is outdated; it needs to be put out to pasture.”

Is WordPress Still Relevant?

Generating a static site with Astro still requires some technical knowledge, and at this point in time it’s nowhere near as easy as using WordPress to get online. Many hosting platforms simplify the process of creating websites with WordPress, including with the use of AI. WordPress 7.0 looks to be the start of the most profound changes to WordPress, quite likely making it even easier for anyone to publish a website.

So yes, a strong case can be made for the continued relevance of content management systems, especially WordPress. Yet it may be that static website generator platforms may become a thing in the near future.

Read the de Valk’s blog post here: Do you need a CMS?

Featured Image by Shutterstock/TierneyMJ

Vibe Coding Plugins? Validate With Official WordPress Plugin Checker via @sejournal, @martinibuster

Vibe coding WordPress plugins with AI can raise concerns about whether a plugin follows best practices for compatibility and security. WordPress.org’s Plugin Check Plugin offers a solution for those who wish to check whether a plugin conforms to the official standards. The latest version can now connect to AI.

The plugin is developed by WordPress.org, and it’s meant as a tool for plugin authors to test their own plugins with similar kinds of tests used by the official WordPress plugin repository, which can also help speed up the process of getting accepted into the repository.

According to the official plugin description:

“Plugin Check is a tool for testing whether your plugin meets the required standards for the WordPress.org plugin directory. With this plugin you will be able to run most of the checks used for new submissions, and check if your plugin meets the requirements.

Additionally, the tool flags violations or concerns around plugin development best practices, from basic requirements like correct usage of internationalization functions to accessibility, performance, and security best practices.”

The Plugin Check Plugin also has a Plug Namer feature that will check if a plugin’s name is similar to another plugin, if it may violate a trademark, complies with WordPress naming guidelines, and if the plugin name is too generic or broad.

The latest version of the plugin is version 1.9.0 and it adds the following new features:

• Supports the new WordPress 7.0 AI connectors so that the plugin can work with the WordPress AI infrastructure
• Updated block compatibility check for WordPress 7.0.
• Checks for external URLs in top-level admin menus to avoid admin issues.
• This latest version also contains additional tweaks, enhancements, and improvements.

User reviews share positive experiences:

“This plugin helped me identify areas of my plugin that I thought I had taken care of. When developing my first plugin. I learned a lot through the feedback given and was able to re-run and eventually remove of all errors.”

“Useful tool for catching issues early. If you’re serious about plugin development, this is a must-have.”

Download the official WordPress Plugin Checker Tool here:

Plugin Check (PCP) By WordPress.org

WooCommerce May Gain Sidekick-Type AI Through Extensions via @sejournal, @martinibuster

WooCommerce is approaching a turning point in 2026 thanks to the Model Context Protocol and the convergence of open source technologies that enable it to function as a layer any AI system can plug into, helping store owners and consumers accomplish more with less friction. Automattic’s Director Of Engineering AI, James LePage, discussed what’s possible right now, what’s coming in the near future, and why the current limitations are temporary.

WooCommerce

Because WooCommerce is built on WordPress and is highly extensible through plugins, APIs, and now MCP, it is rapidly evolving into a coordination layer where AI-based systems can plug in and work together through it. Automattic’s James LePage describes this approach as one in which WooCommerce fits perfectly in the center.

Model Context Protocol

Model Context Protocol is an open standard that enables platforms like WooCommerce to connect their capabilities to AI systems, making AI-powered features possible.

While MCP sounds like an API, which enables software systems to communicate, the key difference is that an API handles predefined requests, whereas MCP enables platforms like WooCommerce to support a broader range of AI interactions without building custom integrations for each one.

WooCommerce Sits In The Middle

ACP (Agentic Commerce Protocol), developed by OpenAI and Stripe, enables an AI agent to handle product, discovery, checkout, and payments from a chat interface like ChatGPT.

The UCP (Universal Commerce Protocol), an open source solution developed by Shopify and Google, provides a way for checkouts to happen through a buy button throughout Google’s AI and Search ecosystem as well as Anthropic’s Claude, regardless of whether the transaction is happening on a WooCommerce store or any other shopping platform. A developer only has to implement a UCP-compliant MCP Server for WooCommerce.

WooCommerce sits in the middle of those protocols, where their integrations come together.

Enablement Strategy For WooCommerce

LePage described a practical perspective for how AI fits into the WooCommerce platform through MCP. He calls this approach enablement.

He explains this approach:

“What’s interesting about that is it follows a strategy that we’re taking at WooCommerce, which is what I refer to as enablement, where WooCommerce is this core software, this core way that you run a digital business online.

And we want to make sure that core software is available and always in the middle of whatever’s happening in AI.

So we want to build AI features for it. We want to make it really easy for others to build AI features for it. But we absolutely want to make sure it will meet you wherever your AI tools are, wherever the best financial analysis AI tool exists, wherever the best general chatbot exists.

So to us, MCP represents a really strong opportunity there.”

Because MCP is flexible to whatever AI platform a user is on, WooCommerce is able to remain in the middle, regardless of which AI system a user subscribes to.

Practical Use Of AI In WooCommerce

LePage brought attention to practical uses of AI right now, where users can leverage ChatGPT Connectors and Claude Code from within WooCommerce in order to have multiple apps and AI communicate with each other to accomplish various tasks.

He explains:

“What’s also cool is if you use ChatGPT with connectors, if you use Cloud Code with their MCP support, there’s a lot of opportunity that you get when you add multiple pieces of software to one session.

So if I take my WooCommerce stuff and I take QuickBooks and I take X, Y, and Z, I can interact with all of them in a conversational manner.

And that’s got me very excited, but it’s also got all the merchants really excited.”

AI Is Developer-Facing Infrastructure

While profound AI implementations are quickly coming together for WooCommerce, LePage indicated that, at this moment, the current work is foundational, providing the building blocks that developers and agencies use to make it all work rather than delivering out-of-the-box merchant features today.

The question asked in the podcast was:

“…is that where we are with WooCommerce and AI at the moment is that you do need really a developer to hook it all up and make it work?”

LePage answered:

“So I’d say yes, if you want a really robust AI implementation that’s built and fits like a glove on your store and does everything that you ever want, the pieces are there.”

He later said that there are plugins that can implement some of those functionalities.

Sidekick-Type Functionality

LePage offered an exciting preview of what’s in store in the near future for WooCommerce when asked if WooCommerce will ship with deep native integration of AI similar to Shopify’s Sidekick AI assistant.

Shopify Sidekick is an AI assistant that can be invoked at various points in the store management workflow, enabling store owners to perform creative tasks like transforming product images or creating email marketing campaigns to handling common store management tasks.

The question asked was:

“One thing I’d love to know is what is planned for Core, possibly WordPress as a whole, certainly WooCommerce, in terms of like an interface built into Core, like how Shopify has Sidekick where wherever you are, you can just type what you want and it will do it for you.”

LePage answered that this kind of AI integration will likely be in the form of an extension, explaining that integrating this kind of functionality within core would be good, but doing it with a plugin would be great. He explained that all the pieces for doing this will be in place within core in version 7, which will be released on April 9, 2026.

He shared that WooCommerce will be an orchestration layer, where WooCommerce sits in the middle, directing and coordinating multiple services, tools, and data sources.

He explained:

“…it will work if we made it a very basic implementation in core, or as even like a very basic plugin, but it will be great when we can plug it into things like WooCommerce Analytics, when we can plug it into much more complex orchestration workflows under the hood to go and do things like really bulk product optimization and catalog stuff and analytics and deep number crunching, all of the fun stuff that we’re actually working on as we speak.

So you will see AI support in terms of this Sidekick-type implementation coming out from Automattic in this extension territory. And that extension also housing additional AI features to make it a much more approachable AI experience to merchants.”

Consumer-Facing AI In WooCommerce Stores

Another area discussed in the podcast was consumer-facing AI implementations that introduce more personalization and chat interfaces for retrieving order information or product selection.

At this point, the podcast jumps into agentic AI shopping, which is projected to become a thing between the near future and 2030.

But at the end, LePage circles back to affirming WordPress’s role as the orchestration layer intended to support whatever functionality and vision emerge.

LePage shared:

“These building blocks are intended to make WordPress into a platform where a developer can build any AI solution.”

WordPress and WooCommerce are very much in transition to providing the option of becoming an orchestration layer. While other content management systems are a little further down the road with these kinds of functionalities, WordPress and WooCommerce have a huge developer ecosystem that is already innovating new features that will become more powerful and useful in the very near future.

Watch the Do the Woo podcast with hosts Katie Keith and James Kemp:

AI Meets Woo: the Future of Ecommerce is Already Here

Featured Image/Screenshot Of Do the Woo Podcast

CleanTalk WordPress Plugin Vulnerability Threatens Up To 200K Sites via @sejournal, @martinibuster

An advisory was issued for a critical vulnerability rated 9.8/10 in the CleanTalk Antispam WordPress plugin, installed in over 200,000 websites. The vulnerability enables unauthenticated attackers to install vulnerable plugins that can then be used to launch remote code execution attacks.

CleanTalk Antispam Plugin

The CleanTalk Antispam plugin is a subscription based software as a service that protects websites from inauthentic user actions like spam subscriptions, registrations, form emails, plus a firewall for blocking bad bots.

Because it’s a subscription based plugin it relies on a valid API in to reach out to the CleanTalk servers and this is the part of the plugin is where the flaw that enabled the vulnerability was discovered.

CleanTalk Plugin Vulnerability CVE-2026-1490

The plugin contains a WordPress function that checks if a valid API key is being used to contact the CleanTalk servers. A WordPress function is PHP code that performs a specific task.

In this specific case, if the plugin cannot validate a connection to CleanTalk’s servers because of an invalid API key, it relies on the checkWithoutToken function to verify “trusted” requests.

The problem is that the checkWithoutToken function doesn’t properly verify the identity of the requester. An attacker is able to misrepresent their identity as coming from the cleantalk.org domain and then launch their attacks. Thus, this vulnerability only affects plugins that do not have a valid API key.

The Wordfence advisory describes the vulnerability:

“The Spam protection, Anti-Spam, FireWall by CleanTalk plugin for WordPress is vulnerable to unauthorized Arbitrary Plugin Installation due to an authorization bypass via reverse DNS (PTR record) spoofing on the ‘checkWithoutToken’ function…”

Recommended Action

The vulnerability affects CleanTalk plugin versions up to an including 6.71. Wordfence recommends users update their installations to the latest version at the time of writing, version 6.72.

WP Engine Complaint Adds Unredacted Allegations About Mullenweg Plan via @sejournal, @martinibuster

WP Engine recently filed its third amended complaint against WordPress co-founder Matt Mullenweg and Automattic, which includes newly s allegations that Mullenweg identified ten companies to pursue for licensing fees and contacted a Stripe executive in an effort to persuade Stripe to cancel contracts and partnerships with WPE.

Mullenweg And “Nuclear War”

The defendants argued that Mullenweg did not use the phrase “nuclear war.” However, documents they produced show that he used the phrase in a message describing his response to WP Engine if it did not comply with his demands.

The footnote states:

“During the recent hearing before this Court, Defendants represented that “we have seen over and over again ‘nuclear war’ in quotes,” but Mullenweg “didn’t say it” and it “[d]idn’t happen.” August 28, 2025 Hrg. Tr. at 33. According to Defendants’ counsel, Mullenweg instead only “refers to nuclear,” not “nuclear war.””

While WPE alleges that both threats are abhorrent and wrongful, reflecting a distinction without a difference, documents recently produced by Defendants confirm that in a September 13, 2024 message sent shortly before Defendants launched their campaign against WPE, Mullenweg declared “for example with WPE . . . [i]f that doesn’t resolve well it’ll look like all-out nuclear war[.]”

Email From Matt Mullenweg To A Stripe Executive

Another newly unredacted detail is an email from Matt Mullenweg to a Stripe executive in which he asked Stripe to “cancel any contracts or partnerships with WP Engine.” Stripe is a financial infrastructure platform that enables companies to accept credit card payments online.

The new information appears in the third amended complaint:

“In a further effort to inflict harm upon WPE and the market, Defendants secretly sought to strongarm Stripe into ceasing any business dealings with WPE. Shocking documents Defendants recently produced in discovery reveal that in mid-October 2024, just days after WPE brought this lawsuit, Mullenweg emailed a Stripe senior executive, insisting that Stripe “cancel any contracts or partnerships with WP Engine,” and threatening, “[i]f you chose not to do so, we should exit our contracts.”

“Destroy All Competition”

In paragraphs 200 and 202, WP Engine alleges that Defendants acknowledged having the power to “destroy all competition” and were seeking contributions that benefited Automattic rather than the WordPress.org community. WPE argues that Mullenweg abused his roles as the head of a nonprofit foundation, the owner of critical “dot-org” infrastructure, and the CEO of a for-profit competitor, Automattic.

These paragraphs appear intended to support WP Engine’s claim that the “Five for the Future” program and other community-oriented initiatives were used as leverage to pressure competitors into funding Automattic’s commercial interests. The complaint asserts that only a monopolist could make such demands and successfully coerce competitors in this manner.

Here are the paragraphs:

“Indeed, in documents recently produced by Defendants, they shockingly acknowledge that they have the power to “destroy all competition” and would inflict that harm upon market participants unless they capitulated to Defendants’ extortionate demands.”

“…Defendants’ monopoly power is so overwhelming that, while claiming they are interested in encouraging their competitors to “contribute to the community,” internal documents recently produced by Defendants reveal the truth—that they are engaged in an anticompetitive campaign to coerce their competitors to “contribute to Automattic.” Only a monopolist could possibly make such demands, and coerce their competitors to meet them, as has occurred here.”

“They Get The Same Thing Today For Free”

Additional paragraphs allege that internal documents contradict the defendants’ claim that their trademark enforcement is legitimate by acknowledging that certain WordPress hosts were already receiving the same benefits for free.

The new paragraph states:

“Contradicting Defendants’ current claim that their enforcement of supposed trademarks is legitimate, Defendants conceded internally that “any Tier 1 host (WPE for example)” would “pushback” on agreeing to a purported trademark license because “they get the same thing today for free. They’ve never paid for [the WordPress] trademarks and won’t want to pay …”

“If They Don’t Take The Carrot We’ll Give Them The Stick”

Paragraphs 211, 214, and 215 cite internal correspondence that WP Engine alleges reflects an intention to enforce compliance using a “carrot” or “stick” approach. The complaint uses this language to support its claims of market power and exclusionary conduct, which form the basis of its coercion and monopolization allegations under the Sherman Act.

Paragraph 211:

“Given their market power, Defendants expected to be able to enforce compliance, whether with a “carrot” or a “stick.””

Paragraph 214

“Defendants’ internal discussions further reveal that if market participants did not acquiesce to the price increases via a partnership with a purported trademark license component, then “they are fair game” and Defendants would start stealing their sites, thereby effectively eliminating those competitors. As Defendants’ internal correspondence states, “if they don’t take the carrot we’ll give them the stick.””

Paragraph 215:

“As part of their scheme, Defendants initially categorized particular market participants as follows:
• “We have friends (like Newfold) who pay us a lot of money. We want to nurture and value these relationships.”
• “We have would-be friends (like WP Engine) who are mostly good citizens within the WP ecosystem but don’t directly contribute to Automattic. We hope to change this.”
• “And then there are the charlatans ( and ) who don’t contribute. The charlatans are free game, and we should steal every single WP site that they host.””

Plan To Target At Least Ten Competitors

Paragraphs 218, 219, and 220 serve to:

• Support its claim that WPE was the “public example” of what it describes as a broader plan to target at least ten other competitors with similar trademark-related demands.
• Allege that certain competitors were paying what it describes as “exorbitant sums” tied to trademark arrangements.

WP Engine argues that these allegations show the demands extended beyond WPE and were part of a broader pattern.

The complaint cites internal documents produced by Defendants in which Mullenweg claimed he had “shield[ed]” a competitor “from directly competitive actions,” which WP Engine cites as evidence that Defendants had and exercised the ability to influence competitive conditions through these arrangements.

In those same internal documents, proposed payments were described as “not going to work,” which the complaint uses to argue that the payment amounts were not standardized but could be increased at Defendants’ insistence.

Here are the paragraphs:

“218. Ultimately, WPE was the public example of the “stick” part of Defendants’ “trademark license” demand. But while WPE decided to stand and fight by refusing Defendants’ ransom demand, Defendants’ list included at least ten other competitors that they planned to target with similar demands to pay Defendants’ bounty.

219. Indeed, based on documents that Defendants have recently produced in discovery, other competitors such as Newfold and [REDACTED] are paying Defendants exorbitant sums as part of deals that include “the use of” Defendants’ trademarks.

220. Regarding [REDACTED], in internal documents produced by Defendants, [REDACTED] confirmed that “[t]he money we’re sending from the hosting page is going to you directly”.

In return, Mullenweg claimed he apparently “shield[ed]” [REDACTED] “from directly competitive actions from a number of places[.]”.

Mullenweg further criticized the level of contributions for the month of August 2024, claiming “I’d need 3 years of that to get a new Earthroamer”.

Confronted with Mullenweg’s demand for more, [REDACTED] described itself as “the smallest fish,” suggesting that Mullenweg “can get more money from other companies,” and asking whether [REDACTED] was “the only ones you’re asking to make this change” in an apparent reference to “whatever trademark guidelines you send over”.

Mullenweg responded “nope[.]”. Later, on November 26, 2024—the same day this Court held the preliminary injunction hearing—Mullenweg told [REDACTED] that its proposed “monthly payment of [REDACTED] and contributions to wordpress.org were not “going to work,” and wished it “[b]est of luck” in resisting Defendants’ higher demands.”

WP Engine Versus Mullenweg And Automattic

Much of the previously redacted material is presented to support WP Engine’s antitrust claims, including statements that Defendants had the power to “destroy all competition.” What happens next is up to the judge.

Featured Image by Shutterstock/Kues