I've been running a WordPress site for around 5 years. Recently, I've been working with AI to help build prototypes, which it is very adept at.

One of the things I'm seeing is a bit of a collision between highly maintainable WordPress blocks, and quick and beautiful AI-generated code that is by nature less maintainable. I'm finding more of my site is becoming custom HTML code to achieve the look I want.

I'm interested in this community's opinion on what ends up bridging the gap here. The speed at which one can create fast HTML/JavaScript based websites with AI is not something that will be lost on both new and experienced website builders, and yet WordPress still dominates internet web sites not only for its CMS but also its ability to build and maintain sites very easily.

I'm not an expert here, so I'd love to hear the up close view from the experienced crowd here.

I just woke up to find that I've lost the TEC website, its redirecting to somewhere else!! anyone faced the same issue?

Hi guys,

I’m currently auditing my infrastructure costs and planning to move 32 client sites. I'm torn between sticking with a giant like WPMUDEV or going with KloxStudios.

The price difference between the two is significant. I know WPMUDEV is the industry standard for "all-in-one" plugin ecosystems, but KloxStudios offers a bundle that seems to cover the essentials (especially their security tools) for a fraction of the price.

Has anyone here made the switch to Klox or used them for agency-level hosting? I need to know if their performance holds up or if this is a "get what you pay for" situation. I have to pull the trigger by Monday, so I'd appreciate any real-world experience regarding their uptime and plugin stability.

Cheers!

I've been a fan of the Blocksy theme myself, but I still find myself needing a blocks plugin to use on top of Gutenberg.

Kadence (theme + blocks plugin) had one of the better offerings than the competitors, especially in the free version. It's one of the more recommended tools for performance in this subreddit as well. GeneratePress, although lean and clean, is quite limited in terms of even the basic features.

Greenshift is a great option, but it takes an FSE approach, so I guess it's not exactly a drop-in replacement for Kadence.

Are there any other theme + blocks plugin combinations that you guys recommend for people trying to move away from Kadence, and what appears to be a highly incompetent company, Liquidweb?

Hey all — looking for some honest answers from folks who manage multiple client sites for a living.

I'm trying to understand a specific failure mode better: the one where the site is technically "up" — homepage loads, returns 200 — but something is actually broken. Contact form silently failing, checkout throwing an error after the button click, a plugin update killing the booking widget, etc. The kind of thing your monitoring doesn't catch because it's looking at the wrong thing.

