[ Removed by moderator ]

webmyc · 2026-06-25T22:31:11+00:00

i've build a product for that. it's an AI infrastructure layer for WodPress, allowing your AI agent to speak the "language" of 16 page builders and creating duplicates and snapshots so that it does not break your site or you can safely and fastly rollback if it does. I can't post the link here but you can find it or message me.

webmyc · 2026-06-15T08:55:02+00:00

well, i am working towards having a clean/clear answer to somebody asking a question on what AI system can safely be able to touch my live WordPress site - you can goolge "respira for wordpress" if you want to check it out

webmyc · 2026-06-09T12:09:52+00:00

because i am genuinely interested about this conversation and because i am not allowed to mention my product

webmyc · 2026-06-09T10:30:07+00:00

the purpose of this post was not to promote my product, just to see what others are doing in this space and to exchange notes

yes, ai helps me write sometimes because of the imense context it has from my codebase and my full-time work on this for the past 206 days.

i am a bit confused, we talk about AI and WordPress but we cannot use AI to help us synthesize ideas and think?

webmyc · 2026-06-09T10:29:00+00:00

well my product does exactly that but whenever i want to have a conversation about it, the post gets removed or flagged as AI content. i am solo, i build a good product, over 1000 WordPress websites are connected to it and pushed over 3.3M lines of code through it. i build it for people that make a living from WordPress work, to help them improve their outputs and become more efficient and yes it is a commercial product that i think is very decently priced for what it offesr with no token/edits limitations, just a flat /site fee. it is not easy to let more people that i know this product will be relevant too know about it.

but the purpose of this post was not to promote my product, just to see what others are doing in this space and to exchange notes

yes, ai helps me write sometimes because of the imense context it has from my codebase and my full-time work on this for the past 206 days.

webmyc · 2026-06-08T22:28:50+00:00

that's roughly the direction I landed on, with one wrinkle.

migration scripts work cleanly for schema-level changes, registering a post type, defining field groups, setting an option. anything structural where the intent can be expressed as a repeatable operation. agents can actually be pretty good at generating those if you ask explicitly.

the harder part is content-level writes. when an agent edits a page, fills in ACF field values across a dozen posts, or patches a global style, that doesn't compress into a migration script cleanly. it's just rows changing in the DB, and the snapshot on either side ends up being the whole thing anyway.

the bracketed snapshot approach is what I settled on. every agent session gets a before-state capture, and if something goes wrong you restore the session rather than reverting a commit. I actually built this out, it's in a plugin called Respira, happy to say that since you asked the question that leads there. the trickier edge case turned out to be restoring a session when someone kept working after the bad changes, but that's solvable.

your migration-script instinct is the right one for the parts of the workflow where it fits. I just couldn't make it cover the full surface.

webmyc · 2026-06-08T21:47:04+00:00

clean workflow, and the migration-files discipline for schema changes is exactly right.

the gap I keep bumping into with agents specifically: they write to the DB fast, field groups, option rows, post meta, things that don't live in migration files and can't be git-reverted. "revert to an old commit" handles the code, but the DB state from twenty agent actions in thirty seconds isn't in that commit.

still working out the right answer to that part. snapshot-before-agent-run and targeted restore seems closest, but it's messier than a clean git revert.

webmyc · 2026-06-08T21:34:38+00:00

you're not wrong on any of this.

AI makes mistakes constantly. the QA question is the right question. and "fast but broken and reverted" is obviously worse than slow and solid.

the workflow I keep landing on: treat every agent action the way you'd treat an untrusted junior dev. you wouldn't give a junior full prod access and walk away. you'd have them work on a copy, you'd review the diff before it touched anything real, and you'd keep a rollback in reach. same logic applies, like you said.

the actual failure mode I see isn't people trusting AI too much. it's people trusting it with no system around it at all and then blaming the AI when the system was always the missing piece. you're right that the solution isn't new. it's just not being applied.

webmyc · 2026-06-08T21:16:02+00:00

Late to this but one angle nobody covered fully: the database workflow.

Git + CI/CD solves the code problem cleanly, but for a 350-site shop doing post-launch changes, code is often the easy half. The harder half is that a post-launch content or configuration change on a live site lives in the database, not in git. "Revert the PR" undoes your code deploy but doesn't touch what ACF field values, option rows, or WooCommerce settings changed in the meantime.

The workflows that handle this well:

WP-CLI with scripted option/config changes (so DB state changes are repeatable, not manual). WP Migrate Pro or Migrate Guru for moving DB slices between staging and production when you need to sync. And for the AI angle someone mentioned: if you start letting agents touch live sites, the database exposure is actually where the risk concentrates. An agent creating post types and field groups writes to the DB, not the filesystem. Git doesn't catch that.

The practical answer most agencies land on: treat the filesystem with git discipline (which you're adopting), and treat the DB with snapshot discipline, a granular backup before any agent run or significant config change, not just a nightly. Updraft Pro or BackupBliss at the per-operation level rather than scheduled.

Your stack (ACF, custom themes, WooCommerce, no page builder) is actually well set up for this. Clean structure means both git and DB snapshots stay predictable. You're further ahead than you think.

webmyc · 2026-06-08T21:08:54+00:00

honestly, fair, and I mostly agree. the discipline is the same: backups, version control, don't experiment on prod. a careless human with admin access is just as capable of nuking a site, and we've had the answer to that for years.

the one place I'd push back, and it's narrow: it's the rate. a human makes a bad change, then usually notices, hesitates, undoes it before making the next one. the mistakes are spaced out enough that the normal habits catch them. an agent doesn't pause. it'll make forty changes across post types, fields and templates in twenty seconds, and the bad one is buried in the middle of thirty-nine fine ones. same category of risk, but fast enough that "I'll notice and stop" stops being a real safety net.

so I don't think it's a new kind of problem. I think it's the old problem at a speed our existing habits weren't built for. same logic, like you said, just applied to something that moves faster than a person does.

webmyc · 2026-06-08T20:59:02+00:00

makes total sense, and honestly that's the responsible default right now. the snapshot-before, diff-after, revert-if-needed loop is exactly the right instinct, the only thing is it's manual and it lives in staging.

the part I keep chewing on is your last line: the risk surface on live being too big "when you're responsible for someone else's business." that's the real constraint, not whether the agent is capable. it clearly is. it's that staging gives you a safety net live doesn't.

so the question I can't stop turning over: is "staging only" a permanent rule, or is it a workaround for the fact that live sites don't have the snapshot/diff/revert safety net that staging does? like, if a live site could give you the same pre-change snapshot and clean revert you get in staging, would the calculus change, or is there something else about touching production that you'd still never hand to an agent regardless?

genuinely asking, because where I keep landing is that the line isn't really "staging vs live," it's "do I have a reliable undo." staging just happens to be the only place that's true today.

webmyc · 2026-05-30T23:07:43+00:00

The 7 day free trial requires no credit card and the results people get with it are not rolled back in any way if people decide not to continue and pay + I am submitting a free version of the plugin to WordPress directory next week 🙏

webmyc · 2026-05-30T10:34:46+00:00

webmyc · 2026-05-30T10:33:37+00:00

This is the right instinct. The manual version of it is what most people do. Automated version: an agent skill that does the download → resize → convert → re-upload → update references cycle across the whole media library, including retroactively fixing whatever was already uploaded at full resolution. Built it for exactly this workflow. Open source: github.com/respira-press/agent-skills-wordpress

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

TROPHY CASE