TranslatePress compatibility with DIVI5

# Bug Report: Divi 5 Visual Builder fails to load post content (confirmed conflict with TranslatePress - Multilingual)

**Theme:** Divi (mixed content versions: builderVersion 4.16–4.27.4 legacy content alongside 5.0.0-public-beta.1)
**Environment:** WordPress, PHP 8.3.29 (fpm-fcgi), Apache, msphotographics.de
**Affected post:** ID 9675, "Kyoto, Nara und Osaka" (~7,940 words / 176,150 characters raw content), published, URL: https://msphotographics.de/rundreise-kyoto-nara-osaka/

## Summary

Opening this one specific post in the Divi Visual Builder (?et_fb=1) fails to render the actual article content. The builder canvas loads (the app frame reaches an interactive state, no console errors), but only shows ~1,400 characters of stray template/theme-builder text across 3 modules — not the real 7,940-word article. The front-end page and the raw database content are both fully intact and correct; only the Visual Builder fails to display/edit them.

**We have not saved, re-published, or made any changes to this post while investigating** — we're deliberately avoiding any action that could risk data loss, since manually recreating this article would take several days.

## Steps to Reproduce

1. Open <a href="https://msphotographics.de/rundreise-kyoto-nara-osaka/?et_fb=1" target="_blank" rel="noreferrer noopener">https://msphotographics.de/rundreise-kyoto-nara-osaka/?et_fb=1</a> (or via wp-admin → edit post 9675 → "Mit Divi Builder bearbeiten").
2. Wait for the Visual Builder app frame (#et-vb-app-frame) to finish loading.
3. Inspect the builder canvas: only a handful of short text modules appear, not the actual article.

## Expected Behavior

The full article renders as editable Divi modules in the Visual Builder, matching what's shown on the front-end and stored in the database.

## Actual Behavior

The builder shows only 3 text modules totaling 1,431 characters, instead of the real content.

## Technical Evidence

- Confirmed via REST API (GET /wp/v2/posts/9675?context=edit) that content.raw is 176,150 characters and fully intact — nothing has been lost at the data level.
- Parsing that raw content shows only **5 top-level Gutenberg block comments**. Nearly the entire article — all 483 legacy &#091;et_pb_...] (Divi 4) shortcodes — is embedded as a single escaped JSON string inside one wp:divi/text block's content.innerContent.desktop.value attribute. In other words, this post was never converted into native Divi 5 blocks; it's still sitting as one giant unconverted shortcode blob wrapped in a single placeholder-style block.
- **Comparison post** (ID 9003, "Chongqing in vier Tagen," similar size at 6,521 words) IS properly split into 54 individual native wp:divi/text (and related) blocks. Its Visual Builder loads correctly and shows all 33,437 characters of real content. This rules out post size/word count as the root cause — it's specific to posts still in the unconverted legacy format.
- While the Visual Builder is open on post 9675, several Divi 5 REST endpoints remain in a permanently "pending" network state and never resolve, even after 60+ seconds of waiting:
- /wp-json/divi/v1/page-manager
- /wp-json/divi/v1/dynamic-data
- /wp-json/divi/v1/module-data/blog/posts
No errors appear in the browser console.
- Server-side max_execution_time is already 600 seconds, so this is not a simple PHP timeout — the request appears to hang indefinitely rather than fail cleanly.
- We tried toggling Divi Theme Options → Builder → Advanced → "Enable Classic Editor" and "Force Enable D4 Shortcode Framework." Neither resolved the issue.

## Update: Root Cause Confirmed — TranslatePress - Multilingual

Divi Support suggested enabling Safe Mode (Divi → Support Center) to check for a plugin/theme/custom-code conflict. **In Safe Mode, the issue is resolved** — the post loads correctly in the Visual Builder. We then isolated this to a single plugin:

- First pass: deactivated all 25 active plugins one at a time (or in small batches, cross-checked individually), reactivating immediately after each test. In this first pass, deactivating TranslatePress alone appeared *not* to fix the issue — but that test was confounded by a cached redirect (see below) and turned out to be a false negative.
- Along the way we found and confirmed a real, related bug: **TranslatePress prefixes the REST API base URL with the active language slug**, even for the Divi Builder's own client-side REST calls. While the Visual Builder is open, window.wpApiSettings.root evaluates to <a href="https://msphotographics.de/de/wp-json/" target="_blank" rel="noreferrer noopener">https://msphotographics.de/de/wp-json/</a> instead of the correct <a href="https://msphotographics.de/wp-json/" target="_blank" rel="noreferrer noopener">https://msphotographics.de/wp-json/</a>. A plain GET to /wp-json/divi/v1/page-manager returns 400 (route exists, needs params) while the same request to /de/wp-json/divi/v1/page-manager returns 404 (no route registered under that prefix).
- We deployed a narrowly-scoped code snippet (active only while et_fb/et_bfb is in the query string, i.e. only during an active Builder session — never affects normal visitors) that corrected this REST-root prefixing. It worked exactly as intended (wpApiSettings.root became correct), **but the Builder still failed to load content**, so at that point it looked like TranslatePress wasn't the (sole) explanation. We reverted this snippet afterward (deactivated and trashed) — site fully back to original state, no changes retained.
- **Re-tested TranslatePress deactivation on its own, this time bypassing cache with a fresh, uncached request.** Result: with TranslatePress deactivated, the Visual Builder loads the post **completely correctly** — 85 real content modules, 81,552 characters of actual article text, instead of the previous 3 stray modules / 1,431 characters.
- **Confirmed bidirectionally, cleanly, twice:** TranslatePress deactivated → Builder loads full content. TranslatePress reactivated → Builder immediately breaks again (back to 3 modules / 1,431 characters), reproduced on demand.

**This is now a confirmed, 100%-reproducible root cause: TranslatePress - Multilingual conflicts with the Divi 5 Visual Builder for this post.** The REST-URL prefixing described above is one concrete symptom of that conflict, but evidently not the only mechanism — TranslatePress must be interfering with the Builder's content loading in at least one additional way we have not fully mapped (possibly filtering/altering the REST response body itself, not just the request URL, since fixing only the URL wasn't sufficient on its own).

