How to Fix Kadence Customizer Not Saving Changes

You just spent 20 minutes tweaking your colors, fonts, and header layout in the Kadence Customizer. You hit “Publish.” And… nothing happens.

Your changes vanish. Or you get a vague “Looks like something’s gone wrong” message that tells you absolutely nothing useful.

I’ve been there. For this update I went further than troubleshooting from memory: I broke the Customizer on purpose on a test site running Kadence 1.4.5 and watched what happened. It almost always comes down to one of 5 things – from quickest fix to deepest dig. And one piece of advice you’ll find in most guides, including the first version of this one, turned out to be wrong.

Why Does the Customizer Fail to Save?

Here’s what’s happening behind the scenes. When you click “Publish” in the Customizer, your browser sends one request to your server with all your changes packed inside it. WordPress saves them into a single database row – for Kadence that row is called theme_mods_kadence – and sends back a short “success” reply that the Customizer reads.

If anything interrupts that chain – a stale cache, a plugin conflict, a server error, or junk text mixed into the reply – the save either fails with an error or fails silently. The silent failures are the worst because you think it saved, but it didn’t.

And here’s the twist I found while testing: sometimes it’s the other way round. The save works, but the reply comes back garbled, so the Customizer shows an error anyway. More on that in Fix 2.

What it’s not, usually, is a timeout from leaving the Customizer open. WordPress security tokens (nonces) stay valid for 12 to 24 hours, not minutes, and if your login itself expires, WordPress pops up a login box rather than silently losing your work. Still, if you’ve had the tab open since yesterday, refresh it before you start a long editing session.

Fix 1: Clear All Your Caches

This is the quickest thing to try, so always start here.

Old cached files – especially JavaScript files from a previous Kadence version – can conflict with the current Customizer code. Your browser thinks it already has the right files, but they’re outdated. And a cached copy of your site can make it look like your changes didn’t save when they did.

Here’s what to clear, in order:

1. Browser cache – Press Ctrl+Shift+Delete (Cmd+Shift+Delete on Mac), select “Cached images and files,” and clear it
2. Site cache – If you’re running WP Rocket, LiteSpeed Cache, W3 Total Cache, or any caching plugin, purge everything
3. Server cache – Some hosts like SiteGround, Cloudways, and Kinsta have their own caching layer. Check your hosting dashboard for a “Purge Cache” button
4. CDN cache – If you use Cloudflare or another CDN, purge that too

Now reload the Customizer and try saving. If it works, you’re done. If not, keep reading. (If you’re choosing a caching plugin, I compared WP Rocket and LiteSpeed Cache for beginners.)

Fix 2: Check for PHP Errors

A single PHP warning from any plugin on your site can break the Customizer’s save. The Customizer expects a clean reply from the server. If a plugin prints a warning onto the page at the wrong moment, that text lands in front of the reply, and the Customizer can’t read it.

I tested this exactly. I made a small test plugin print one PHP warning during the save, then clicked Publish. Here’s what the Customizer showed:

Here’s the surprising part: the change had actually saved. The server wrote it to the database and replied “success” – but the warning was stuck on the front of that reply, so the Customizer couldn’t read it and assumed it failed. So if you see this error, open your site in a new tab before you redo anything. Your work may already be there.

Warnings only end up in the reply when your site is set to display PHP errors on screen, which should never be on for a live site. The fix:

• If you turned on debugging yourself – in wp-config.php, make sure WP_DEBUG_DISPLAY is set to false (you can keep WP_DEBUG_LOG on to write errors to a log file instead)
• If you didn’t – ask your host to switch off “display errors” for your site. Most hosting panels have it as a checkbox in their PHP settings
• Then find the plugin that’s causing the warning and update it, using the conflict test in Fix 3

Quick test: Temporarily switch to a default theme like Twenty Twenty-Five (Appearance > Themes). Open the Customizer. Try saving. If it works fine with the default theme, the problem is specifically with Kadence or a plugin interaction – not your server.

Fix 3: Test for Plugin Conflicts

This is the classic WordPress troubleshooting step, and it catches more issues than you’d expect.

1. Go to Plugins > Installed Plugins
2. Tick the checkbox in the table header to select everything
3. Pick Deactivate from the Bulk actions dropdown and click Apply
4. Open the Customizer and try saving
5. If it saves, reactivate your plugins one by one, testing the Customizer after each one

The usual suspects? Security plugins (Wordfence, Sucuri), optimization plugins (Autoptimize, Perfmatters), and caching plugins. These can block or change the request the Customizer sends, or add their own output to the reply.

Once you find the culprit, check its settings for any option that filters admin requests or changes how scripts load. Or contact that plugin’s support – they’ll likely have a known fix.

Fix 4: Check Your PHP Limits

This is where I have to correct myself. The first version of this article called PHP’s max_input_vars setting “the big one” – the idea being that Kadence sends thousands of settings in one save, and a host limit of 1,000 quietly throws the rest away. You’ll find the same advice in other Kadence troubleshooting guides too.

So I tested it. I lowered max_input_vars on my test server to just 25 – far below any real host – then changed 40 Kadence settings and clicked Publish once. All 40 saved.

