Flatsome fix
UX Builder Not Loading, Blank or Not Saving on Flatsome?
UX Builder is an application inside your dashboard that loads the live page in a frame and edits it there. When it sticks on the loader, shows a blank panel or will not save, the published page is almost always fine. What failed is one of the connections between the builder, the frame and the server, and each leaves a different clue.
- Navigated to /wp-admin/post.php?post=128&app=uxbuilder
- ux-builder: requesting preview frame
- Mixed Content: requested an insecure frame 'http://store.test/'
- This request has been blocked; content must be served over HTTPS
- ux-builder: still waiting for preview frame
What you are seeing
- Edit with UX Builder opens a loading screen that never finishes
- The builder's sidebar appears but the page preview stays white
- Pressing Update spins, then nothing is saved
- The builder works on most pages and fails on one long one
- The UX Builder button is missing on a custom post type
Why it happens on Flatsome
Most common first.
- 1
The site's two addresses disagree
UX Builder runs under the dashboard's address and loads the page from the site's address. If one is saved as http and the other as https, or one has www and the other does not, the browser treats the preview as a different site and will not let the builder reach into it. This is the classic result of an SSL certificate added after launch.
- 2
An optimization layer rewriting the builder's scripts
Minify, combine and defer features in caching plugins reorder JavaScript, and so does Cloudflare's Rocket Loader. UX Builder needs its scripts to arrive in sequence for a logged-in user. One reordered file and the loader spins indefinitely with an error in the console.
- 3
Flatsome is older than the WordPress beneath it
WordPress updates itself. A Flatsome that was never registered does not. When WordPress changes the script libraries it ships, an old copy of UX Builder can fail to start. If the builder died the day after a WordPress update, suspect this first.
- 4
A firewall or server limit rejecting the save
UX Builder sends the whole page back to the server as one request full of shortcodes and markup. Host firewalls sometimes read that as an attack and answer with a 403, and tight PHP limits can cut a long page short. In both cases the builder opens normally and fails only when you press Update.
- 5
Something else answering in the preview frame
Security plugins and some hosts send a header that forbids the site from being shown inside a frame at all. Maintenance-mode and login-redirect plugins can hand the frame a holding page in place of the one you asked for. The builder waits for a page that never identifies itself.
How to fix it, in order
Least invasive first. Stop at the step that fixes it.
- 1
Confirm the live page works, then back up
Load the page in a private browser window. If it displays normally, your content is intact and you are repairing the editor only. Take a backup anyway before changing any settings.
- 2
Match the two addresses
Go to Settings, General and compare WordPress Address with Site Address. Make both of them https, and make them agree on www. If the fields are grayed out, the values are set in wp-config.php and must be changed there. Log out, log in again at the corrected address and reopen the builder.
- 3
Watch the console while the builder loads
Open UX Builder, press F12 and choose Console. A mixed content or blocked frame message confirms an address or header problem. An error naming a file under /wp-content/plugins/ names your conflict. An error inside Flatsome's own files on an old version points to the update.
- 4
Switch off script optimization for logged-in users
In your caching plugin, turn off minify, combine and defer for logged-in users, or exclude wp-admin, then purge. If the site runs through Cloudflare, disable Rocket Loader in its speed settings and test again. Turn features back on one at a time so you learn which one it was.
- 5
Hunt the conflict on a staging copy
On staging, deactivate every plugin except WooCommerce and reload the builder. If it opens, reactivate the plugins in halves until it stops. Security, maintenance-mode and script-manager plugins are the usual finds.
- 6
Update Flatsome, then look at the server
Bring Flatsome current on staging. An unregistered theme has to be registered first. If only saving fails, open the Network tab, press Update and find the request that fails. A 403 means the host's firewall needs a rule relaxed. A long page that will not save at all is a reason to ask the host about PHP memory and post size limits.
Keep it from coming back
- Keep Flatsome registered so the builder is updated along with WordPress
- Exclude wp-admin and logged-in users from minify, defer and Rocket Loader
- Open UX Builder on staging after each WordPress or plugin update, before you need it
- Move repeated sections into UX Blocks so no single page save carries everything
The permanent fix
A faster Next.js build, with a CMS made for your business
If UX Builder breaks each time something else updates, count what sits between you and a simple text change: WordPress, the theme, the builder and every plugin that touches scripts. A Next.js build with a custom CMS removes that chain. The editor becomes a set of fields for the things you actually change, with no builder to fall out of step.
| On Flatsome today | On Next.js with a custom CMS | |
|---|---|---|
| What you keep updated | WordPress, the theme, its builder and every bundled plugin, all in step | Nothing on a schedule. There is no theme or plugin stack to fall out of step |
| How a page is served | Built from the database on each visit, through the theme and its builder | Built ahead of time and served as finished files from servers near the visitor |
| How you edit it | A general-purpose builder with every option the theme ships | A CMS built around what your business actually changes: services, prices, photos, posts |
| What can break it | An update to any one of those parts, or a license that lapses | A change someone makes on purpose, tested before it goes live |
Your content, your addresses and your rankings come with you: every page is moved, every old address is redirected, and you get a login to an editor that only shows what you need. A repair is still the right call for many sites, and we will say so when it is.
Want this fixed on your Flatsome site?
Tell us what you are seeing. We look at the site, tell you plainly what is wrong and what it takes, and quote a fixed price before any work starts.
Which of these sounds like you? (pick any)
Frequently asked
No. The page is stored in the database as shortcodes and keeps displaying to visitors. You can confirm it by opening the page in the standard editor's text or code view, where the shortcodes are visible. Resist the urge to retype anything there. Fix the builder.
Loading and saving are different requests. Saving sends the full page to the server, and that is where a host firewall, an expired login session or a PHP limit steps in. Open the Network tab, press Update and read the status of the request that fails. A 403 is a firewall, a login prompt is a session and a 500 is a server error with details in the PHP log.
UX Builder is switched on for pages, UX Blocks and the other content types Flatsome registers itself. A custom post type added by a plugin has to be registered with the builder, which takes a short call to add_ux_builder_post_type in a child theme. Until then that content opens in the standard editor only.
For a small text change, yes. Open the page in the standard editor's text or code view and change the words between the shortcode tags, leaving every bracket alone. For anything structural, wait. One missing closing tag in a hand-edited shortcode makes a layout fault that takes longer to find than the original problem.
Keep reading
- ServiceFixing WordPress PluginsOne bad plugin can take your whole site down. We fix plugin conflicts, fatal errors, and security holes fast — and build custom plugins when the off-the-shelf ones fall short.
- ServiceForms & Scripts Not WorkingA form that quietly fails is the most expensive bug on a website — you never see the leads you lost. We fix it, then prove the message arrives.
- ServiceFixing Broken WebsitesSite down, hacked, or falling apart? We diagnose it fast, fix what's broken, and tell you straight how to keep it from happening again.