TranslatePress needs to stay active for the live site (it's the multilingual setup real visitors use), so we can't just leave it off. We're not comfortable digging further into TranslatePress's internals ourselves without risking the plugin's own translation data/behavior for the rest of the site.

## Suspected Root Cause

**TranslatePress - Multilingual actively interferes with the Divi 5 Visual Builder's content-loading process for this post**, confirmed via clean bidirectional testing (see above). Why it affects this specific post and not others (e.g., comparison post 9003 loads fine either way) is likely tied to this post still being in the unconverted legacy shortcode-blob format described above (483 &#091;et_pb_...] shortcodes embedded as one JSON string in a single wp:divi/text block, rather than native Divi 5 blocks) — TranslatePress's content-filtering may specifically choke on processing/scanning that much raw shortcode text in one field, in a way it doesn't for posts already split into many small native blocks.

## Impact

The post cannot currently be edited via the Divi Builder (Visual or Backend) while TranslatePress is active. The front-end display and raw database content are unaffected — nothing has been lost — but the post is effectively locked out of the builder for editing under normal (TranslatePress-active) conditions.

## What We'd Like to Know

1. Is TranslatePress's interaction with Divi 5's Visual Builder (specifically for posts still in the unconverted legacy shortcode format) a known compatibility issue?
2. Beyond the REST-URL language-prefixing (which we found and can work around ourselves), what else might TranslatePress be doing to the page/REST responses that could stop Divi's page-manager/dynamic-data endpoints from ever resolving? Any pointers to which of TranslatePress's content-filtering hooks (gettext, output buffering, etc.) might be involved would let us build a more complete, targeted fix.
3. Is there a safer, more controllable way to trigger/complete the Divi 4→5 content migration for a single post (e.g., a WP-CLI command or admin utility) — ideally one that isn't sensitive to TranslatePress being active — that lets us inspect/back up content before and after?
4. Since we can't leave TranslatePress off permanently, is there a recommended way to edit this specific post (e.g., a temporary per-user/per-session TranslatePress bypass, similar in spirit to Divi's own Safe Mode) that would let us use the Visual Builder without disabling multilingual support for other visitors?

Happy to provide site access, further debug output, or a full content export if useful.

The page I need help with: [log in to see the link]