I noticed several issues regarding Mediawiki during the upgrade from Bullseye to Bookworm on one of my FreedomBoxes. The FreedomBox has a Mediawiki installation that was upgraded from version 1.35.8 to 1.39.2; the upgrade also advanced the PHP version from 7.4.33 (fpm-fcgi) to 8.2.5 (fpm-fcgi), SQLite from 3.34.1 to 3.40.1, and ICU 67.1 to 72.1.
Need to run php update.php
I dug into these version details because following the upgrade, the Main Page displayed an ominous “There is currently no text in this page”. After reading some Mediawiki documentation regarding upgrades, I saw that the process requires running an update script: php update.php. In my case, this was # php /var/lib/mediawiki/maintenance/update.php. Running the script started a process that reported various modifications took place involving table stuff. For me, the process took 1m26s and resulted, as far as a I can tell, all pages being restored.
Mediawiki:Sidebar not updating
There is an issue with my MediaWiki:Sidebar content not being displayed. I fixed the issue after a peek at this forum thread, which suggested simply making an edit to the MediaWiki:Sidebar page; this seems to force a cache update; the upgraded Mediawiki instance seems to have cached the default sidebar that temporarily existed prior to running php update.php as described earlier. I believe this issue may have resolved itself after some cache time limit expired.
Extension updates
If you installed any custom extensions by manually copying a downloaded archive’s contents into the /var/lib/extensions/ directory, a new archive containing an updated version of the extension appropriate to Mediawiki 1.39.2 will need to be downloaded. You can see which extension versions are loaded at Special:Version. There’s a tool called composer that appears to automatically update default extensions, but I haven’t explored using it for custom extensions.
Backup
It’s probably a bit too late for you if you’re here because the Bullseye to Bookworm upgrade already happened, but these details are fresh in my mind as I’ve been working through Mediawiki details, so I thought I’d include them here.
If you want to make or restore backups, you should read the official Mediawiki documentation about backing up a wiki and restoring a wiki. If your wiki is simple enough (no images), you can probably get away with just exporting the wikicode of pages via Special:Export.
Note that FreedomBox uses an sqlite3 database instead of the default MySQL/MariaDB database; although this doesn’t affect most php maintenance scripts (e.g. the aforementioned update.sh is run regardless of database type), it does mean you won’t be using mysqldump but instead SqliteMaintenance.php to create a backup file. For me, the command was # php /var/lib/mediawiki/maintenance/SqliteMaintenance.php --backup-to $HOME/20230611..mw_backup. I’m fairly certain that FreedomBox didn’t perform such a Mediawiki-specific backup command. It’s also unclear to me what exactly the Backup settings on the Plinth Settings page save.
That said, since a database backup does not include images (i.e. the content of /var/lib/mediawiki/images/) or configuration files (e.g. the target of the /var/lib/mediawiki/LocalSettings.php symbolic link), commands such as the following can save such Mediawiki data from a Freedombox installation. Some care will need to be taken to make sure file owner and groups are properly restored if they’re imported into a new operation system:
# dirBackup="$HOME/20230611..mw_backup_files"
# mkdir "$dirBackup";
# cd "$dirBackup"
# rsync -avu --progress /var/lib/mediawiki/ ./var/lib/mediawiki/
# rsync -avu --progress /usr/share/mediawiki/ ./usr/share/mediawiki/
# rsync -avu --progress /etc/mediawiki/ ./etc/mediawiki/
# rsync -avu --progress /var/lib/mediawiki/mediawiki-db/ ./mediawiki-db/
# ls -alhR . > 20230611..mw_backup_files.txt
# php /var/lib/mediawiki/maintenance/SqliteMaintenance.php --backup-to ./sqlite3_db
In this example, the image files should be backed up to: $HOME/20230611..mw_backup_files/var/lib/mediawiki/images/. I’ve included directories such as /usr/share/mediawiki/ and /etc/mediawiki since FreedomBox uses symbolic links to reference them; ideally they shouldn’t need to be backed up, but I’ve made some changes here and there (e.g. sourcing /etc/mediawiki/mySettings.php files from LocalSettings.php via a line resembling:
include dirname(__FILE__)."/mySettings.php";
If I run into any further issues, I’ll post them here.
edit(2023-06-13T19:31+00): Added extension to ls command to clarify you’re saving a file list, not doing anything to the $dirBackup directory itself.