mirror of
https://github.com/Piwigo/Piwigo.git
synced 2026-11-03 07:22:22 +01:00
Couldn't access web interface after update #2144
Assignees
adam (Adam Wojcieszonek)
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: adam/Piwigo#2144
Reference in new issue
Block a user
Hello,
I just updated my installation, and now I couldn't access the web page of the application.
I've got the following error:
Piwigo-db logs:
Did you have the same problem with the officiel Docker image ? https://hub.docker.com/r/piwigo/piwigo
Thanks for the feedback, indeed it resolved the UI issue.
But now, the system couldn't read my datastore. The db seems OK.
It doesn't read any photo.
Check Upload plugin output (1 line)
Thanks in advance if you've got any idea.
Ok nevermind.
I managed to get access to the photos after changing the PATH to the photos, according to the last update requirements as I read.
New bind
/mnt/nas/Photos | /var/www/html/piwigoI have the same issue as the original. Using the Docker variant isn't really an option for me and besides, I'd prefer actually fixing the error (even if it's local) rather than just ignoring it by switching the stack.
I don't think the original problem is fixed by the PATH update so I guess the issue could be reopened. In any case I'd be interested in how to fix this properly here.
This issue comes from the LinuxServer.io image, not from Piwigo.
Their container heavily modifies Piwigo’s normal structure (moving folders, creating /config and /gallery, adding symlinks, etc.). Because of this, the environment is not comparable to a standard Piwigo installation nor to the official Piwigo Docker image.
We can’t debug or support issues caused by third-party images, so we won’t reopen the issue.
If you want to confirm whether it’s an actual Piwigo bug, please test again with the official Docker image, which follows the standard filesystem and behaves like a normal installation.
Ah. My Piwigo installation comes straight from the Github repository (it's actually a
git cloneset to the 16.1.0 tag).But your comment made me look deeper: the
modustheme itself is installed separately (again from the Github source) and thus needs to be kept in sync, which was the problem here.So no need to reopen the bug but in case someone else has the same problem as me: remember to update the modus theme after upgrading to 16.x
Yes, you found the root cause.
That’s exactly why we strongly recommend managing your themes and plugins from Piwigo’s own administration interface. It automatically pulls extensions from
piwigo.org/ext, selecting the version that is compatible with your Piwigo release.When installing themes/plugins directly from GitHub, you always risk version mismatches. In your case you were lucky: the current master branch of Modus happens to be compatible with Piwigo 16.1, but that’s not guaranteed, and there can easily be a gap between GitHub and the official release.
Using the built-in extension manager avoids these problems completely.
I understand that but (sorry for the off-topic) my server doesn't have outgoing internet access so the extension manager can't check for updates (it could maybe check for locally installed versions and warn about incompatibilities).
Oh, I see. In your situation you can still browse
piwigo.org/extmanually to check compatibility.For example:
https://piwigo.org/ext/index.php?eid=972shows “Compatible with Piwigo 16, 15”.Once you’ve verified the correct version, you can download the revision and upload it directly into your Piwigo
plugins(orthemes) folder via SSH or any other method.