[SOLVED] Misleading "Unsaved changes" message shown after API has updated an entity

I have…

  • [ ] Checked the logs and have uploaded a log file and provided a link because I found something suspicious there. Please do not post the log file in the topic because very often something important is missing.

I’m submitting a…

  • [ ] Regression (a behavior that stopped working in a new release)
  • [ x ] Bug report
  • [ ] Performance issue
  • [ ] Documentation issue or request

Current behavior

When I view an entity twice and in between the API has performed an update, Squidex suggests to overwrite old data over new data when no changes have been made. (i.e. “You have unsaved changes. Do you want to load them now?”)

Expected behavior

When I view an entity twice and in between the API has performed an update, Squidex recognises that I have not made changes that needed saving and does not suggest overwriting API changes with older versions

Minimal reproduction of the problem

  • save changes to an entity (causing an API to update the entity)
  • open the entity again
  • you should see a dialogue asking if you want to save unsaved changes


  • [ ] Self hosted with docker
  • [ ] Self hosted with IIS
  • [ ] Self hosted with other version
  • [ x ] Cloud version

Version: [VERSION]


  • [ x ] Chrome (desktop)
  • [ ] Chrome (Android)
  • [ ] Chrome (iOS)
  • [ ] Firefox
  • [ ] Safari (desktop)
  • [ ] Safari (iOS)
  • [ ] IE
  • [ ] Edge


  • the bug also occurs if I log out right after saving changes and the API perform changes while I’m logged out (i.e. when I log back in I am still asked to load “unsaved” changes that have already been saved)

Hi Beatriz,

I cannot reproduce it. Squidex stores your changes in the local store and when they differ it shows the dialog. Perhaps your change is not 100% the same as the API version?


My changes are not the same as the API version for sure. Here is a clarification of what happened:

Change #1 (by me) - affects field A, leaves field B untouched
Change #2 (by the API) - affects field B, field A kept as is
Change #3 (by me, after loading supposed “unsaved” changes) - reinstates change #1, as if it had never been saved. Change #2 is overwritten, so API changes are wiped.

It’s a pity you can’t reproduce.(Note: Your action of saving an entity should trigger API changes. You can log out immediately after saving, let the API do its changes, log back in and open that entity again)

But what are your expectations? You can load the unsaved changes and then you compare your changes with the one from this history:

Unfortunately the arrow button (2) is at the wrong place right in the Cloud and not shown like in the screenshot. This is a bug and will be fixed. But you can compare field by field where the difference is, so that you do not loose changes.

Another improvement could be that we also store the current version when saving the current content to the local store. Then we could show a more precise message.

Such as “You have unsaved changes for an previous version of the content. Do you want to load them now?”

What do you think about that?

Hi Sebastian, It seems that you’re the one doing all the changes on that entity (no API interference). API is what’s causing the version mashup on squidex.

The problem is that I get told there are unsaved changes when there aren’t. Other users of the CMS are getting induced in error and following squidex advice to load and save “unsaved” changes, and they are accidentally reinstating an older version of the entity.

I hope my screenshot explains the issue

Now I get it. After you made Change #1, the version should be removed from your local store. This does not seem to work. Therefore the wrong hint, I guess.

I think I have solved it now. But it is not deployed yet.

excellent news! thank you Sebastian. Do you have any indication when it will be deployed? (so that I relay back to my content team)

No, it can take a while because there is big improvement in the pipeline.

This topic was automatically closed after 2 days. New replies are no longer allowed.