mirror of
https://github.com/BookStackApp/BookStack.git
synced 2026-05-04 18:08:46 +03:00
"php artisan bookstack:update-url" not updating application logo #3936
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @mfatfhg on GitHub (Jul 26, 2023).
Describe the Bug
Under Settings -> Customization -> Apllication Logo we updated the Application Logo.
After that, we changed the URL in our loadbalancer from https://docs.example.com to the new https://docs.example.com/bookstack
and we also changed the APP_URL= parameter to the new https://docs.example.com/bookstack
Then we started a "php artisan bookstack:update-url https://docs.example.com https://docs.example.com/bookstack" to update the URLs of attachements in the database.
We noticed that the previously uploaded Application Logo was no longer displayed after we changed the URL.
To fix this, we reuploaded the logo and its working again.
Its not that wild because the logo is very small file, but do we have an orphaned logo picture on the storage now? We is it located and how can we delete it? Not sure if a cleanup function can delete the application logo.
Edit: There is only one picture in /var/www/bookstack/public/uploads/images/system/2023-07/ so i guess we dont have a orphaned logo image file on the disk.
Steps to Reproduce
See bug description above.
Expected Behaviour
Application Logo should work after url update.
Screenshots or Additional Context
Missed to take a screenshot before we fixed it.
Browser Details
Firefox
Exact BookStack Version
23.06.2
PHP Version
8.2.1
Hosting Environment
Ubuntu 22.04 with bookstack instance installed with automatic install script like described in the documentation.
@ssddanbrown commented on GitHub (Jul 26, 2023):
Thanks for raising, but this is not something I've been able to reproduce.
From my testing this updates as expected.
We specifically target the column that stores the URL, as this was added to address the same issue raised previously in #2546.
This could of happened if you didn't run the update-url command when originally going from
http://docs.example.comtohttps://docs.example.com, since that would have left the old http URL in the database for this logo, which would have not therefore been targeted in the update to use the sub-path. The image would have likely still loaded when you went to https, even if the references was left as http.@ssddanbrown commented on GitHub (Aug 2, 2023):
Since there's been no further follow up I'll close this off assuming the above scenario took place to lead to the reported scenario.