Divi 5 Post Emptied by the Builder — Recovery Playbook

The symptom

You (or an AI assistant) create a Divi 5 post through Royal MCP Pro — an article body, Theme Builder template, category archive layout, whatever. The post renders correctly on the frontend. You verify the markup is present by reading the post back through the MCP.

Some time later, someone opens the post in the WordPress editor or clicks Edit With Divi from the admin bar. On the next page load, the post body is empty. The frontend now renders a blank page or shows a stray <!-- wp:divi/placeholder /--> and nothing else.

The good news: WordPress writes a revision on every save. The version immediately before the empty save has your original content and is one wp_restore_revision call away.

Why it happens

Divi 5 stores layouts as WordPress blocks (<!-- wp:divi/section -->, <!-- wp:divi/row -->, etc.) with a specific per-breakpoint attribute shape. When you open a Divi 5 post in either the WordPress block editor OR the Divi builder, the editor re-parses the post body and hands it to Divi’s client-side JavaScript to re-render.

If any block in the post uses attributes Divi’s editor doesn’t recognize as its own (a rare module type, an unrecognized namespace variant, custom markup Divi didn’t originate), Divi’s re-serialization path may collapse the document down to an empty wp:divi/placeholder shell. When the user then clicks Save or Update — even without making any changes — the empty document is written back to the post.

The MCP write itself succeeded. What overwrote it was a later editor-open-and-save cycle. This is Divi editor behavior, not a Royal MCP behavior — opening any programmatically-authored Divi 5 post has the same risk regardless of what wrote it.

Recovery from revisions

Step 1: List the post’s revisions

Call wp_get_post_revisions on the affected post to list every stored revision. Newest are returned first by default.

Get the revisions of post 42 using wp_get_post_revisions.

Step 2: Identify the pre-empty revision

Look for the revision whose post_modified is just before the moment someone opened the post in the editor. That revision’s post_content is your original Divi 5 markup.

Do not sort by word_count. WordPress’s word_count uses wp_strip_all_tags + str_word_count, which cannot see text buried inside Divi 5 block attributes (content.innerContent.desktop.value). Every good Divi 5 revision reports word_count: 0. So does every empty revision. Sorting by word_count tells you nothing.

For byte-length inspection via SQL:

-- Replace wp_ with your site's table prefix if it's not the default
SELECT ID, post_modified, LENGTH(post_content) AS bytes
FROM wp_posts
WHERE post_parent = 42
  AND post_type = 'revision'
ORDER BY LENGTH(post_content) DESC
LIMIT 10;

Pick the ID with the largest byte count that predates the empty save. That’s your restore target. Or use wp_get_revision_content to fetch a specific revision’s post_content if you want to eyeball it first.

Step 3: Restore the revision

Call wp_restore_revision with the revision’s ID. WordPress copies the revision’s post_content back onto the parent post.

Restore revision 138 using wp_restore_revision.

Step 4: Verify the frontend

Reload the post’s public URL. The full Divi 5 layout should render again. If it doesn’t, the revision you restored may itself have been an empty one — step back one more revision and repeat step 3.

Correlate via the Activity Log

Royal MCP Pro’s Activity Log records every Pro tool call, including Divi writes. Divi 5 writes are marked with an amber badge in the Divi format column, making them scannable at a glance.

Enable the Divi format column

The column is hidden by default. To turn it on:

1. Navigate to Royal MCP Pro → Audit Log in your WordPress admin.
2. Click Screen Options in the top-right corner.
3. Check Divi format. Also enable Content bytes (before), Content bytes (after), and Δ bytes for context on the write’s byte impact.
4. Click Apply.

What to look for

• An amber “Divi 5” badge on the row for your MCP write — that confirms your Pro tool did author Divi 5 content into the post.
• Content bytes (after) in the several-kilobyte range on that row — the write actually landed content, not an empty shell.
• No Royal MCP row between your amber-badged write and the moment the post went empty. If the amber-badged write is the last MCP touch on the post but the post is now empty, the emptying happened outside Royal MCP — the editor-open path described above.

Prevention

Don’t open programmatically-authored Divi 5 posts in the builder

The simplest prevention: once you’ve programmatically authored a Divi 5 post, avoid opening it in the Divi builder or the WordPress editor. If you need to make edits, do them programmatically through the MCP so the content stays in a shape Divi’s re-serialization can round-trip cleanly.

Use the divi5_scaffold_block tool

Direct authoring lets you emit any block markup you want — including markup Divi’s editor won’t recognize as its own on re-open. The divi5_scaffold_block tool emits only markup that matches Divi’s own conventions, which reduces the chance of the editor collapsing on re-open. See Divi 5 Authoring for the tool reference.

Raise WordPress’s revision cap

Some hosts cap post revisions to a low number (5 or 10). If your host is one of them and you make several MCP edits to the same post over time, the pre-empty revision may already have been rotated out of the retention window. Add this to your theme’s functions.php or a site-specific plugin to raise the cap:

define( 'WP_POST_REVISIONS', 30 );

Or for unlimited (default WP behavior when not set):

define( 'WP_POST_REVISIONS', true );

Take a SiteVault backup before every publish

If SiteVault Pro or SiteVault (Free) is installed, the wp_publish_and_promote_pro composer queues a pre-flight backup automatically as its first step. That gives you a full-site restore point in addition to WordPress’s revision history. See Cross-plugin Composers for the composer reference.

Related documentation

• Divi 5 Authoring — the schema, the scaffold tool, and the reverse-engineer-by-diff method for undocumented blocks
• Undo Tokens & Reversibility — the 72-hour undo token every destructive Pro tool issues
• Universal Audit Log — every column in the Activity Log explained, including the Divi format badge
• Cross-plugin Composers — SiteVault pre-backup workflow that reduces recovery risk further
• Builder Session Detected — a different scenario where the Visual Builder is currently open on the target post