Page BuildersDivi (Divi 4 + Divi 5)

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:

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

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

ModuleShortcodeKey Attributes
Textet_pb_textcontent (HTML)
Buttonet_pb_buttonbutton_text, button_url
Imageet_pb_imagesrc, alt, url
Blurbet_pb_blurbtitle, content, image
Codeet_pb_codecontent (raw HTML/JS)
Accordionet_pb_accordionnested et_pb_accordion_item
Tabset_pb_tabsnested et_pb_tab
Slideret_pb_slidernested et_pb_slide
CTAet_pb_ctatitle, button_text, button_url
Contact Formet_pb_contact_formemail, 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_path plus position puts it into an existing section or column, at a 0-based index among that container's children. The path is the one respira_extract_builder_content or respira_find_element returns, for example sections[0].rows[0].columns[0]. On Divi 4 the target is a section or a column, not a row.
  • after_element_id or before_element_id puts it next to an element, by its id (_nodeId on Divi 5, module_id on 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:

  1. respira_begin_session and keep its session_id. Inside the session the plugin keeps one recovery snapshot of the page, taken before the first write, instead of one per chunk, and respira_restore_session undoes the whole build.
  2. Write the frame first: the sections and rows, with empty columns.
  3. Read the paths with respira_extract_builder_content or respira_find_element.
  4. Add each row or module with mode: "append", a target_path, a position, a chunk_id of your choosing and the session_id. The answer's inserted path is the target for the next piece inside what was added.
  5. 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: null and render_validator_state: "unverified", a reason (preview_timeout, preview_unreachable or request_time_budget) and a note, instead of a failure. A draft, which the check cannot fetch, also reads "unverified" with the reason not_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_text with punctuation) parse cleanly instead of truncating the shortcode.
  • kses and column_structure corruption 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.

See also