There is a specific kind of moment that makes you question your own sanity: you have proved something with a direct database query, the result is unambiguous, and the application still insists on showing you the opposite. I hit that while rebuilding a batch of marketing pages on a WordPress project using PHP scripts.
The symptom: deleted, but still there
Those pages were full of raw HTML widgets, leftovers from older work that I wanted replaced with a cleaner structure. There were too many of them to do by hand and the pattern was consistent, so I wrote a PHP script that read _elementor_data, stripped out those HTML widgets, and wrote the structure back.
The script ran without errors. I checked the data directly in the database to be sure, and it was clean: not a single HTML widget left in _elementor_data. So far, exactly according to plan.
Then I opened the page in the Elementor editor.
The old HTML widgets were still sitting there. Intact. Exactly as they had been before my script ran. And above them, Elementor was warning me about unsaved changes.
That combination is what made it confusing. If the editor had merely rendered stale content, cache would have been my first suspect. But an "unsaved changes" prompt is a different kind of signal: Elementor was not obliviously serving a stale copy, it was telling me it had another version that it considered newer than what was stored.
Why this is not the usual Elementor cache story
My first reflex pointed in the wrong direction: clear the cache. Elementor does store rendered HTML and CSS separately from the data, and that is the most common reason a live page refuses to change after you rewrite the data in PHP.
But the live page was not the problem here. The editor canvas was. And the Elementor editor does not read the render cache at all. It builds the canvas from the data, so if the data is clean, the canvas should be clean too.
Unless it is reading data from somewhere else.
The root cause: autosave wins over published data
Here is the trap. Elementor stores your in progress work as an autosave revision, and that revision carries its own copy of _elementor_data, separate from the published post. When the editor loads, Elementor prefers that autosave revision over the published data, because from its point of view that is your most recent work that never made it through Update. That preference is also why it offers the unsaved changes prompt in the first place.
Now combine that with how my script worked. My PHP wrote straight to the page's post meta. One write, one target, done. What it never touched: any autosave revision left behind by the last editing session before the script ran.
So the sequence looked like this:
- An earlier editing session left an autosave revision holding the old layout.
- My PHP script cleaned
_elementor_dataon the published post. - The editor opened, saw an autosave newer than the published data, and loaded the autosave.
- The old HTML widgets came back to life on the canvas, complete with an offer to save them.
Step four is the dangerous part. If I had absentmindedly clicked Update assuming the editor just needed a nudge, I would have written every one of those old widgets back into the database and erased my own script's work. The database was right, the editor was wrong, and the editor wins the second you press save.
The fix: end every script by deleting autosave revisions
The fix is small, and it is now the mandatory closing block in every script of mine that touches _elementor_data:
$pid = 123; // ID of the page you just rewrote
foreach ( wp_get_post_revisions( $pid, [ 'posts_per_page' => -1 ] ) as $r ) {
if ( wp_is_post_autosave( $r->ID ) ) {
wp_delete_post_revision( $r->ID );
}
}A few deliberate choices in there:
wp_is_post_autosave()as the filter. I only want the autosaves gone, not the whole revision history. That history is the safety net if the script turns out to have stripped something it should have kept. Deleting everything is faster, but it also throws away your only way back.posts_per_page => -1spelled out. I would rather not rely on a default that some other plugin might filter on a given install. If a single autosave survives, the symptom returns and you will assume the fix did not work.- Placed at the end, not the beginning. What you want to guarantee is that once the last write lands, nothing on the post looks newer than the published data. Clear the autosaves first, let the editor get opened before the script finishes, and a fresh autosave drops you right back into the same symptom.
After that, refresh the editor. Not a click around the canvas, an actual reload of the editor page.
If Elementor still complains about local changes
Sometimes even after a reload Elementor will still surface the unsaved changes prompt. If you are confident the database holds the correct version, and you have just written it there yourself, the answer is Discard.
It feels wrong. That button reads like throwing work away. In this situation what you are throwing away is a leftover of the old state, and what you are keeping is the script output you already verified in the database. The genuinely dangerous button on that screen is not Discard. It is Update.
What I took away
- When the Elementor editor canvas disagrees with the database, do not reach for cache first. Render caches explain a stale live page, not a stale editor.
- The "unsaved changes" prompt is not a minor annoyance, it is the diagnosis. It means Elementor is holding a different version and preferring it.
- Writing directly to post meta touches exactly one place. Autosave revisions carry their own copy of the data and will sit there until you delete them.
- Any PHP script that rebuilds an Elementor layout should end with an autosave cleanup. That one small block saves you a debugging session spent doubting a query result that was correct the whole time.