Open maticboncina opened 2 years ago
Hi I read through the issue and have not used the Custom Home Page module so not entirely sure what sort of files it modifies.
If it is like any other Laravel application I believe all of its configuration would be saved in .env (or in this image /data/config
same files).
Can you tell me what is added if anything to the .env file? If you know how to restore it, or how to trigger how it loses its settings we can build some sort of timer or switch that allows you to recreate cache/routes.
These are the entries I see in my /data/config file related to the Custom Homepage extension:
CUSTOMHOMEPAGE_DASHBOARD_PATH=amigos
CUSTOMHOMEPAGE_LOGIN_PATH=
CUSTOMHOMEPAGE_HOMEPAGE_REDIRECT="https://help.amigocloud.com/hc/1806209440"
CUSTOMHOMEPAGE_HTML="PGJyLz48YnIvPjxici8+PGRpdiBjbGFzcz0iYmFubmVyIj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8aW1nIGFsdD0iIiBzcmM9Imh0dHBzOi8vaGVscC5hbWlnb2Nsb3VkLmNvbS9pbWcvYmFubmVyLnBuZyI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgPGgzIHN0eWxlPSJ0ZXh0LWFsaWduOiBjZW50ZXI7Ij4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YSBocmVmPSJodHRwczovL2hlbHAuYW1pZ29jbG91ZC5jb20vbG9naW4iPkxvZ2luPC9hPjwvaDM+"
Thanks, and I assume that doesn't change when the custom home page stops working. How are you fixing it within the container when it stops working?
When it stops working, the login page is shown (instead of the custom homepage url), so I login and go to system settings then go to the custom homepage settings.
Once there, all the settings are as I left them, so I change the dashboard path from 'amigos' to 'amigo' and save. Everything is working then, but I just put in the wrong setting, so I change it back from 'amigo' to 'amigos' and save again. Then everything works again until the service is restarted and it 'resets' (for lack of a better word) and shows the login page instead of the custom home page. I use the custom homepage so my help desk people can go to '/amigos' to login, and my customers can see the help center documentation.
OK thanks. So this pretty much only resets after a container restart then.
Upon container restart I do a couple rewrites to the config / .env
file based on environment variables, but then issue a few commands via the included artisan
command.
Specifically one of these I figure is triggering this reset.
sudo -u "${NGINX_USER}" php artisan freescout:clear-cache
sudo -u "${NGINX_USER}" php artisan config:clear
sudo -u "${NGINX_USER}" php artisan storage:link
sudo -u "${NGINX_USER}" php artisan migrate --no-ansi
Are you able to try them one by one inside your container to see if one of them is the culprit to reset?
I'm coming up to a loss here as to why this could be happening, unless of course there is a series of files stored somewhere within the source area that we aren't correctly linking to permanently reside in the /data/
folder.
To find out if that is the case - we would want to restart the container to make it revert back to the Freescout Login page. Wait 10-15 minutes, followed by doing your configuration and then immediately after enter the container and execute:
find "${NGINX_WEBROOT}" -mmin +10 -ls
This should output a list of paths and files updated within the past 10 minutes, to then we can see if there is stray files that need to link.
I ran the commands:
[tiredofit/freescout:1.15.58 01:39:05 /www/html] $ sudo -u "${NGINX_USER}" php artisan freescout:clear-cache
The compiled services & packages files have been removed.
Cache cleared successfully.
Compiled views cleared!
Configuration cache cleared!
Configuration cached successfully!
Created: storage/app/public/js/vars.js
[tiredofit/freescout:1.15.58 01:39:14 /www/html] $ sudo -u "${NGINX_USER}" php artisan config:clear
Configuration cache cleared!
[tiredofit/freescout:1.15.58 01:39:44 /www/html] $ sudo -u "${NGINX_USER}" php artisan storage:link
The "public/storage" directory already exists.
[tiredofit/freescout:1.15.58 01:40:50 /www/html] $ sudo -u "${NGINX_USER}" php artisan migrate --no-ansi
**************************************
* Application In Production! *
**************************************
Do you really wish to run this command? (yes/no) [no]:
>
Command Cancelled!
[tiredofit/freescout:1.15.58 01:41:13 /www/html] $
After each command I checked the site to see if it was working.
After running the second command:
sudo -u "${NGINX_USER}" php artisan config:clear
The Custom Homepage Extension stops working and I need to reset the settings. So that's the command that seems to be causing the issue.
Thanks.
config
config:cache Create a cache file for faster configuration loading
config:clear Remove the configuration cache file
Something is being cached. This may have to go back to Freescout developers, but before can you try to keep going and see if we can find any changed files within the past 10 minutes after you fix it with this command ? find "${NGINX_WEBROOT}" -mmin +10 -ls
Apologies for the lack of interaction here as an author of the issue. I got back on track. I will also test this in a few days and if I find anything that wasn't already said, I will post an update. Thank you very much to both for keeping the issue and its progress alive :)
https://github.com/freescout-helpdesk/freescout/issues/2228#issuecomment-1271470784
This is a little follow-up to the convo mentioned above. A lot has been tried already.
The problem we are facing is that the custom homepage module requires settings to be resaved every so often. Only happens in the docker. Do you maybe as a creator of the image have any idea what could be wrong?
Any help is much appreciated since there are quite a few people struggling with it.