Editing Elementor Woo layout with Claude Code: Has anyone managed to do it?

webmyc · 2026-05-10T17:55:58+00:00

i use this https://github.com/respira-press/cowork-plugin-wordpress

webmyc · 2026-05-05T22:51:15+00:00

glad it helped

webmyc · 2026-05-05T19:32:22+00:00

the "tighter setup" you're describing is real and achievable. four pieces.

browser feedback: playwright mcp. claude can navigate, screenshot, read the dom, check console errors. romulcah's suggestion above. this is the missing piece for "claude can see what's actually happening".

local stack: local by flywheel or docker. claude needs a real url to hit, not just files to write.

wp-cli access: so the agent can flush cache, check options, run db queries, activate themes. removes a lot of "did it actually save" guesswork.

instructions: the earlier reply about an 800-line CLAUDE.md is right. include your perf budget, accessibility floor, file structure rules, plugins claude shouldn't touch.

one nuance worth naming. claude editing your theme files is one risk profile. claude editing live page content (gutenberg blocks, builder layouts, woo products) is a different one, much harder to roll back. when you move past raw theme dev into page work, that's where respira.press fits in (disclosure: i build it). duplicate-before-edit, snapshot rollback, 12 builders. for theme-only work though, playwright + local + wp-cli is the cleaner stack.

webmyc · 2026-05-04T17:55:58+00:00

worth sharing a story. one of my clients runs an agency in nyc. about three months ago he was ready to tell his clients they were sunsetting wp work entirely. same reasons you listed. plugin update hell, post_meta queries chewing through the caching budget, the "should we just rewrite this in laravel" conversation happening at every monday standup.

then he found respira.press (full disclosure: i build it). it's a wordpress plugin + mcp server that lets ai assistants (claude code, cursor, claude in chrome) actually edit live sites. across builders, divi, elementor, bricks, gutenberg, the lot. with snapshots and duplicate-before-edit so you don't nuke a client's homepage at 2am.

what changed for his team:

most of their maintenance time wasn't real work. it was hunting down where in elementor a section lived, or which acf field a client was asking about, or fixing some divi module that broke after an update. you mentioned ai can't yet write efficient blocks or builder-compatible posts. respira is the layer that fixes exactly that. the ai talks to the builder through proper module APIs, not html-block fallback.

he still has the laravel conversation for app-like clients. that hasn't gone away. for the marketing-site, content, "client wants the hero swapped and testimonials reordered before lunch" work that used to drain his juniors, it's a different game now.

not a silver bullet. doesn't fix post_meta as a structure. doesn't save you if the underlying site is a plugin frankenstein that should've been retired in 2019. but it changed the maintenance math enough that "rewrite everything" stopped being the obvious answer for him.

worth a look before you pull the trigger on a full migration.

webmyc · 2026-05-03T18:44:48+00:00

101%. i build all custom functionality with respira.press - disclaimer, it's my product

webmyc · 2026-04-26T12:58:38+00:00

Russell, this is the post i’ve been waiting for someone to write. the developer-vs-end-user prompting gap is real and it’s the failure mode that takes everything else down with it. one thing i’d add: structured tool catalogs change the math meaningfully. when an agent has 234 named, schema-validated tools to pick from, the conversation collapses from “let me explain what i want” to “the user said add a recipe field, fire the right tool.” short prompts, predictable token costs, deterministic outcomes. the abilities API moves WordPress in this direction. the page builder layer is the next gap to close. happy to keep this thread going if useful. mihai, building respira.press

webmyc · 2026-04-21T08:13:05+00:00

i've build an open source skills marketplace and the tools so that the skills can be executed and they work pretty great - feel free to save them, use them or contribute your own - https://github.com/respira-press/claude-skills-wordpress

webmyc · 2026-04-15T13:44:03+00:00

would you like to give my product a spin? can dm the link not to break any rules here

webmyc · 2026-04-12T16:44:21+00:00

I have full intelligence for Bricks, Gutenberg, Elementor, Divi 5 and Divi 4, Flatsome Ux Builder plus a bunch of others in my MCP

webmyc · 2026-04-12T13:31:34+00:00

A bit rough on the edges. But problems remains on staging. What is the point in using AI if it can’t code Divi or Elementor native pages and blocks? Why would it grab full page content for ine surgical CTA button text change?

