Delete server rules button does not delete rule.
-
@girish Dan says "I will look into this after work, seems like something maybe corrupted in the config_cache table, however it will be easy to fix"
-
@girish his fix didn't work, and of course this is much more extensive than just the rules.
-
I had to roll back to the previous Pixelfed version, I couldn't leave everything unconfigured and registrations wide open.
-
@girish I told Dan this is not a one-off issue, that more people than just me are experiencing the issue. I'm going to setup a Cloudron server with one Pixelfed instance to see if I can replicate the issue with 0.12.0 that he can diagnose. If I can't replicate it with a fresh 0.12.0, it is likely related to the upgrade from 0.11.13 I'm imagining. Is there a way to start a fresh install with a specific version?
-
@girish I told Dan this is not a one-off issue, that more people than just me are experiencing the issue. I'm going to setup a Cloudron server with one Pixelfed instance to see if I can replicate the issue with 0.12.0 that he can diagnose. If I can't replicate it with a fresh 0.12.0, it is likely related to the upgrade from 0.11.13 I'm imagining. Is there a way to start a fresh install with a specific version?
@yehuda1491 yes, https://git.cloudron.io/cloudron/pixelfed-app/-/blob/master/CHANGELOG?ref_type=heads gives a mapping between package version and pixelfed version. Click on pixelfed in appstore and change the URL bar to have the right package version and then click install.
-
@yehuda1491 yes, https://git.cloudron.io/cloudron/pixelfed-app/-/blob/master/CHANGELOG?ref_type=heads gives a mapping between package version and pixelfed version. Click on pixelfed in appstore and change the URL bar to have the right package version and then click install.
@girish It does replicate on a fresh 0.12.0 install, fyi. I'll let you know what happens.
-
@girish still haven't heard from Dan.
FYI I have no idea if this is relevant, but on both v0.11.13 & v0.12.0 in env.production ENABLE_CONFIG_CACHE=true, and in v0.11.13 diagnostics ENABLE_CONFIG_CACHE is true, but in v0.12.0 diagnostics ENABLE_CONFIG_CACHE is false. -
I was following the upstream defaults here https://github.com/pixelfed/pixelfed/blob/v0.12.0/.env.docker#L70 also the app itself does not build anymore with config cache enabled. The mentioned docs link in pixelfed is also sadly outdated.
-
@girish @nebulon A person I know says they fixed the issue, but I don't know how this relates to cloudron/docker:
"Btw, I was able to get pixelfed working I had to do the setting permissions step again
cd pixelfed
sudo chown -R http:http . # change user/group to http user and http group
sudo find . -type d -exec chmod 755 {} ; # set all directories to rwx by user/group
sudo find . -type f -exec chmod 644 {} ; # set all files to rw by user/group(replace http in http:http with the user you run pixelfed as with the systemd service) then after this, i did
php artisan cache:clear
and then these
php artisan config:cache
php artisan route: cache
php artisan migrate --forcefrom the upgrade steps now it all works"
-
@dansup hi and welcome here! I am just trying the new version here. Should the
ENABLE_CACHE_CONFIG=truebe set during runtime then?@nebulon Yes, I added a fallback to handle the initial race condition before the database is configured so it will work as expected!
Let me know if you have any issues or questions, and btw, I posted from my main fediverse account with a link back to this thread in case you wanted verification that I am in fact who I say I am!
-
@dansup unfortunately the new app version seems to behave the same on Cloudron with or without the confic cache set https://git.cloudron.io/cloudron/pixelfed-app/-/commit/512f3767c3bd6a54b4992c201d979d2a7623a86e
The actual values are never stored persistently it seems, like submitting the settings form like branding will succeed status code wise, but a reload of the settings page will reveal the defaults.
