Liquid Web WordPress Plugin Rebrand Triggers Backlash via @sejournal, @martinibuster

Liquid Web inadvertently started a cascading series of controversies after it folded a group of well-known WordPress plugin brands into a new software lineup. The reconfiguration and rebranding caught users by surprise, leading to confusion and significant online backlash against Liquid Web across social media.

A Dynamic WordPress Facebook group admin started a discussion about the Liquid Web plugin and branding controversy that reflected the confusion at the time, writing:

“It looks like a bit of chaos in the Kadence FB group as LiquidWeb moves to integrate their tools under a single umbrella. What’s interesting is that they’ve dropped Lifetime Bundle (LTD) and now have 3 packages:

• $99 Essentials (theme and blocks),
• $219 Pro (which includes ShopKit)
• and $399 Elite.

Ultimately, people aren’t happy. It appears that their licenses aren’t working. That’s something they should be able to fix. However, it’ll be interesting to see what level of access people get. Will LTD owners still retain access to addons like ShopKit and Kadence Conversions?”

One person in that Dynamic WordPress Facebook group discussion blamed private equity investments in web hosting for the issue, a sentiment that was echoed on X, where @jeffr0 suggested that maybe Matt Mullenweg had a point about private equity firms and WordPress hosting investments.

@jeffr0 tweeted:

“So I guess @photomatt had a point. Private Equity in the WordPress ecosystem blows.”

Someone else disagreed with blaming private equity investors, responding:

“I’m not sure I agree. First, WPE wasn’t doing anything wrong. …I’m also not sure what’s happening to these plugins is a result of LW being owned by PE.”

Reflecting the confusion in the moment, @srikat tweeted:

“I can’t find the downloads for my lifetime Kadence purchase. Just sent them a support email ticket..”

Nexcess/Liquid Web Branding and Rebranding

Part of the confusion stems from a yearslong series of Liquid Web and Nexcess branding flip-flops.

• Liquid Web acquired Nexcess in 2019.
• The two brands later moved toward a unified Liquid Web identity.
• By late 2025, users who typed in nexcess.net were often redirected to liquidweb.com.
• In April 2026, Nexcess relaunched as a “Specialty Cloud” brand combining Liquid Web’s managed hosting expertise with Servers.com’s bare-metal infrastructure.

Meanwhile, Liquid Web is now the managed hosting brand within the Nexcess ecosystem.
StellarWP Disappears: Plugins Emerge In Nexcess And Liquid Web
Previously, the plugins lived under the StellarWP brand, with many maintaining their own standalone websites. The new branding is confusing for some users because both Nexcess and Liquid Web describe the same WordPress products as part of their own ecosystem.

The Nexcess relaunch announcement from April 8, 2026 says:

“We’re expanding your toolkit by bringing leading software solutions, like Kadence, GiveWP, The Events Calendar, and LearnDash, directly into the Nexcess ecosystem.”

Liquid Web’s May 12, 2026 web page describes the same products as part of the Liquid Web by Nexcess software portfolio:

“Liquid Web by Nexcess is concentrating its diverse WordPress software portfolio into four core products…”

The overlapping language between both brands helps explain why the rollout appeared confusing from the outside. The products were described as moving into both Nexcess and “Liquid Web by Nexcess,” and StellarWP seemingly disappeared without notice.

Liquid Web’s software announcement says its WordPress software portfolio is now concentrated into four core products: Kadence, LearnDash, The Events Calendar, and Give. The company says SolidWP, Iconic, Restrict Content Pro, and MemberDash are no longer sold as standalone products, with their features folded into Kadence or LearnDash.

What It Means For Plugin Subscribers

For existing customers, Liquid Web says the change is optional. The company says customers can keep their current features, plans, pricing, tools, and license keys unless they choose to upgrade to one of the new software plans.

But the public rollout appears to have created confusion among plugin users, including lifetime deal customers who were unsure what happened to the products they had purchased. Social media posts described product pages disappearing, redirects not working as expected, and users trying to determine whether their plugins had been discontinued, renamed, or moved.

In a post to a discussion in the Dynamic WordPress Facebook group, Jack Kitterhing, Strategic Product Leader at Nexcess, confirmed that lifetime subscription plugin customers would retain what they already had and that every customer was being grandfathered in. He also acknowledged login issues and missing invoices, describing the move as a “massive migration and change of systems” that came with challenges.

Kitterhing posted an explanation of what’s going on:

“Just to confirm Lifetime customers retain everything they already had. We aren’t removing anything or watering it down. If you owned it you still own it today. Every single customer is being grandfathered in.

And we re-positioned Kadence Essentials so for those of you who just want the theme and blocks it’s now cheaper than it used to be ($99 vs $129) to get the core components of Kadence.