• What are you currently using for uptime monitoring across your client sites? (Doesn't matter if it's UptimeRobot free tier, BetterStack, a homegrown cron, or nothing — just curious what's actually working out there.)
• What's the last silent failure that bit you? The one where the client called or emailed you about something broken before your monitoring did. What was it, and how did you eventually find out?
• After that happened, did you actually change anything in your monitoring setup — or just kind of move on and hope it doesn't happen again?

Not pitching anything, not selling anything. I'm trying to figure out if a thing I'm thinking about building is solving a real problem, and I'd rather find that out from people doing the work than from my own head.

Happy to share back what I learn if there's interest.

WordPress 7.0 lost its headline feature yesterday. The infrastructure story underneath is more interesting, and it's already in production.

Yesterday Matt pulled RTC (real-time collaboration) from WordPress 7.0. RC4 ships May 14, final on May 20, RTC has no new target version.

Most of the coverage I've read frames this as "WordPress lost its headline feature." Which is true. But I think the more interesting question is the one nobody seems to be asking yet:

If RTC isn't the infrastructure shift in WordPress 7.0, what is?

The answer is hiding in plain sight. While everyone covered RTC for six months, WordPress quietly shipped a complete AI infrastructure stack across 6.9 and 7.0:

• Abilities API (6.9, December 2025) — the PHP layer. Plugins register their capabilities so AI assistants can recognize and call them. The foundational primitive for agents that edit WordPress.
• Client-Side Abilities API (7.0) — @wordpress/abilities and @wordpress/core-abilities packages. Auto-fetches server-registered abilities via REST. Explicitly described in the dev notes as "laying the groundwork for browser agents and WebMCP integration."
• WP AI Client (7.0) — provider-agnostic AI infrastructure in core. Standardized interface so plugins don't each reinvent their integration with OpenAI, Anthropic, Google.
• Connectors API (7.0) — credentials storage and provider selection at the platform level. Three official provider plugins shipping with it: OpenAI, Google, Anthropic.

That's not one API. That's a complete platform shift. WordPress 7.0 is the first version of WordPress that ships AI infrastructure as a first-class core concern, with the same architectural commitment that the REST API got in 4.7 or Gutenberg got in 5.0.

I've been building production infrastructure on top of this stack as a solo dev for the last five months. Wanted to share what I've learned, because I think a lot of the same engineering problems that pulled RTC are about to show up in AI-agent territory and this community is going to be the one that has to deal with them in the field.

What this stack actually enables

In one sentence: the difference between "AI generates HTML you paste in" and "AI safely edits the right field in the right module on the right page builder, with the right validation, on a real client site."

Every page builder stores content completely differently:

• Elementor: post meta with serialized JSON
• Divi 4: shortcodes inline in post_content
• Divi 5: Gutenberg block markup
• Bricks: serialized post meta (different shape)
• Oxygen Classic: post meta with shortcodes AND JSON
• Oxygen 6: different shape from Oxygen Classic in the same plugin family
• Breakdance: its own JSON
• Beaver Builder: _fl_builder_data post meta
• WPBakery: shortcodes with attribute parser
• Flatsome UX Builder: own format
• Brizy: own format
• Thrive Architect: own format

An "AI plugin" that writes HTML and hopes the renderer figures it out doesn't survive contact with real client sites. You need schema-aware adapters per builder. The Abilities API is the standard registration layer that makes this tractable across plugins. WP AI Client gives every plugin a uniform LLM surface. Connectors API solves credentials at the platform level. Without all three, every plugin reinvents the same wheel and the ecosystem fragments.

With all three in core, the ceiling lifts substantially. We're going to look back at 6.9 + 7.0 the same way we look at 4.7 (REST API) and 5.0 (Gutenberg).

The bug pattern that pulled RTC is the same bug pattern AI agents hit

This is the part I find genuinely interesting and want to hear pushback on.

The five concerns Matt cited for pulling RTC: surface area, race conditions, server load, memory efficiency, recurring fuzz-test failures. Read carefully, all five describe the same family of consistency bug. The database accepts a state both clients agree on. Neither client's local renderer can reconcile it. Persistence is honest. The render layer isn't.

Two cursors typing in the same paragraph. The system has to decide which edit wins, how to merge, how to surface what happened.

Now look at AI agents editing the same WordPress site. An LLM writes a payload. The plugin endpoint accepts it. The database updates. The response says success: true. The page renders blank or wrong because some flag, some cache, some template reference, some selector specificity got missed.

Different mechanism. Same family of bug. The success signal lies.

I spent two months hunting an Oxygen Classic empty-render bug for one customer. Eight releases. Every patch fixed something real and still produced the same blank page. The final fix was that Oxygen's CSS regenerator expects integer ct_id values. The writer was emitting string GUIDs. The lookup missed silently. CSS never regenerated. The page rendered without its styling. The API said success the whole time.

Same family of bug as the RTC concurrent-edit problem. Different surface. Same engineering question core is now wrestling with at the platform layer.

Three things I'd tell anyone building on the AI stack in 7.0

These are the lessons that cost me real time. Sharing them because I think the community is about to need them.

1. Build the render-validation gate before the write path

If your plugin exposes an ability that writes to a page, HEAD-fetch the preview URL after the write completes. Check the rendered output. If it doesn't reflect what you just wrote, surface partial_write: true with structured trace fields. Don't trust your own success responses.

This is non-negotiable. The AI agent calling your plugin does not have eyes on the page. It only has your response. If your response lies, the agent confidently tells the user "done" while their site is broken. Same shape of failure RTC ran into; same shape of failure every plugin shipping on the new AI stack will run into if it doesn't gate the write.

2. Snapshot before every write. Always.

Full state snapshot of post_content plus post_meta plus builder-specific data plus ACF fields, captured immediately before any AI write touches the post. Restore in one click.

This is the foundational safety primitive for AI editing WordPress. Not a feature, not a "premium" thing. The minimum viable safety story. Builder support without snapshot is playing with fire on production sites.

3. Schema-aware adapters per builder, not "an AI plugin"

The temptation is to build a generic AI editing plugin and hope it works across builders. It won't. Every page builder needs its own adapter that understands its specific data model, its specific render path, its specific cache invalidation requirements.

This is the part that takes time. There's no shortcut. The Abilities API gives you the registration layer; WP AI Client gives you the LLM-side abstraction; Connectors API gives you credentials. The per-builder intelligence is still the work, and it lives outside core.

Why this matters for the broader 7.x roadmap

The pattern Gutenberg followed for major features was: feature plugin first, extended community testing, then core inclusion. Full Site Editing went through this. Block Patterns. The Site Editor. RTC will probably follow the same path now.

I'd argue AI-agent infrastructure follows the same path, with the foundation already in core. The Abilities API + WP AI Client + Connectors API are the platform commitments. The per-plugin implementations and the cross-plugin patterns are going to mature in the field first, then stabilize, then probably show up as more opinionated core APIs in 7.2 or 7.3.

The agencies and freelancers in this subreddit are going to be the ones who run that maturation. You're going to hit the silent-fail bugs. You're going to find the cache-invalidation gotchas. You're going to discover which builders need which adapter shapes. You're going to figure out which workflows actually want WP AI Client's abstraction layer and which want raw MCP. The work happens in the field, not in core.

I'd love to hear from anyone who's already touching the new AI stack on real client sites. Abilities API, WP AI Client, Connectors API, all three? What are you running into?

The disclosure

I build Respira for WordPress, an independent AI infrastructure layer for WordPress. Five months solo from Brașov, Romania. We support 12 page builders. Our biggest release shipped yesterday, same day RTC pulled from 7.0 (genuinely a coincidence).

Public live telemetry: 752 connected sites, 3.4M lines of code shipped through customer projects since March, 42K MCP events, zero API errors this week. The dashboard at respira.press/live updates every sixty seconds and is the place to verify any number I just cited.

Free Lite version is in the WordPress.org submission queue. Should land in a few weeks.

https://preview.redd.it/vhecigjimb0h1.png?width=3440&format=png&auto=webp&s=5fd4fdf9d388bd9ee737841320b1bfbce65fa15a

I'm in the comments for the rest of the day. Happy to go deep on:

• Page builder schema gotchas across the twelve the product supports
• MCP server architecture for production WordPress (i open-sourced it)
• How the new WP AI Client and Connectors API compare to MCP, and whether they overlap or stack
• Why we shipped a Claude Cowork plugin the same week, and what that audience needs that Code doesn't
• Whether the right shape for AI-agent ecosystems is one giant plugin or an SDK with first-party + partner addons (we bet on the SDK; happy to argue either side)
• Whether AI-agent infrastructure follows the Gutenberg-feature-plugin path next
• CLI vs MCP vs slash commands: which surface area matters for which kind of WordPress work
• Anything else useful

If you want the longer write-up of how this week unfolded (six releases, the Oxygen arc, why the API not lying matters), it's on my Substack at respira.love. Not selling anything there either; it's free.

--Mihai, Respira for WordPress (respira.press)

Hey everyone,

I really need some honest advice because I’m feeling stuck and frustrated.

I’ve been working as a WordPress developer for 3+ years now and have completed 300+ projects. I’m experienced with Wordpress, Elementor Pro, HTML, CSS, JavaScript, PHP etc and building fully responsive websites.

The problem is… almost all of my work has come through jobs, agencies, or middlemen.

I’ve never really been able to build my own consistent client flow.

I’ve tried Fiverr and Upwork, but they feel extremely saturated. I send proposals, optimize gigs, try different strategies… but results are very inconsistent. It feels like no matter how skilled I am, I’m just lost in the crowd.

Now I’m stuck in this cycle where:

• I have solid experience
• I can clearly deliver value
• But I still depend on others to bring me work

And honestly, it’s starting to feel discouraging.

So I want to ask people who’ve been in this situation:

How did you break out of relying on middlemen?
How did you start getting your own direct clients consistently?
What actually worked for you? (cold outreach, LinkedIn, content, referrals, etc.)

I’d really appreciate real, practical advice. Right now I just feel like I’m missing something important.

Thanks in advance.

ok so I do WP for small businesses, mostly local stuff, coffee shops, contractors, that whole world. Last month I'm setting up site #14 and it hits me that I've literally rebuilt the same testimonial grid block four times this year. Different themes, different colors, but structurally the same thing. And I keep doing it because the actual block lives inside whichever client's WP install I built it in last, and I have no clean and quick way to pull it back out.

I tried what everyone tries:

copy-pasting the <!-- wp:... --> markup from the code editor. Fine for one block, breaks down hard once it's 30. Image URLs point at the old client's site, theme styles don't transfer, you end up keeping a Notion page of code snippets which is somehow worse than not having a system at all

theme patterns. only useful if you ship the same theme to every client. I don't. None of my clients use the same theme.

multisite. wrong tool. clients want their site on their own host, their own admin, their own domain. multisite is invasive and most hosts disable it anyway

export/import. designed for whole-site migration, not "save this hero section so future-me can reuse it"

I ended up building a plugin. Saves blocks to a personal cloud library, you log in on whatever site you're working on and your blocks show up in the inserter. It captures the relevant theme CSS at save time so the block actually looks right when you drop it on a different theme. Free tier is 10 blocks which is enough to test if it fits your workflow. It's on .org as PerAstra BlockVault.

real talk on what's still rough: it doesn't handle dynamic block like Query Loop properly yet. it'll save the markup but not the query config, so you'd re-set the query on the new site. that's the next thing I'm fixing. CSS capture also occasionaly pulls in too much ( whole theme stylesheets) which I'm currently tightening up.

mostly posting because I'm curious what other freelancers actually do for this. is anyone doing something clever I missed? the people I've talked to either copy-paste markup, migrate entire pages or just rebuild from scratch each time, and everything feel like it's outdated.

I keep seeing people say they’re moving off WordPress.

Some probably are, fair enough. But a lot of the complaints sound familiar in a different way.

• A cache plugin needs another exception.
• There is some CDN rule nobody remembers setting up.
• The security plugin blocks some requests it shouldnt block.
• WooCommerce update changes behavior somewhere.
• Client says the site feels slow and now you’re checking your hosting, plugins, Cloudflare, theme code, cron, database, whatever else got bolted on over the years.

All these tools are super important, but you end up being the person holding the whole thing together, even when the problem is somewhere between three tools and nobody wants to own it.

That feels like the part people burn out on.

For people running or managing serious WordPress sites, what’s the layer you’re most tired of babysitting?

After working on multiple WordPress projects (agency and product), we kept running into the same pattern:

Not bugs. Not plugin issues. Structural problems. The recurring problems

Blocks don’t scale. Every developer implements them differently Design systems decay. Tokens exist but nothing enforces them Performance becomes a post-build activity Junior developers unintentionally break global consistency Every project starts from scratch again Maintenance never actually ends

What we tried

Guidelines, code reviews, naming conventions, documentation: None of it held.

Because the problem wasn’t discipline. The problem was lack of enforcement.

What we changed: Instead of adding more process, we asked:

What if WordPress simply didn’t allow inconsistency in the first place?

That led us to build an internal system, now called wpTruss, with a few hard constraints.

1. Blocks must pass validation before they exist

We added a Block Validator with 12 rules. No hardcoded colors. Must use tokens

No global CSS leakage. Must be scoped. Required structure enforced. No almost correct blocks allowed

If it fails, it does not register.
Result

You don’t review blocks anymore. The system rejects bad ones upfront.

2. Tokens are not optional

We implemented a Token Registry: colors, spacing, typography, radius and shadows Blocks do not store values. They reference tokens. So when a client says Change brand color

You change one value and the entire system updates instantly.

3. Structure over theme

We removed the idea of a theme. Header is a block. Footer is a block. Templates are block compositions

Everything is built using the same system. No theme lock-in. No builder dependency. Just structured blocks assembling the entire site.

4. Elements are centralized

Instead of every block redefining headings, buttons, and images, we created an Element Registry in JS.

Each element: resolves tokens, enforces consistency, behaves predictably everywhere. So a button is not 17 variations across blocks. It is one system-controlled element.

5. Performance is not optimized. It is produced

We built an Asset Bundler that: loads CSS and JS per page, only what is used, combines and minifies, automatically, injects proper image attributes, defers JS by default, We did not build this for PageSpeed.

But the output consistently hits:

95+ out of 100 without any performance plugins

Even with:

WooCommerce, AJAX, infinite scroll microstore blocks,

6. Blocks became more than content

We started building micro-app blocks.
Example

A single block that: loads products, infinite scroll, AJAX cart, cart updates, checkout flow(default woocommerce)

This is essentially a mini storefront inside one block.

It still scores 95+. What this changes in practice, Rebrands take minutes instead of days, New projects import a system instead of rebuilding it, Junior developer risk is structurally eliminated, Performance is no longer a separate phase, Maintenance is close to zero, Or more bluntly, The system removes the need for being careful.

Why we are sharing this now

Over the past few weeks, we have been discussing parts of this problem here:

block scaling, validation, design entropy, WordPress as an operating layer

Those discussions led to this system.

If you want context, here are the earlier threads:

https://www.reddit.com/r/ProWordPress/comments/1s1h7bw/wordpress_blocks_dont_scale_we_built_a_registry/

https://www.reddit.com/r/ProWordPress/comments/1rtic2b/what_if_gutenberg_blocks_had_to_pass_validation/

https://www.reddit.com/r/ProWordPress/comments/1recqs4/preventing_design_entropy_in_gutenberg_projects/

https://www.reddit.com/r/Wordpress/comments/1rckzzf/rethinking_wordpress_as_an_operating_layer/

Where it is now, This is not a concept anymore.

It is running. Who this is for: Not beginners. Specifically: agencies, product teams, developers working with Gutenberg at scale

If you have ever said: Why does every project slowly fall apart

This is our answer.
Open to questions

Happy to break down: validator rules, architecture decisions, tradeoffs, where this might not fit

No fluff. Just what we have learned building it.

I have to create a new Wordpress website, and I want to plug Claude to be able to create or modify pages with ease. I thought about creating few templates and use them to create pages. What is the best way (and easier way) to do that?
Thanks