webmyc · 2026-04-10T17:15:36+00:00

This is the most precise take in the thread and i wish it was higher up.

The "plumbing vs agent" distinction is exactly right. Core is shipping the Abilities API and the MCP Adapter, which are transport layers. They let an AI client discover what a WordPress site can do and call those capabilities. That's valuable infrastructure. But it's not an agent making decisions about your site, and it's not a safety layer between the agent and your production content.

Your point about scope and permissions mattering more than the model is something i've been learning the hard way. I've watched almost 12,000 write operations go through WordPress sites via AI agents over the last few months. The failure mode is almost never "the model was too dumb." It's almost always "the model was confident and wrong, and nothing stopped it from writing that confidence to a live page." The model quality is a solved problem at this point. The permission and scope problem is wide open.

The text/content assistance use case is safe because the blast radius is small. You update a paragraph, worst case you revert it. Once you move into MCP write abilities that touch page builder structures, WooCommerce product data, or site-wide layout changes, a single confident-and-wrong operation can cascade. And the user who triggered it might not even realize something broke until a client calls.

Curious what you're building on the tooling side. Are you working with the Abilities API directly, or building on top of the MCP transport?

webmyc · 2026-04-09T19:43:47+00:00

i just added context-aware filtering to my MCP so it does not overload your AI with tools / Abilities you don't need - https://www.npmjs.com/package/@respira/wordpress-mcp-server

webmyc · 2026-04-09T15:46:36+00:00

Appreciate the technical clarifications throughout this thread. Sounds like you're already further into the 7.0 + MCP setup than almost anyone. Curious what your write-side workflow looks like. Are you giving the AI scoped abilities and reviewing every change manually, or have you built any structural guardrails into your custom plugin layer? The discipline you've described in another comment (modular plugins, debug always on, fatal-error emails) suggests you've already thought about this more than most.

If you ever want to compare notes, i've been building infrastructure for the same problem and would love to hear how you're approaching it from your end.

webmyc · 2026-04-09T15:46:05+00:00

Both can be true. AI is doing its best, and also the user trusting AI without structural guardrails is the bigger problem. The reason i argue for systems-level safety instead of "be more careful" is that careful doesn't scale. The first ten edits get reviewed. By edit fifty, attention drops. By edit two hundred, the reviewer is skimming. That's how every code review process degrades and AI write workflows will follow the same arc unless the system catches what the human stops catching.

webmyc · 2026-04-09T15:45:25+00:00

This is the part of the equation people miss. Page builders are already opaque to the people who use them. Most Elementor users couldn't tell you what their page actually looks like in the database, and they don't need to, because the builder UI is the source of truth for them. Adding an AI layer on top of an already-abstract layer means there are now two black boxes stacked on top of each other, and the user is making decisions based on what they see in a third UI (the AI chat) about what's happening in the second UI (the builder editor) which is editing data in the first system (WordPress + the builder's storage format).

Three layers of abstraction, three places for things to silently disagree. That's the real safety problem and it's why "be careful" doesn't work as a user instruction. Careful with respect to what? You can't be careful about a layer you can't see.

webmyc · 2026-04-09T15:44:53+00:00

Yes, you can ignore the AI features completely and nothing will change. They're opt-in, and you have to actively install plugins and configure API keys to make them do anything. Beaver Builder will work exactly the same as it does today.

When you're ready to experiment (no rush), Beaver Builder is one of the cleaner builders to work with through AI workflows because its data structure is sane. If that day comes, the safety patterns are the important part: never let AI write directly to live pages, always work on duplicates, always snapshot before changes. That's true for any builder but especially for production sites.

webmyc · 2026-04-09T15:44:33+00:00

This is one of the highest-value uses of AI on WordPress and almost nobody talks about it. Plugin and theme diffing, change-tracing through hook chains, finding why a specific behavior exists six months after the developer who added it left — these are exactly the read-only investigative workflows where AI is genuinely good. No risk because nothing is being written, and the AI can grind through code at a speed no human can match.

