Update SPEDAS wiki to latest stable version (1.39)

[jameswilburlewis]

This will resolve some security concerns, and also enable the use of a Google Translate gadget to support automatic translation to other languages.

[jameswilburlewis]

Apparently the update needs to happen in two steps....first to 1.35, then to 1.39. I have version 1.35 installed in the public_html/wiki_debug directory. The old version is still in public_html/wiki. They are sharing the same database, which has been updated for 1.35. The old database has been backed up to both sql and xml backup files,. The old files are also backed up, but since I did it with 'cp', I suspect the permissions might have been messed with in the backup.

I had all kinds of problems getting 1.35 running....mostly "Internal Server Errors", with little other information, even after turning on all kinds of PHP debugging flags in LocalSettings.php and php.ini. The issue turned out to be permissions problems on the php files (they were group readable, need to be mode 644) and directories (again, group readable, needed to be mode 755). I had to log into spedas.org as root (not spedas!) in order to be able to see the apache2 error logs, which called out the permissions issues. Now, after correcting the permissions, it seems to be working (though the code formatting extension is disabled, until I upgrade all the way to 1.39 or 1.40).

For the second half of the upgrade, I'll take another pair of database backups, and try the tarball rather than the zip file for the mediawiki file installation, and also for backing up the existing files. At least I know now to watch the apache2 logs to diagnose any mysterious problems that come up.

[jameswilburlewis]

I couldn't get version 1.39 working properly. The "vector" skin wasn't being applied -- the page contents showed, I could log in, navigate around, etc., but the logo was missing and the styles weren't being applied. No errors showing in the Apache logs, nor any obvious PHP errors in the debug log. There might be some oddity in Hostgator's Apache or PHP config that needs special .htaccess magic or changes to PHP defaults for this version to work.

I've restored the database and wiki files from backups, so we're back at version 1.34 until I can figure out how to do a clean upgrade. Maybe we're better off migrating spedas.org to SSL servers, then trying to upgrade the wiki without any hostgator/cpanel stuff getting in the way.

[jameswilburlewis]

OK, trying this again with a bit more caution. I've cloned the production database and site files to spedas.org/wiki_dev, so if I screw something up, it won't affect the production site. Notes from last attempt: pay close attention to file & directory permissions, don't copy the skins directory from the pre-upgrade version; may have to rebuild the localization cache (using maintenance/rebuildLocalizationCache.php), check error_log in the wiki directory if problems occur, pay closer attention to release notes and upgrade instructions (e.g. specifying the logo in LocalSettings.php is done differently in later versions).

[jameswilburlewis]

More updates notes: Untar the new files with "tar xvf mediawiki-X.XX.XX.tar" right in public_html, then 'mv' to the target directory. There are some weird permissions if you use "tar xvfp", that resulted in empty directories when I did "cp -R" to install it in public_html. It might be necessary to "chmod 755" the top level directory, but I didn't have to mess with any permissions other than that.

[jameswilburlewis]

New way of specifying the logo file in 1.35 and later....instead of setting $wgLogo, you can now set $wgLogos, a map which can specify 1x, 2x, svg, or wordmark versions of the logo. We're just using 1x for now.

## The relative URL path to the logo.  Make sure you change this from the default,
## or else you'll overwrite your logo when you upgrade!
#$wgLogo             = "$wgScriptPath/images/2/29/Wiki_logo_draft.jpg";
$wgLogos = [ '1x' => "$wgScriptPath/images/2/29/Wiki_logo_draft.jpg" ];

[jameswilburlewis]

I figured out why some of my attempts didn't work: I had been getting errors because some PHP files were group writeable. I tried to fix this with something like find . -name \*.php -exec chmod 644 {} \; (i.e. change all PHP files in the entire directory tree to mode 644). Annoyingly, there's a directory called less.php -- if you change it to mode 644 (instead of 755), it breaks the site.

[jameswilburlewis]

Upgrade complete! We are now at mediawiki version 1.40.2, the latest stable version, and everything appears to be in working order. The current state of the files & database are backed up in ~/wiki_backups.

Going forward: There's now a development version of the wiki site, so we can try making changes without worrying about breaking the production site. It's in the wiki_dev directory, and it has its own database spedas_wiki_dev (mysql user spedas_wikidev), so it's completely isolated from the production site.