I changed host. I did a backup (full, with the include thumbnails option enabled) from the old instance (latest Discourse version).
I changed domain IP, then I Installed a new discourse instance first (classic installation with docker).
Then I copied the backup to /var/discourse/shared/standalone/backups/default and restored it from the new instance.
Everything went fine, except topics doesn’t have any messages.
Log seems fine. I can log in, everything is normal apart topics being empty.
Any idea? Where should I look if issue there is? What should I do now?
CSP setting was forced enabled upon the restoration. Some theme components were declaring script using a CDN. Those scripts were not white-listed and the topic messages would not appear because of JS errors.
More security is always welcomed, though I would not expect Discourse changing a backup setting. I can understand for new installations, but not for a backup. Because it was not just a matter of backup/restore, It did not occur to me to check the browser console at first. I have to confess I’m fairly frustrated losing a lot of time/energy/sleep for such silly issue and because of building Discourse is painfully time-consuming.
It’s good that you found the reason for the problem.
I’d consider it a bug if you restored the backup on the exact same version of Discourse. Was this the case? When you restore a backup from an older version of Discourse on a newer version of Discourse, you should expect that the system behaves differently.
Did you report the CSP problems to the authors of the theme components yet? That might at least prevent other people from experiencing the same issue.
Likely newer since we upgrade only when a new version happens and installing a new instance will grab the latest from test-passed.
Well, regardless older/newer, unless there is a very special circumstance, in my opinion existing settings should never be altered in any way. Also, from a same base version, I do want to expect my backup will have the same behavior. If anything, at least showing a warning once you are connected to Discourse (E.g: “for security reasons, CSP setting has been enabled”, you get the idea) would be welcomed (or any kind of changes).
Think about the implications of this. What you want would require an industry-wide change of direction.
Currently, what applies for an in-situ upgrade would apply when an older database is restored. That is consistent and predictable behavior for applications.
If you want no change in the settings then the normal method is to use exactly the same version of the application.
By latest, I was implying the latest release, not the latest commits from test-passed branch on github.
But yes, it’s the same base version 2.4.0.beta9.
We are talking about only backup and only settings values, nothing else. Discourse version, DB changes, whatever are irrelevant. I don’t see a single justification for changing a setting value from a backup without notifying the admin. You do customize Discourse with those specific settings, it makes no sense to change arbitrarily your settings values just because you’re restoring a backup on a newer Discourse version.
As said, if a value of a specific setting needs to be changed, I would want to expect Discourse to tell the admin what’s going on. It’s just about being transparent and making the admin life less painful. My point is you should never alter user settings unless there is a good damn reason and if so, notifying the admin about it is fine.
