Installing anew #fail

Once upon a time nearly ten years ago I installed Piwigo. And since then it has served … well, honestly, pretty terribly. But reasonably consistently. And across several hardware migrations.

This fall has undergone some visually dramatic changes. And I want to migrate hardware again. So I think it is time to try to migrate again but, this time, to a clean re-install.

The big problem has been – and continues to be – regular upgrades breaking the database. It is really clear the dev team are either not good at working with mysql, or they are bleading edge and screw it up by not testing on the crudest/worst maintained systems in the wild. Like, say, mine.

(IMO the install/upgrade should do a comprehensive diagnosis of the database and repair all possible errors from all possible previous versions before updating the database to the current model. For example, it appears my piwigo_user_infos is missing ‘last_visit’ field, which I think was added in version 1.5 – and the current version is 2.1)

But, enough rant.

The newest release looks like there has been a usual, cautious iteration on core, and a very uncharacteristic strong shift in UI. The UX is really not very much changed; the workflow is somewhat klunky, the plugins appear unchanged. But, trying a simple install to test whether Shotwell can upload photos, which it should be able to do, failed.

It may have been due to not being integrated with the nginx reverse proxy. Fine, I have a quick solution for that – install it via Yunohost. Yunohost automates the install and setup, but installs an older version of Piwigo. Still it should work as a test, so create a user, get Shotwell to login and…:

Invalid URL
Shotwell cannot contact your Piwigo photo library. Please verify the url you entered.

Clearly there is an error in the Piwigo publishing plugin for Shotwell, since it successfully logs in to the site. It just cannot upload.

So, maybe I can figure out another method of uploading images once they are sorted. Let us test if we can upgrade Piwigo. Oh-look-dump-the-database-to-make-sure-you-have-a-backup (of an empty site with one new user) before-updating:

<br />
<b>Fatal error</b>:  Uncaught Error: Call to undefined function mysql_select_db() in /var/www/piwigo/admin/include/mysqldump.php:75
Stack trace:
#0 /var/www/piwigo/admin/include/mysqldump.php(66): MySQLDump-&gt;setDatabase('piwigo')
#1 /var/www/piwigo/admin/include/updates.class.php(481): MySQLDump-&gt;__construct('piwigo', '/home/yunohost....', false, false)
#2 /var/www/piwigo/admin/updates_pwg.php(106): updates::dump_database(false)
#3 /var/www/piwigo/admin/updates.php(43): include('/var/www/piwigo...')
#4 /var/www/piwigo/admin.php(312): include('/var/www/piwigo...')
#5 {main}
  thrown in <b>/var/www/piwigo/admin/include/mysqldump.php</b> on line <b>75</b><br />

Yes, Piwigo fails even in doing something so simple as a no-history database dump.

At this point we run into the failings of using an integrated SSO/LDAP system like Yunohost: it never actually populates Piwigo’s user database with the administrator account’s password. Why would it? you will just be logging in via Yunohost’s interface all the time, right? That’s how single-sign-on is supposed to work, right?

Yes, but a web app often confirms the admin is the admin before performing admin tasks like altering the site configuration or upgrading. Piwigo refuses to upgrade without entering the admin’s username and password. And at that point the upgrade also cannot be canceled, locking up the site.


So, searching for a more-modern photo gallery software…