Most of the time this is a cache, and the value you think did not save is sitting in the database exactly as you left it.
The other cases are a real save failure. The two are fixed in completely different places, so the first thing to do is tell them apart.
#The thirty second test
Save, reload the settings page, and look at the value.
Still there: it saved. Something between the database and your screen is showing you an old copy, and the cache section below is the one to read.
Reverted: it did not save. Skip to "It does not save".
#It saved, but the site does not show it
#Cache, almost always
A WordPress site can have six caches stacked on top of each other, and clearing only one of them is what makes people think the problem is somewhere else. Clear all of them:
- a caching plugin
- your host's cache, which is separate from the plugin's
- a CDN such as Cloudflare
- your browser cache
- an object cache such as Redis or Memcached
- generated critical CSS in an optimization plugin
Open the page in a private window first, before clearing anything.
A private window has no browser cache and no login, so it sees roughly what a visitor sees. If the page looks right there, the value saved, and the only question left is which layer is holding the old copy.
You can also send the link to somebody on a different network and ask what they see. If both of you see the same stale page, it is a cache. If only you see it, it is often just your own browser.
#The scope of the value
Some settings exist at several levels: globally, per post type, and locally on one post or page. Local beats global.
So when a global change does not show on one page, that page most likely has its own local value, and the design is working as intended.
#You edited the wrong layer
The same visual thing can be configured in more than one place, and editing one does not affect the other. A page built in Elementor does not listen to the theme settings for that zone.
#It does not save
- The REST API is blocked
The settings panel is built on the WordPress REST API. If a security plugin, a host firewall, ModSecurity, HTTP authentication on the API path, or a "disable REST API" plugin closes it, the panel either fails to load or silently fails to save. Check this first. Diagnostics, in the Pro plugin, has a dedicated check for it.
- Large forms are truncated
The server's
max_input_varslimit silently discards fields beyond the cap, so part of the form saves and the last few changes vanish. This happens to any theme with a lot of settings.- A database problem
If nothing saves at all, including standard WordPress settings, this is not the theme. A database quota reached, a database in read only mode, or a damaged options table. Your host diagnoses and fixes those.
- Insufficient permissions
You are not an administrator, or a roles plugin has reduced role capabilities. The sign: some settings pages do not open at all.
- An expired session
"Are you sure you want to do this?", or a silent failure after a long editing session with the tab open. Sign in again and retry. If it keeps happening, a page cache is caching your admin.
- A JavaScript error
A blank page, a permanent spinner, a button that does not react. Open the browser console. If the error names a third party plugin, you have found it. Ad blockers and strict browser security policies belong in this group too.
#Elementor specifically
Six things, in the order worth checking them.
Update Elementor and Elementor Pro
An old version against a new theme is the cheapest source of strange behavior to rule out, and it costs one click.
Turn flexbox containers on
The theme is built on them, and some templates behave differently in the older section mode.
Turn experimental features off while you diagnose
Experimental features are the usual source of instability.
Clear the Elementor cache
Go to ElementorToolsRegenerate CSS & Data, and run Sync Library too if the library looks wrong. This is a separate cache that a caching plugin's clear button does not touch.
Deactivate third party Elementor add-ons
Deactivate any plugin that modifies post content along with them. This group conflicts more than any other.
Confirm you are editing the right thing
A theme template and a page built in Elementor are different places, and a change in one is invisible in the other.
#Blocks
A block that shows no preview, or an empty block settings panel, usually means stale scripts in the browser. Hard reload, then check in a private window.
#Custom setups narrow what anyone can answer
This changes what a support ticket can do for you.
We can answer for a site where our theme, the Pro plugin and the integrations are doing the work they were written for. The further a site gets from that, the less anybody can say about it with confidence. Custom post types added by another plugin, content generated by a third party builder, a roles plugin rewriting capabilities, a heavily modified admin: each of those is code we did not write, sitting in the same request as the save that failed.
We still help, as far as the evidence reaches. A ticket that says "it also fails with every other plugin deactivated" is one we can act on, and a save failure inside somebody else's custom post type usually belongs with whoever wrote that plugin. Our Support Policy sets out the same line formally.
#Before you open a ticket
The theme is rarely the cause here, and the reason is worth knowing. Saving in WordPress is core's own job: the options table, the REST API, the nonce, the user's capabilities. A theme supplies the fields and reads them back. It sits a long way from the code that writes the row, so a theme bug in this area is the last thing to suspect, not the first.
So the useful order is: private window, clear every cache layer, deactivate third party plugins, run Diagnostics. If the symptom survives all four, you have something worth reporting, and a ticket that can be answered in one reply instead of ten.
#Common questions
How do I tell a cache problem from a save problem?
Save, reload the settings screen and look at the field. A value that is still there saved correctly, and the problem is on the way to the page. A value that reverted never reached the database.
Does the classic editor work with the theme?
Not as a supported way to build pages. Several of the theme's fields and block features are not available inside it, so a setting that appears to be missing there often is. Use the block editor, or Elementor where the theme supports it.
Only the last few settings on a long page are lost
That is max_input_vars truncating the form. PHP silently discards fields past the cap, and WordPress reports a successful save either way. Raise the limit to 3000 or more; saving in smaller batches only works around it.
It looks wrong to me but right to everyone else
That is your own browser or your admin session, not the site. Hard reload, then try a private window, then a different device. Nothing needs fixing on the server.
Nothing saves anywhere, including the WordPress settings
Then it is not the theme. A full database, a read only database or a damaged options table all produce exactly this, and they are your host's to diagnose.
What should the ticket include?
First reproduce the problem with third party plugins deactivated and caches cleared. If the symptom disappears, it is a conflict, and naming the plugin in your ticket saves most of the investigation.
Include the setting name, where it lives, what you expected, what you see, and the System Info report.
#Still stuck
Open a support ticket and say what you tried and where it stopped. Your product, your domain, a screenshot and the exact message you saw are usually enough to settle it in one reply.
Last updated