There are currently issues with logging in for some customers and missing invoices which the team is fixing as I type and we expect to be fully fixed in a few hours.
This was a massive migration and change of systems and like anything of such magnitude it comes with challenges. Thanks for bearing with us as we get this all up and running today.”

Takeaways

• Liquid Web says existing customers keep their current features, pricing, plans, tools, and license keys.
• Lifetime customers were told they retain what they already had.
• The backlash appears to have been driven by confusion during the rollout, not only by the product consolidation itself.
• Years of Liquid Web and Nexcess branding changes made the plugin migration harder to understand.
• Clearer advance communication may have reduced the confusion around product pages, redirects, licenses, and lifetime deal access.

There appears to have been insufficient communication from Liquid Web and Nexcess, compounded by the two companies’ branding flip-flops. The situation appears to be on the way to being resolved.

Featured Image by Shutterstock/hoangpts

WordPress 7.0 Will Ship Without Real-Time Collaboration via @sejournal, @martinibuster

WordPress announced that the real-time collaboration feature will not ship in the upcoming 7.0 release, citing that the current approach is not yet “robust enough” to be included. The response from the WordPress community was a collective sigh of relief.

A post by Matt Mullenweg in the official WordPress Make Slack workspace explained the reasons for removing the feature:

“Hi
I would say I’m not confident with RTC being in core at this point.

I’m fine taking the heat for pulling it out, but the surface area, race conditions, server load, memory efficiency, and the bugs that keep popping up in fuzz tests / etc don’t give me a lot of confidence on our current approach being the robust one we want to support.

There’s also the added burden right now of the WP Engine lawfare and depositions being a time DoS for critical people, perhaps without that in the background we could have gotten to a better place by now, but I don’t think with the current deposition schedule and all the faff around discovery we’re able to support this feature”

Real-time Collaboration (RTC)

WordPress delayed the release of version 7.0 due to the inability to finalize the collaboration feature. Collaboration is Phase 3 of a four phase development road map and version 7 was meant to mark the phase 3 milestone.

Real-time collaboration enables multiple users to edit posts or pages simultaneously. The current default is to lock a web page or post if someone else is working on it. The purpose of collaboration was to bring better editorial workflows by eliminating “post locking” and ensuring changes appear instantly across all active sessions.

Matt Mullenweg tweeted in April that the real-time collaboration feature could also enable AI to edit in real-time, too. That part of the feature was likely to be the most popular use of RTC but aside from Matt’s tweet nothing else was actually said about that.

The commercial WordPress hosting platform WordPress.com has had a controlled roll-out of the RTC feature for VIP and Enterprise users since late 2025.

A support page on WordPress.com explains:

“With real-time collaboration, you and other users on your site can edit the same post or page in the WordPress Editor at the same time and see each other’s changes as you type. This guide covers how to turn real-time collaboration on or off and what to expect while editing together.

This feature is available on sites with the WordPress.com Personal, Premium, Business, and Commerce plans. For free sites, upgrade your plan to access this feature.”

Response To Announcement

Many folks in the WordPress community were not surprised by the delay because it had become evident that finalizing the feature was not progressing fast enough to make the release deadline of May 20, 2026.

Now the process begins to remove the feature from the 7.0 release.

According to the announcement:

“Today, @matt made the decision to remove real-time collaboration from WordPress 7.0 and shared that he is not confident the current approach is robust enough to include in Core at this time, citing concerns around surface area, race conditions, server load, memory efficiency, and recurring bugs found through fuzz testing.

This is a difficult decision, especially given the amount of work that has gone into the feature, but it is being made in service of shipping a stable and reliable WordPress 7.0 release for our users. Work to remove the feature from the release is being organized in #65205 and in the #feature-realtime-collaboration. At this time, the release schedule remains as is and further updates will be provided if the schedule needs to change to unwind this feature.”

Upbeat Response To Removal Of RTC

The general response to the announcement was relief and agreement that it was a good idea. Some disagreed that the feature should ever become a part the WordPress Core because it wasn’t something that most users would need. Although an argument could be made that AI-powered collaboration would be highly popular.

One of the comments to the official announcement on WordPress.org welcomed the decision.

Kento wrote:

“I honestly welcome this decision, besides the fact that this needs further work to confidently get into core, it will also give extension developers more time to prepare, experiment and provide feedback.”

Over on X, WordPress entrepreneur Katie Keith shared her opinion that the feature is delayed but not written off and will likely be returning in the near future.

She shared:

“This looks significant, but I think it’s a delay rather than an actual change of direction or strategy.”

In a completely different discussion on X, Justin Ferriman tweeted:

“That feature always came across as a bit tone deaf. This was the right decision.”