When I looked at the request, it contained only 9 fields, because WordPress packs every Customizer change into a single field. The limit counts fields, not settings, so it can’t touch a Customizer save.

WordPress does the same trick on the Appearance > Menus screen for the same reason. So raising max_input_vars won’t fix a Kadence Customizer problem. It can still matter for some plugins’ very large settings pages, so it’s not a useless setting – it’s just not this problem.

The limits that can matter are memory and time. A save that runs out of either stops halfway. Here’s where to check them:

1. Go to Tools > Site Health > Info
2. Click on Server
3. Find PHP memory limit and PHP time limit

As a rough guide, a memory limit of 256M and a time limit of 60 seconds or more are comfortable for a Kadence site. If yours are lower:

• Shared hosting: Contact your host’s support and ask them to raise memory_limit and max_execution_time
• cPanel hosting: Go to MultiPHP INI Editor, select your domain, and change the values
• VPS/dedicated: Change them in your php.ini file, then restart PHP

What if the Customizer Loads but Looks Broken?

If your Customizer opens to a blank white panel, shows missing sections, or controls don’t respond when you click them – that’s a different problem. It’s almost always a JavaScript conflict.

Here’s how to check:

1. Open the Customizer
2. Press F12 to open your browser’s developer tools
3. Click the Console tab
4. Look for red error messages

Common causes include an outdated plugin loading an old version of jQuery, or a minification plugin combining scripts in a way that breaks things. Update all your plugins first. If the errors persist, the plugin conflict test from Fix 3 will help you find the culprit. This same kind of JavaScript conflict can also trigger JSON response errors in the block editor, or stop the Kadence Design Library loading.

One more thing that looks like “broken” but isn’t: if you can’t find a header or footer setting, it may simply not exist yet. Kadence only shows a component’s settings once that component is placed in a row. I explained how that works in my guide to how the Kadence Customizer works.

Last Resort Options

If nothing above works, here are 2 more things to try:

Reset Kadence settings. Free Kadence has no reset button – I’ve looked, and the Appearance > Kadence dashboard doesn’t offer one. Every Customizer setting the theme owns lives in that single database row, theme_mods_kadence, and deleting it is the reset. The free Customizer Export/Import plugin lets you export a backup of your settings first. If you’re comfortable with WP-CLI, wp option delete theme_mods_kadence does the reset in one line.

Either way this wipes your customizations back to defaults, so only do it if you’re prepared to redo your design. It can fix corrupted settings that no other fix touches. If you are starting fresh, re-importing a Kadence starter template gives you a clean base to build on.

Contact Kadence support. Before you do, gather your Site Health info. Go to Tools > Site Health > Info and click Copy site info to clipboard – it copies your whole setup as text you can paste into a support ticket:

Include the exact error message you see (or describe the silent failure), and mention which fixes you’ve already tried. That saves at least one round of back-and-forth questions.

Quick Reference

Symptom	Most Likely Fix
“Looks like something’s gone wrong” error	Check whether it actually saved, then look for PHP warnings (Fix 2)
Changes revert after saving	Clear caches (Fix 1), then test plugins (Fix 3)
Save spins, then fails on a big change	Check memory and time limits (Fix 4)
Blank or broken Customizer	JavaScript conflict – see “What if the Customizer Loads but Looks Broken?”
A setting you expect is missing	The component isn’t placed in a header or footer row yet

Frequently Asked Questions

Does this only happen with Kadence or other themes too?

Cache conflicts, plugin conflicts and stray PHP warnings can happen with any WordPress theme, because they all use the same Customizer. Kadence has more Customizer settings than most themes, but as my test showed, the number of settings isn’t what breaks a save. If your old theme saved fine and Kadence doesn’t, the conflict test in Fix 3 is where I’d start.

Will I lose my Customizer settings if I switch themes to test?

No. WordPress stores theme settings separately for each theme, in a row named after it (theme_mods_kadence for Kadence). When you switch back to Kadence, all your customizations will still be there. Even deleting Kadence from Appearance > Themes doesn’t remove that row – WordPress leaves theme settings behind when a theme is deleted, so they come back if you reinstall it.

How do I know which plugin is causing the conflict?

The one-by-one reactivation test from Fix 3 is the most reliable method. But if you want a shortcut, start with security plugins (Wordfence, Sucuri), optimization plugins (Autoptimize, Perfmatters), and caching plugins. Those 3 categories are the ones that interfere with admin requests most often.

Can I edit Kadence settings without the Customizer?

Not through a second visual interface, no. Kadence keeps its header and footer builders in the Customizer in both the free and Pro versions – Pro does not move them into the block editor. What Pro adds is Kadence Elements, which lets you build a block-editor layout and hook it into a spot on the page conditionally. That sits alongside the Customizer rather than replacing it.

Everything the theme itself controls is stored in one database row, theme_mods_kadence, so a plugin like Customizer Export/Import can move those settings as a file if you need to work around a broken Customizer.

These days, when a Kadence site won’t save, I clear the caches, check whether the change actually landed, and then run the plugin test. That order has saved me hours of digging in the wrong place.