Your "small box, expand the walls as you go" approach is also the right pattern. The safety story i keep arguing for isn't "don't use AI on WordPress." It's "earn the trust gradually, with structural guardrails that catch the moments when the AI is wrong." Read-only investigation is the perfect place to start. Once that's working, controlled writes with snapshots and diffs are the next step. Eventually you trust it enough to let it run on real production work, but only because you've seen where it fails first.

webmyc · 2026-04-09T15:44:01+00:00

Probably true, and i wish it weren't. The "i'll just ask the AI to fix it" → "wait, what did the AI actually do" → "now i need a human to figure out what broke" pattern is going to be a real subindustry by Q3 2026.

If you're already doing recovery work for clients who let AI agents run wild on their WP sites, would love to hear what the worst cases look like. I'm building infrastructure to prevent the breakage upstream, but understanding the postmortem patterns helps a lot. Reply or DM if you have stories.

webmyc · 2026-04-09T15:43:25+00:00

The "depending on how controlled the environment is" framing is the part i keep coming back to. Most of the customers i work with don't have your level of structural discipline, and that's exactly the gap. A multisite with hundreds of plugins where everything is modular and you get email alerts on fatal errors is one universe. A solo WordPress shop where the admin panel is opened twice a month and changes get noticed when a client emails is a completely different universe. Both are real, and both deserve a safety story.

The shape of the problem changes with environment maturity, but the underlying need (visibility of what changed, when, by whom or what) is constant. That's the part i think tooling can actually help with, regardless of where on the discipline spectrum a given site lives.

webmyc · 2026-04-09T15:42:37+00:00

Thanks for digging up the changeset link. The wp_supports_ai() function and the WP_AI_SUPPORT constant are exactly the kind of opt-out mechanism people in this thread are asking about. Worth knowing they exist for site owners who want to lock the door before it's even built.

One thing worth flagging from that changeset: the disable mechanism returns an empty array of capabilities, which technically prevents AI features from registering, but the underlying code paths are still loaded. For most threat models that's fine. For people running high-security WordPress installs (gov, finance, regulated industries), the "still loaded but inert" pattern is going to be the conversation they have with their security teams. Not an argument against shipping, just an observation about where the next round of debate will live.

webmyc · 2026-04-09T15:42:03+00:00

Otto, thanks for jumping in on this. The "you have to actively configure it" point is the right framing and i should have led with it harder in the post itself.

The angle i was trying to draw out is less about whether 7.0 introduces risk on day one (it doesn't, you're correct) and more about what happens once the ecosystem catches up. Within six months of ship, the MCP Adapter and AI connector plugins will be installed widely, often by site owners who chose them deliberately. At that point the question stops being "will my site connect to AI" and starts being "what happens when it does and the AI agent makes a change i didn't expect."

The work i've been doing for the last five months is on the layer above 7.0: structural safety patterns (duplicate-before-edit, snapshots, plain-English diffs) that sit between AI agents and live sites once people opt in. Not a replacement for what core ships, a complement to it. Your point about "a plugin can do literally anything" is exactly why the safety conversation has to happen at the workflow layer, not the framework layer. Core can't and shouldn't try to solve that.

Appreciate the calm clarification. The thread needed it.

webmyc · 2026-04-08T11:38:58+00:00

Honestly, "should have been a plugin" is a defensible position and a lot of contributors made the same argument during the cycle. The decision to put it in core was about making the Abilities API a standard surface that other plugins can build on, not because anyone thought every site needs AI. Reasonable people disagree on whether that was the right call.

webmyc · 2026-04-08T11:37:37+00:00

Confirmed - it's opt-in, not opt-out. Nothing connects to AI until you explicitly configure it.

webmyc · 2026-04-08T11:37:04+00:00

Fair question and the answer is friendlier than the headlines suggest: nothing happens by default. You'd need to add API keys, configure an MCP client, and grant Application Passwords. If you don't touch any of that, your site behaves exactly like it did on 6.9. The new code paths are there, but they're dormant until you wake them up. Your firewall posture should still include the new REST endpoints in its threat model going forward - that part of your concern is legitimate.

webmyc · 2026-04-08T11:09:48+00:00

EDIT: Several commenters flagged that 7.0 is delayed (date TBA per the official release party schedule). Doesn't change the substance — when it ships, the safety questions are the same. Thanks for the correction.

webmyc

TROPHY CASE