Mark Wesguard agreed:

“Good move. I never understood why this should be in core.”

Hendrik Luehrsen praised WordPress co-founder Matt Mullenweg for his leadership:

“Good call, @photomatt! It’s good to see brave decisions being made in the project at the moment. Inspires hope.”

Similar sentiments were echoed on the Dynamic WordPress Facebook Community (visible to members only), where members expressed the opinion that the feature would be best as a plugin and that the feature was irrelevant for most users.

My own view is that RTC seemed like it had the potential to become a popular way to collaborate in real time with an AI agent. It would also make it easier for teams to collaborate on editing.

Featured Image by Shutterstock/TierneyMJ

WordPress Loses Marketshare. Is Astro Eroding Their User Base? via @sejournal, @martinibuster

A discussion on Twitter about the many people posting that they’ve left WordPress for Astro went modestly viral, with longtime WordPress supporters explaining why they ditched WordPress for Astro. Statistics show that WordPress is losing users and Astro is gaining them at a rate of 100% year over year, indicating that the shift toward Astro is more than a passing trend.

WordPress Marketshare Steadily Declining

An underreported statistic about WordPress is that WordPress peaked in mid 2025 with a marketshare of 43.6% and has been on a steady decline ever since, currently sitting at a 42.2% marketshare (according to W3Techs), a drop of 1.4%.  WordPress is losing marketshare, this is a fact.

An argument could be made that the WordPress marketshare percentage is inflated because a significant number of WordPress websites are abandoned or spam. The official WordPress statistics show that 10.56% of WordPress websites haven’t been updated since 2022. That means, if you don’t count abandoned websites, the actual WordPress marketshare is less than the 42.2%.

Astro Downloaded 2.5 Million Times Per Week

Astro is a static site generator and web framework. It’s not a content management system, it is software that generates websites from content. Sites created with Astro are called static because they are classic HTML web pages that are not dynamically generated from a database the way that PHP-based sites built with WordPress are. The consequence is that Astro-based sites download faster and are less complicated.

Astro had been steadily gaining popularity since it debuted in 2021. The idea that Astro is not popular and that the hoopla is loud voices is demonstrably false. Astro’s popularity is real. It is currently being downloaded at a rate of 2.5 million downloads per week. That’s a 100% increase from 2025 when it was being downloaded at a rate of 1.4 million weekly downloads.

Screenshot Of The Astro Download Statistics

Joost de Valk, founder of the Yoast SEO plugin, may have identified one of the reasons why so many people are turning to Astro. He recently wrote of an epiphany in which he realized he didn’t need a content management system (CMS); he just needed a website.

He wrote:

“For twenty years, ‘I want a website’ meant “I need a CMS.” WordPress, Joomla, Drupal: the conversation was always about which one. That framing is outdated. People never wanted a CMS. They want a website.”

Some Doubt The Astro Reality

Rayhan Arif, a WordPress business person, recently expressed his incredulity over the many tweets and blog posts by people sharing their experience leaving WordPress for Astro.

He tweeted:

“Every “’leaving WordPress’ post I come across seems to point to Astro. But when I dig a little deeper, I often don’t see any prior conversations or context showing those people were actually using WordPress in the first place.

To me, it starts to feel less organic and more like a coordinated narrative almost like a well-planned negative campaign against WordPress. It even makes me wonder whether some companies might be incentivizing this kind of messaging for their own business gains.

I could be wrong, but that’s honestly the impression I’ve been getting.”

That tweet seemed to imply that Cloudflare, which acquired Astro at the beginning of 2026, may have been orchestrating a whisper campaign. But nobody in that discussion agreed with him.

Astro Had Momentum Predates Cloudflare’s Acquisition

One of the first responses pushed back against the idea of a whisper campaign. Tommy J. Vedvik argued that the movement toward Astro was already happening before Cloudflare acquired Astro or created EmDash.

Vedvik responded:

“You’re probably wrong if you think it’s Cloudflare who’s behind it. This happened way before Cloudflare acquired Astro or created EmDash”

David V. Kimball made a similar point from his own experience, saying he had been encouraging people to move away from WordPress before Astro became part of a broader public conversation.

Kimball wrote:

“No, I’ve been pushing people away from WordPress to Astro before it was cool, starting about two years ago.”

He added that he had not seen many others doing the same until recently, but described himself as “a living breathing person” who had already helped many people make that move.

The pushback did not prove that every post was organic, but it did challenge the idea that the pattern began with Cloudflare. The replies suggested that Astro had already been gaining ground among some developers before the recent attention around EmDash.

Not everyone who left WordPress rushed toward Astro. Front end developer Tammy Hart shared that she was a WordPress defector but that she loathed Astro.

