"It does not work" here almost always means one of two things, and they are fixed differently. Either the value never reached the database, or it reached it and never reached the screen.
#The thirty second test
Save, reload the settings page, and look at the value.
Still there: the problem is in display. Cache or scope. Reverted: the problem is in saving.
#It saved, but the site does not show it
#Cache
The most common cause in this whole section. People clear one layer and stop, so here are all of them:
- a caching plugin
- your host's cache
- a CDN such as Cloudflare
- the browser cache
- an object cache such as Redis or Memcached
- generated critical CSS in optimization plugins
Open the page in a private window before clearing anything.
If it looks right there, the value saved correctly and the only remaining question is which cache layer is serving the old copy.
#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 "I changed it globally and it did not change here" is the design working, not a bug.
#You edited the wrong layer
The same visual thing can be configured in different layers, 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 a modern interface 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 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. A classic for 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
Not an administrator, or role capabilities reduced by a roles plugin. 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 repeats systematically, 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:
Current versions of Elementor and Elementor Pro. An old version with a new theme is the cheapest source of strange behavior.
Flexbox containers enabled. The theme is built on them, and some templates behave differently in the older section mode.
Experimental Elementor features off during diagnosis. They are called experimental for a reason, and they are the usual source of instability.
The Elementor cache cleared, through Elementor > Tools > Regenerate CSS & Data, and Sync Library if needed. This is a separate cache that a caching plugin's clear button does not touch.
Third party Elementor add-ons deactivated, along with plugins that modify post content. Those conflict most often.
And confirm you are editing the right thing: a theme template and a page built in Elementor are different places.
The classic editor is not a supported way to work with the theme.
It is a compatibility holdover in WordPress, and some of the theme's fields and block features are not available in it, so use the block editor or Elementor.
#Blocks
Blocks not showing a preview, or an empty settings panel, is usually stale scripts in the browser. Hard reload, then check in a private window.
#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, while a value that reverted never reached the database at all.
Only the last few settings on a long page are lost
That is max_input_vars truncating the form, since PHP silently discards fields past the cap and WordPress reports a successful save either way, so raising it to 3000 is the fix rather than saving in smaller batches.
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.
Before I open a ticket
Reproduce it with third party plugins deactivated and caches cleared, because if the symptom disappears then it is a conflict and naming the culprit in your ticket saves the entire 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 with the setting name, the screen it lives on, and the System Info report.
Last updated
