Mediawiki update odyssey
So I had this wiki running mediawiki (MW) v1.20 and semantic mediawiki (SMW) v1.8. As MW was getting end-of-life, I wanted to update to latest v1.22.
Usually this means :
- download new archive of the MW software, unpack
- get updates of installed extensions
- for SMW there’s the so-called SMW bundle, an archive of all relevant SMW extensions, in a consistent version state
- run MW’s database updater
- run SMW’s database updater
- empty SMW tables and parse all pages to re-create all semantic data (maintenance script provided)
That done, the result was an empty page. Found out that MW 1.22 requires SMW1.9, so also switched to the newer SMW version. This meant that on top of migrating MW to a new version, I was at the same time upgrading SMW to a higher version. This turned out to be more problematic than the 30-minutes procedure described above.
Once done, the result was still an empty page ! After fiddling around, the result was a not-so-empty page, but with no semantic data. Editing the page resulted in a blank page anew.
I’ve spent a lot of time over the last weeks to figure out the issues. Outcome and learnings :
- There’s a new way to install extensions : composer - or Extension installer for elder MW releases. This shall be used for installing SMW, no matter the MW version. Last release of the Semantic Bundle is 2014-01-03, and I fear it will be discontinued
- Starting with MW 1.17, it is no longer necessary to include DefaultSettings.php in LocalSettings.php. I’d rather say DON’T include it, as it will mess up the composer code integrated in MW1.22 ! Composer code is executed before inclusion of LocalSettings.php, thus the DefaultSettings.php would reset several variables and cancel the loading of the extensions handled by composer.
- Instead of installing all new packages at a time, I first upgraded SMW to 1.9 (this is compatible to MW 1.22) - but also brought the issues
- SMW updater and pages indexer hangs forever on a page if this page can’t be generated correctly by the MW engine. Unfortunately, no error messages are thrown. This especially happens when pictures are missing !!! So make sure all the media is available in your local test installation. I found this out when trying to correlate the various pages where the script hang - all had images embedded. And it is not a good idea to bypass (using -s switch) the indexing of those pages, SMW will still make trouble.
- When running the indexer, prefer the two-pass method : first update the data types, then collect the data. This also turned out to make update smoother
|
|
- Test update locally, or at least on a system with file access (file manager helps a lot) and with phpMyAdmin installed to browse the database. All of this is of course doable on the command line but (at least for me) was a loss of time and efficiency, especially when working on a remote test server through SSH+tmux
- CTRL+R only refreshes the HTML, bypassing any browser caching. It does not refresh the page content like MW’s “refresh"feature. Neither does the maintenance/rebuildall.php recreates all pages and recomputes all semantic properties
- When formatting date/time data for use in a SMW field, like
{{#time: Y-m-d\TH:i:00|{{{DATE_START}}}}
, it is essential to put a backslash in front of the T, else the T is interpreted as “timezone abbreviation”. The resulting string is parsed as valid date in SMW1.8, but will lead to invalid data in SMW1.9