Longtime WordPress Defecting To Astro

Several respondents made a point of establishing their WordPress credentials. That became one of the thread’s strongest themes: the most detailed criticisms were not coming from people with no history in WordPress, but from people who said they had built careers, businesses, or client work around it.

Daniel Schutzsmith responded by identifying himself as both an Astro user and a long-time WordPress professional.

Schutzsmith wrote:

“Real Astro user here and I think you’ll see I’ve made 100s of sites with WordPress, been WCUS organizer 3 times, WCNYC organizer 2 times, and WCMIA organizer 1 time.”

Keanan Koppenhaver made a similar credibility claim, writing:

“Former VIP-agency dev, WP agency owner, current plugin owner and multi-time WordCamp speaker, here.

I’m using Astro for a lot now! Still WP in some cases, but Astro, especially when you’re working by yourself or with a git-knowledgeable small team, helps you move way faster.”

Mike Sewell acknowledged that he used both WordPress and Astro but that WordPress is no longer his go-to:

“I have been building client sites with WordPress since 2010. I still use it for some jobs, but I have found myself more and more reaching for other tools – nextjs + sanity, 11ty, and experimenting with EmDash. WordPress isn’t going anywhere but it’s no longer my go to.”

Many others shared similar backgrounds with WordPress, showing that there may be a movement from within the WordPress ecosystem that is moving away from WordPress.

The Matt Mullenweg Effect

While most users shared that the reason for leaving WordPress were pragmatic reasons like Astro’s performance and relative simplicity, Schutzsmith, the former WordCamp organizer who had built hundreds of WordPress sites, explained that his reason for moving away from WordPress was due to clients expressing skittishness about committing to WordPress after Matt Mullenweg’s actions which left hundreds, if not thousands, of WP Engine customers unable to update their WordPress websites.

Schutzsmith shared:

“Matt steered it in a horrible direction and now it’s become very hard to sell WP to enterprise clients that literally see the drama he creates by seeing the articles and videos across publications and influencers about it.

That impact has not gone away. In fact, the monumental expansion of things like Claude Code and OpenAI Codex, make moving to a less dramatic, more stable content management system, a no-brainer.

Selling enterprise on JavaScript based solutions has become much easier than convincing that same buyer that their site won’t be affected if Matt has another meltdown.

The minute he said .org is his personal website to distribute plugins and themes, it made it no longer safe for the enterprise.”

Schutzsmith was speaking from professional experience, later explaining that six of his client’s websites hosted on WP Engine were disrupted because of actions taken by Mullenweg.

AI Coding Tools Are Making Astro Viable

Lastly, AI-assisted coding was one of the highest cited explanations for why Astro is receiving more attention now. Several replies in the discussion suggested that AI tools make code-first site development feel faster and less dependent on traditional CMS interfaces.

David Hamilton described Astro as a strong fit for Claude Code, writing:

“I use astro because it is ridiculously compatible with Claude code.

I haven’t had to open a CMS a figma board or anything.

My latest websites are all made through Claude and astro, I don’t see myself moving back to the traditional website builders anytime soon.”

There were many others who shared the exact same experience.

A Balanced View Of AI And Web Development

Yet there are others like Kevin Geary, developer of the Etch website builder, who express a nuanced opinion of using AI for creating websites.

In a separate post from several weeks earlier he wrote:

“A logical, evidence-based conclusion about where AI fits into a quality development workflow is: AI is a great tool for improving productivity but has to be heavily reviewed and steered by someone who actually knows what they’re doing.

If you’re in the 100% anti-AI camp, you’re likely taking a purely emotional position.

And if you’re in the “AI can do it all, run 18 agents at a time, coders are cooked” camp, you’re also taking a purely emotional position.”

Is The WordPress Ecosystem Eroding?

Anecdotal evidence indicates that WordPress veterans are leaving or minimizing their use of WordPress, largely because of the benefits of Astro, not necessarily because WordPress is a poor experience. Some are choosing Astro because it is faster. Others are using it because AI coding tools make code-first workflows easier and faster. Some are choosing it because their sites are mostly static, making WordPress somewhat overkill for their situation.

Then there are some who believe that the WordPress governance drama has become a business risk.

The larger story is not that Astro is replacing WordPress; it’s still too early to make that claim. The more important question is whether the turn toward Astro is a sign that WordPress has become overly complex and that it’s now easier to build with AI.

Ironically, on the other side of that argument, WordPress is on the verge of a major transformational change due to AI. WordPress version 7.0 is set to bring all the benefits of AI into WordPress at a scale that no other CMS or website-building framework can match. The massive community of plugin and theme developers is poised to roll out AI-assisted features that will be hard to compete against.

Featured Image by Shutterstock/yulsiart

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