§ RELEASES · July 26, 2026

Respira 8.0 Canopy: every way WordPress builds pages

The native Site Editor joins the sixteen page builders Respira already spoke. Plus the honest part: while building it, i audited the safety envelope and found two places where the safety mechanism was the thing doing damage.

Respira 8.0 is called Canopy because it grows the platform upward: WordPress's own Site Editor is now a first-class surface. But the release i'm actually proud of is the one underneath it.

Every way WordPress builds pages

Until today, Respira spoke sixteen page builders. As of 8.0 it also speaks the native Site Editor: block themes, site templates, synced patterns, navigations and design tokens, readable and writable by any AI agent, on the same safety contract as everything else.

The storefront intelligence in the WooCommerce add-on is now FSE-first with builder fallback. On a pure block theme, analysing a shop page returns real structural analysis instead of "no page builder detected". Sale badges land inside the product image, where WooCommerce's own card puts them, and the tool refuses to add a second one if a badge is already there. It knows that by fingerprint, not by trusting its own response.

An independent researcher documented this gap precisely, three weeks ago: five storefront tools inert on builder-free stacks, sixteen builders collapsing to one. That analysis shaped this release, and the acceptance evidence ships built to his published method. His probe string does not appear in the codebase any more.

197 tools on any WordPress site, 302 with the WooCommerce add-on, every one behind the same rule: page edits stage on a duplicate, every write is snapshotted, one click back.

A live WordPress Studio homepage with an MCP-created navigation and a synced proof-bar pattern
One prompt changed the system, not a pile of pages. Respira created a native synced pattern, placed it by reference, and verified WordPress could render it.

The honest part: i found our own safety bugs

While building 8.0 i audited the envelope itself. Twice, the safety mechanism was the thing doing the damage.

A Divi serialiser rule written for brand-new pages was firing on every write path, quietly retyping existing Code modules on pages it was only meant to pass through. And undoing a Theme Builder create could trash a template the agent never created, because the rollback did not distinguish between a template it made and one it reused.

Both are fixed. Both are pinned by permanent tests. And those tests include something i have not built before: tripwires that fail when things get better. The moment the remaining gap closes, the suite breaks and forces the documentation to catch up. Humility that outlives its truth is just another kind of inaccuracy.

Respira approval drawer showing a pending native site-pattern creation and its fingerprint diff
The approval shows the resource, the operation, and the fingerprint before anything becomes live.

The gap, stated plainly

Divi Theme Builder global layouts are snapshotted and reversible, but written live. They cannot be staged the way a page is, and that is a property of Divi rather than a shortcut i took. A page edit goes to a duplicate and waits for you. Divi resolves a global layout by id, so a duplicate would compete with the original instead of standing in for it.

What 8.0 does instead is refuse to do it quietly. The first attempt to rewrite a global header, footer or body is turned down, and the refusal names the layout and says plainly that it will change every page using it. The assistant has to come back having told you that. It is a smaller promise than staging and i would rather describe it accurately than dress it up: it does not stop a bad edit, it stops a casual one, and it puts the decision in front of you while it is still a sentence rather than a broken header.

Everything page-shaped, meaning pages, posts and custom post types, keeps the full staged workflow it always had: the edit goes to a duplicate, you approve it, then it goes live.

Real staging for globals is next. i know the shape of it, and it is the piece that needs the approval machinery to learn how Divi stores things, which is more than i wanted to write on the evening before a release.

Proven, and where proof ends

The full write cycle is verified end to end on stock FSE, Twenty Twenty-Five with WooCommerce 10.9.4 on WordPress 7.0.2: staged with the live template byte-identical while queued, approved with render verification and a snapshot handle returned, rolled back to the original fingerprint. The acceptance file ships with the release, including one finding i got wrong and withdrew in place rather than deleting.

What is not yet proven: the GreenShift stack the original research ran on. That probe is pending a licence, not a harness. i would rather say so than let "verified" quietly mean "verified on something adjacent".

Respira audit log showing pattern and navigation lifecycle events from a Studio acceptance run
Dry run, proposal, create, targeted update, and every refusal. Each write links to its resource, snapshot, diff, and render result.

Getting it

Update from your Plugins screen. Structural writes to site-level objects, meaning templates, patterns and navigation, are beta-gated per site and off by default; read-only discovery works everywhere. The WooCommerce add-on goes to 4.0 alongside this, and the MCP server to 8.0. The live numbers are always at respira.press/live.

breathe easy,
mihai

Join the conversation

0 comments · Respira account

No comments yet. Be the first to weigh in.

The community · building in public

You're not the only one talking to WordPress.

The Respira community is where agency owners debug Divi migrations at 11pm, where vibe coders swap prompts that actually ship, and where the roadmap gets written out loud. Breathe with us.

Lines of code pushed through Respira
9,277,908
Live from the Respira ecosystem · updates as the agent ships