Divi (Divi 4 + Divi 5)
Technical documentation for using Respira with Divi 4 shortcodes and Divi 5 block-based layouts, including module-level updates.
Divi (Divi 4 + Divi 5)
This page is the technical reference. For what Respira does on Divi, how it connects to Claude and ChatGPT, and how every edit lands on a copy first, start with the Divi MCP server page.
Technical documentation for using Respira with Divi.
Divi 5 and migration support
Respira supports both Divi 4 and Divi 5 content structures so you can maintain existing layouts and prepare for migration.
- Divi 5 layouts are supported via their block-based
divi/*structure - Divi 4 layouts are supported via their shortcode-based
et_pb_*structure - Divi’s Migrator handles the actual conversion between Divi 4 and Divi 5 formats
Respira helps you plan and validate your Divi 5 migration. Divi’s Migrator performs the actual conversion.
Use these resources for Divi 5 specific workflows:
- Divi 5 builder reference
- Divi 5 Migration Copilot toolkit
- Divi 4 to Divi 5 migration guide
- Divi 5 troubleshooting
What you will learn
- How Divi 4 shortcode-based layouts map to Respira’s module model
- How Divi 5 block-based layouts differ from Divi 4 and what stays the same
- How to identify, query, and update Divi modules safely with Respira
About Divi
Divi by Elegant Themes is one of the most popular WordPress page builders with over 2 million active installations. It features a visual drag-and-drop editor with 200+ content modules.
Data structure
Divi 4 stores its builder layouts as et_pb_* shortcodes in post_content. Divi 5 uses block-based layouts where Divi modules appear as divi/* blocks in post_content. Respira works against both formats but does not perform the migration or conversion between them. A page stored as Divi 4 shortcodes keeps shortcodes on every write, whatever Divi version the site runs.
On Divi 4, Respira parses the shortcode tree with a quote-aware attribute parser and folds alias children (rows and columns) into the right nesting, so a rebuild keeps the section, row, and column structure intact.
Divi stores content as shortcodes in post_content:
[et_pb_section fb_built="1" _builder_version="4.16"]
[et_pb_row]
[et_pb_column type="4_4"]
[et_pb_text admin_label="Hero Text"]
<h1>Welcome</h1>
[/et_pb_text]
[et_pb_button admin_label="CTA" button_text="Get Started" button_url="/contact"]
[/et_pb_button]
[/et_pb_column]
[/et_pb_row]
[/et_pb_section]
Module identification
By admin label (recommended)
Set in Divi: Module Settings → Advanced → Admin Label
{ "admin_label": "Hero CTA Button" }
By path
{ "path": "sections[0].rows[0].columns[0].modules[1]" }
By type
{ "type": "et_pb_button", "match_content": "Get Started" }
Common Divi modules
| Module | Shortcode | Key Attributes |
|---|---|---|
| Text | et_pb_text | content (HTML) |
| Button | et_pb_button | button_text, button_url |
| Image | et_pb_image | src, alt, url |
| Blurb | et_pb_blurb | title, content, image |
| Code | et_pb_code | content (raw HTML/JS) |
| Accordion | et_pb_accordion | nested et_pb_accordion_item |
| Tabs | et_pb_tabs | nested et_pb_tab |
| Slider | et_pb_slider | nested et_pb_slide |
| CTA | et_pb_cta | title, button_text, button_url |
| Contact Form | et_pb_contact_form | email, title |
Example prompts for Divi
Content updates:
- "Change the hero headline to 'Welcome Home'"
- "Update all button colors to #FF5733"
- "Replace the about section image"
Structure queries:
- "Show me all sections on this page"
- "List all buttons and their text"
- "What modules are in the first row?"
Bulk updates:
- "Find all buttons with 'Learn More' and change to 'Get Started'"
- "Update the copyright year in the footer to 2025"
Global modules
A global module (in Divi 5.15, a Component) lives in the Divi Library. On Divi 5 each page that uses it stores only a reference to it, a divi/global-layout block. Respira keeps it that way: reading a Divi 5 page returns each global module as a reference, never as a copy of its content, and every write keeps the reference exactly as stored, so a global module never turns into a detached local copy. Inserts on Divi 4 pages leave global modules byte for byte as well.
To change a global module, edit the library item. The change then shows on every page that uses it.
- "Save the pricing section as a global module and place it on the About and Contact pages"
- "Add the global newsletter section from the Library to the end of this page"
Theme Builder: the live-edit confirmation handshake
Divi Theme Builder global layouts (global headers, global footers, global bodies) are written live, not staged.
They cannot be staged the way a page can. Divi resolves a global layout by id, so a staged duplicate would compete with the original instead of sitting quietly next to it. That is a property of how Divi works, and pretending otherwise would be worse than saying it plainly.
What 8.0 adds instead is a confirmation handshake:
- The first attempt to rewrite a global header, footer or body is refused with
respira_tb_live_edit_confirmation_required. - The refusal names the layout and states that the change affects every page using it.
- To proceed, re-send the same call with
confirm_live_edit=true.
This is a confirmation, not an approval. Approval means a human reviews a staged change before it exists on the live site. Confirmation means the agent is told what it is about to touch, and has to say yes on purpose. A Theme Builder global layout write goes live when confirmed.
Global layout writes are still snapshotted and reversible. If a confirmed write lands wrong, restore the snapshot from the Changes page in WordPress admin.
New in 9.2.6: insert without rewriting the page
Adding content with respira_inject_builder_content now places only the new content into the stored page. Everything else stays byte for byte, including global modules, Divi 5.15 Components and Slots, and third-party modules such as WPForms or Divi Supreme. The plugin checks that before and after the write.
There are three ways to say where the new content goes:
mode: "append"adds it after the existing content.target_pathpluspositionputs it into an existing section or column, at a 0-based index among that container's children. The path is the onerespira_extract_builder_contentorrespira_find_elementreturns, for examplesections[0].rows[0].columns[0]. On Divi 4 the target is a section or a column, not a row.after_element_idorbefore_element_idputs it next to an element, by its id (_nodeIdon Divi 5,module_idon Divi 4) or its path.
The response reports the inserted node's path and ids, the bytes inserted and the bytes left untouched.
On a page stored as Divi 4 shortcodes the new content is written as shortcodes, whatever Divi version the site runs. A Divi 5 shape and the generic shape (section, row, column, then text, heading, button and the other module names) are converted, in every insert mode. A type with no Divi 4 module is refused and nothing is written.
Chunked builds
A large page can be built as a sequence of small inserts, on Divi 4 and Divi 5:
respira_begin_sessionand keep itssession_id. Inside the session the plugin keeps one recovery snapshot of the page, taken before the first write, instead of one per chunk, andrespira_restore_sessionundoes the whole build.- Write the frame first: the sections and rows, with empty columns.
- Read the paths with
respira_extract_builder_contentorrespira_find_element. - Add each row or module with
mode: "append", atarget_path, aposition, achunk_idof your choosing and thesession_id. The answer's inserted path is the target for the next piece inside what was added. - Read the page back once at the end.
A retried call with the same chunk_id and the same content is a no-op that answers already_applied: true, never a duplicate. A failed chunk writes nothing and leaves the frame as it was.
Also in 9.2.6
- Edit links open the Visual Builder. Every edit link Respira returns for a Divi page, Divi 4 and 5, opens it in the Divi Visual Builder, and Theme Builder layouts open in the Theme Builder.
- A slow render check reports unverified, not failed. When the check after a write gets no answer in time, the write comes back with
render_validator_pass: nullandrender_validator_state: "unverified", a reason (preview_timeout,preview_unreachableorrequest_time_budget) and a note, instead of a failure. A draft, which the check cannot fetch, also reads "unverified" with the reasonnot_published. A page that answers with an error status or a fatal error still fails. - The builder name "divi5" is accepted, and "divi4" too. On a Divi 4 site a "divi5" request says so and suggests builder "divi".
Limitations
- Visual-only settings (hover states) may need Divi builder
- Per-module custom CSS is supported but complex styling may need builder
- Dynamic content tokens are preserved but not directly editable
- Theme Builder global layouts are written live behind a confirmation handshake, not staged for approval
Recent capabilities (8.0 "Canopy")
Two fixes from auditing the safety layer itself, both on the Divi path:
- A Divi 4 serializer rule stopped firing where it did not belong. The rule was written for brand-new pages, but it ran on every write path, which meant it retyped existing Code modules on pages it should only have passed through.
- Undoing a Theme Builder create no longer trashes a template the agent never created. The undo path could reach past its own work.
Recent capabilities (plugin v7.5.x)
Divi 4 stays shortcode-based, and recent work hardened that path:
- Alias children fold correctly. Row and column aliases now fold into the right nesting, so a full-page rebuild no longer drops rows or columns.
- Quote-aware attribute parser. Shortcode attribute values that contain quotes or brackets (for example a
button_textwith punctuation) parse cleanly instead of truncating the shortcode. - kses and
column_structurecorruption fixes. Content-filtering and column-width edge cases that could corrupt a saved page are fixed, so an edited Divi 4 page renders as written.