Skip to content

Visual Editor Blank or Broken

The visual editor loads your site page inside a frame alongside the translation sidebar. When something goes wrong, it’s almost always one of a small number of causes. Open your browser’s developer tools (press F12) before you start — the Console and Network tabs will often point directly to the problem.


Before going through the full diagnostic steps, run through this list:

  1. Is the Omnalingo plugin active? (wp-admin → Plugins)
  2. Are you logged in as an administrator?
  3. Are you using a modern browser (Chrome, Firefox, Edge, or Safari)?
  4. Does the page load normally on the frontend (without the editor)?

If the page doesn’t load normally on the frontend either, the issue is with the page itself, not the editor.


Symptom: editor shows a blank white or grey page

Section titled “Symptom: editor shows a blank white or grey page”

Check 1 — The page hasn’t been scanned yet

Section titled “Check 1 — The page hasn’t been scanned yet”

The visual editor needs to know about the page before it can load it. If you opened the editor for a page that’s never been scanned or gathered, it may not load.

Fix: Go to the Omnalingo dashboard, find the page, and run a scan on it. After scanning, open the editor again.


Check 2 — A security plugin or firewall is blocking the editor

Section titled “Check 2 — A security plugin or firewall is blocking the editor”

Some security plugins or hosting firewalls block requests that look unusual — and the editor’s frame-loading request can trigger these filters.

To check:

  1. Open the editor.
  2. Press F12 to open developer tools.
  3. Go to the Network tab.
  4. Look for any requests that return a 403 (Forbidden) or 503 status.

If you see blocked requests, check your security plugin’s settings (Wordfence, iThemes Security, Sucuri, etc.) and whitelist the Omnalingo editor URL pattern, or temporarily disable the security plugin to confirm it’s the cause.


Symptom: editor shows a login screen inside the frame

Section titled “Symptom: editor shows a login screen inside the frame”

Check 3 — Your session isn’t carrying into the editor frame

Section titled “Check 3 — Your session isn’t carrying into the editor frame”

The editor frame loads your site page. If WordPress isn’t recognising your logged-in session inside that frame, it shows a login page instead.

Common causes:

  • A security plugin is blocking cookies in certain contexts
  • Your site uses HTTP in some places and HTTPS in others (mixed protocol), which can prevent session cookies from being shared
  • A custom login redirect plugin is intercepting the request

To check: Open developer tools → Network tab → click the frame’s page request and look at the response. If it’s a redirect (302) to your login page, the session isn’t being recognised.

Fix: Ensure your entire site uses HTTPS consistently. Check your WordPress address and Site address in wp-admin → Settings → General — both should use https://. If you have a redirect plugin, check whether it’s interfering with editor requests.


Check 4 — Mixed HTTP/HTTPS (protocol mismatch)

Section titled “Check 4 — Mixed HTTP/HTTPS (protocol mismatch)”

The editor sidebar and the page frame communicate through the browser’s messaging system. If the sidebar is loaded over HTTPS and the frame is loaded over HTTP (or vice versa), the browser blocks these messages as a security measure.

To check: Open developer tools → Console tab. Look for errors mentioning “origin” or “blocked message.”

Fix: Make sure your entire site consistently uses HTTPS. Update your WordPress address settings in wp-admin → Settings → General to use https:// for both fields.


Check 5 — A security header is blocking the frame

Section titled “Check 5 — A security header is blocking the frame”

Some hosting control panels or security plugins add headers that prevent pages from being loaded inside frames. The most common ones are X-Frame-Options: DENY and Content-Security-Policy: frame-ancestors 'none'.

To check:

  1. Open developer tools → Network tab.
  2. Click the frame’s page request.
  3. Look in Response Headers for X-Frame-Options or Content-Security-Policy.

If these headers are set to deny framing, contact your hosting provider or check your security plugin settings to allow same-site framing.


Symptom: JavaScript error in the browser console

Section titled “Symptom: JavaScript error in the browser console”

Open developer tools → Console tab and look for red error messages. Common things to look for:

  • “Cannot read properties of undefined” or “Uncaught ReferenceError” — usually means a plugin conflict is interfering with Omnalingo’s JavaScript.
  • Errors pointing to other plugin files — deactivate plugins one by one (starting with recently added ones) to find which plugin is causing the conflict. Reactivate each one after testing.

Symptom: “Page not found” inside the editor frame

Section titled “Symptom: “Page not found” inside the editor frame”

WooCommerce’s Shop, Cart, and Checkout pages sometimes need extra configuration for the editor to load them correctly. Make sure these pages are properly assigned in wp-admin → WooCommerce → Settings → Pages (or the equivalent WooCommerce screen). If the Shop page is not set or the page doesn’t exist, the editor can’t load it.


If none of the above steps identify the problem, open the editor in a different browser. This rules out browser extension interference, browser-specific cache issues, or local browser settings that might be blocking frame content.