Divi content can appear correct in the Visual Builder while the live site continues showing outdated or mismatched sections when a web application firewall rejects the save request. In this case, four unclosed <iframe> tags created malformed HTML. An F5 Web Application Firewall interpreted the request as a possible code-injection attack and blocked it before it reached WordPress. Closing the iframe tags allowed Divi to save the intended content normally.
Issue background
A WordPress page built with Divi showed different content in the editor and on the live site. A section for one subject area existed in the Divi editor, but the public page displayed content from another section instead.
Because the editor appeared correct, the problem initially resembled a Divi cache issue or a failed deployment. However, repeated saves did not update the live page.
The affected page contained several embedded videos added with iframe markup.
Diagnosis
Browser developer tools showed that the Divi save request did not receive WordPress’s normal response. Instead, it returned an F5 Request Rejected page with a volt-adc server header.
The hosting logs contained no record of the save request. This confirmed that the request had been blocked at the security edge before it reached WordPress, PHP, the database, or the Divi plugin.
A review of the stored page markup identified the exact problem:
- Ten opening
<iframe>tags - Only six closing
</iframe>tags - Four unclosed iframe elements
The malformed HTML caused the WAF to interpret the Divi save payload as potentially malicious code. Because the request never reached WordPress, the database retained the previous version of the page and the live content remained unchanged.
Resolution steps
- Reproduce the mismatch. Compare the Divi editor with the live page and identify which section or module is failing to update.
- Inspect the save request. Open the browser Network panel, save the page, and review the response from the Divi save or AJAX request.
- Identify a WAF response. Look for a
403,Request Rejectedpage, security support ID, or server headers associated with F5 or another web application firewall. - Check the hosting logs. If the request does not appear in the application or PHP logs, it was likely blocked before reaching WordPress.
- Validate custom HTML. Review iframe, script, form, and embed code for missing closing tags, broken attributes, or nested elements that produce malformed markup.
- Count opening and closing tags. For repeated embeds, compare the number of
<iframeand</iframe>occurrences. The counts should match. - Correct the malformed markup. Add the missing
</iframe>tags and verify that each embedded video has a complete opening and closing element. - Test on a development copy. Save the corrected page and confirm that the WAF allows the request and the frontend displays the intended section.
- Deploy the correction. Apply the validated markup to the live page and clear relevant Divi, page, and edge caches.
- Verify the live result. Review the affected section while logged out and confirm that the editor and public page now match.
Divi’s code editor may automatically insert a closing iframe tag as new code is typed, but pasted legacy markup can still contain missing or mismatched tags. Validate all custom embed code before assuming a page-builder or caching defect.
A separate performance issue was also identified during the investigation. Divi’s cache-clearing routine could scan a large cache directory on every save and push the request beyond a 60-second timeout. This was unrelated to the WAF rejection, but clearing an oversized Divi cache can help when saves are slow rather than explicitly rejected.
Final outcome
After all four missing iframe closing tags were added, the Divi save request passed through the F5 Web Application Firewall and reached WordPress successfully. The live page then displayed the intended content and matched the editor.
No WordPress core, PHP, plugin, or hosting repair was required for the content mismatch. The failure was caused by invalid HTML triggering a security rule before the request reached the application.
The key lesson is to inspect the actual save response when Divi edits do not appear publicly. A page that looks correct inside the editor may never have been saved if a WAF rejected malformed custom markup.
For help troubleshooting Divi content mismatches, rejected WordPress save requests, or malformed iframe embeds, contact Freshy.
