-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No "Save" Button on the Settings->Appearance page, Changes lost #3196
Comments
There should not be any save button. It autosaves. |
Except for a few. |
Could you go into your setup? This works on my machine (chrome-latestet, linux) |
Yes closing the browser fully and re-opening it. It is from a MacOS desktop system talking to a RHEL8 server running the Uptime-Kuma Docker container. On my setup (tried with multiple browsers- Brave, Firefox) and each time I make the settings change(s) under appearance (yes, I'm well aware it's supposed to autosave but it's clearly not working in some scenarios as the other settings pages- which work fine to save changes) when I close my browser fully and re-open it to log back into Uptime-Kuma the Appearance settings are always reverted back to the default settings. How are these values stored when it attempts to autosave changes on the Appearance page? |
These settings are saved to the Also, have you tried logging in with the "remember me" option? This should not matter but I wonder if it might affect how the browser works. |
Many people do not always run their browser in "normal" mode and/or simply have it configured to clear data across sessions and want to keep their system more privacy oriented...given all these factors which can affect localStorage it doesn't seem like the ideal place to store these settings? This may be relevant? https://stackoverflow.com/a/9948339 Maybe using a cookie would be the better approach as users who clear data across sessions can add an exception to allow cross-session cookies for their Uptime-Kuma server web address. While server-side access doesn't seem to be necessary, using a cookie should at least allow more flexibility and consistency across different web browsers' behaviors.
This doesn't make any difference. |
Duplicate of #1858 |
🛡️ Security Policy
Description
There is simply no "Save" button on the Settings -> Appearance page, which in my experiences leads to anything you change there (e.g. Theme, Theme - Heartbeat Bar settings) to be lost and stay stuck on the default perpetually. Assuming saving the state of these settings is sensible, I don't see why there is no way to persist these across browser sessions. Maybe this is some kind of cookie issue I'm not sure but I don't know that these setting should rely on browser session data state if users/browser settings clear data across sessions etc. I'm not sure and did not investigate the details fully but that is my hunch.
Seems there needs to be a Save button added to the bottom of this page to save and persist appearance settings changes? Or maybe this should use a cookie to save those settings?
👟 Reproduction steps
Go to Settings->Appearance and change something like the Heartbeat bar from "normal" to "bottom". Afterwards, upon closing the browser session and reopening a new session/logging back in the changes are lost and revert back to the default settings.
👀 Expected behavior
The changes you make persist across browser sessions.
😓 Actual Behavior
Changes are lost across browser sessions.
🐻 Uptime-Kuma Version
1.21.2
💻 Operating System and Arch
MacOS desktop -> RHEL 8 host system for Uptime-Kuma Docker deployment.
🌐 Browser
Firefox 102.11 ESR
🐋 Docker Version
Docker
🟩 NodeJS Version
No response
📝 Relevant log output
No response
The text was updated successfully, but these errors were encountered: