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
[Bug] Odd issue with widget and field names on reload or config change #534
Comments
The text you're seeing is the i18n key names, which are used when a language translation is missing. Can you try manually setting your language to English and see if that resolves it? You can place this line inside of your language: en-US |
Thanks for getting back to me. I just tried that in the settings and it didn't seem to make any difference. I tried setting both |
I should also note that I just tested a new instance on a standalone docker host and opened port 3000 directly in order to rule the swarm overlay network and traefik out of potential causes. It was deployed with the same configuration files and unfortunately it has the same issue(s) as before. |
Having the same issue as well. Setting |
I'm experiencing the same issue. Starting from scratch with a fresh container resolves it until I make an edit, then the fields display the i18n key names again. |
Also experiencing this issue on docker installs. Anytime a setting is applied, it displays the key names. For me, It only stops when commenting out anything in the settings that is not stock, and recreating. |
Still cannot reproduce this, its not obvious to me what might be causing it. Does anyone have anything helpful displayed in the container or browser logs? How about with log level set to |
Logging set to debug did not reveal any more info about the issue during my testing unfortunately, but. I did manage to narrow down the cause of the issue during testing today, though I'm still not sure of a possible workaround yet. In order to attempt getting some useful debug logs, I recreated the docker standalone instance with the standard compose file as follows:
With the config above, the instance proceeded to create a new set of configuration files when the page was loaded as expected. When the configuration was reloaded through the dedicated button or updated by modifying the config files, everything worked perfectly as it should, the i88n issue did not present itself. I then copied my production config files into the same location and overwrote the ones that were previously created on the first page load. As above, everything worked as it should. Finally I copied my production assets directory containing icons and images directories into
Note: The only change above is the addition of the With this config I was able to reproduce the original issue. When the container is started, all of the fields display correctly, but upon reload using the dedicated button, or on configuration change, the i88n fields were displayed instead of the appropriate values. After this discovery I suspected there was something in my I also tried with a directory structure like below with the appropriate declarations in the compose file, but it seemed to make no difference. The issue persisted.
I also tried reproducing the issue with the At this point I've managed to consistently reproduce the issue on a docker standalone instance with a locally bind-mounted config directory. I've also tried the same steps but with my nfs mounted "data" directories in use by my swarm cluster, and produced the same results as above, so that can be ruled out. I'm still uncertain of the underlying cause of the issue, or a potential workaround that doesn't involve not having a volume definition for the |
Removing I miss my icons folder tho. |
Ah, OP did not post their docker config compose / run. If that’s true for OP too then yes that’s the issue. You shouldn’t map the entire public dir, you map a subdir eg /app/public/images see https://gethomepage.dev/en/configs/settings/#background-image |
Not OP, but changing my |
Sure can add a note but I don’t think it suggests anywhere to do that so I’m not sure where the idea came from in the first place? |
Sure thing, I updated the docs. Thanks all |
Confirmed that mapping Thanks a lot for the clarification. In retrospect, failing to submit the docker-compose file as a part of the problematic config was a big oversight on my part. My apologies for any grief it caused dealing with this issue. |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new discussion for related concerns. |
Description
Issue:
I'm configuring a brand new deployment and having a problem with the fields in homepage, Screencap below.
untitled.mp4
This issue seems to occur anytime I reload the page with the dedicated reload button or if I make a change to any of the configuration files. Reloading the page, deleting the cache and reloading (Ctrl+Shift-R), closing the window and opening again, using a different browser, and opening the page on a different machine do not resolve the issue. The only thing I've found that works is recreating the container.
I've found that disabling all service widgets do not resolve the issue either. This problem occurs even after first deployment with an empty configuration directory.
On a side note, changes to the
settings.yanl
file are not being applied on first use after the container is started. The only way I've found to apply options in the settings.yaml is to use the dedicated reload button or to make a configuration change. But that also causes the issue above and is a secondary issue for me atm.Notes about environment:
The config directory is bind mounted into the container where both the app and the folder/files are using root permissions, but I have also tried with running with
user: <user>:<group>
in the compose file as well with appropriate config directory/file permissions wih no difference in behavior.The app is being reverse proxied with Traefik using the "secureHeaders" middleware
Traefik dynamic config
This is also deployed on a docker swarm cluster, though not sure if It's relevant to the issue.
Container Logs:
Note: there were no other reported errors after either using the dedicated reload button or making a config change. The errors below are present on container start.
logs/homepage.log
Configuration files:
bookmarks.yaml
docker.yaml
services.yaml
settings.yaml
widgets.yaml
Steps to reproduce
homepage version
v0.4.18 (4ea2798)
Installation method
Docker
Configuration
No response
Other
No response
The text was updated successfully, but these errors were encountered: