Page MenuHomePhabricator

Upgrade production Wikimini from MediaWiki 1.28.0 to at least 1.31 (current Debian GNU/Linux stable)
Open, MediumPublic8 Estimated Story Points


Why upgrade?

When we imported the Wikimini's wiki farm into the WMCH-Infrastructure we kept their legacy MediaWiki version, 1.28.0, in order to concentrate on migration issues and avoid to introduce additional regressions.

This had some security implications that cannot be disclosed here, anyway, we have the responsibility to plan an upgrade ASAP to at least MediaWiki 1.31. That version is the current stable version provided by Debian GNU/Linux buster 10 (current stable). We also have the possibility to update to MediaWiki 1.35 proposed by the buster-backports package.

I generally would be inclined in updating directly from 1.28 to 1.35 for the simple fact that updating MediaWiki usually works as expected nowadays and and that nowadays intermediate advances are not recommended (because in recent versions you have the benefit of fix for old broken updates). Moreover I have a lot of faith in the maintainer of the backports package. Anyway, we can pull the rollback lever in case of troubles.

Some benefits for MediaWiki 1.31:

  • significantly improve security (adopting a clean verified core)
  • improve user experience of multimedia files
  • simplify ordinary maintenance (thanks to the package manager, and getting rid by the legacy VisualEditor Parsoid/JS service)
  • simplify security maintenance (provided by the package maintainer)
  • improve patrolling with block IP-ranges
  • improve cache systems ($wgUseFileCache)

Additional benefits for MediaWiki 1.35:

  • improve user experience adopting newer versions of VisualEditor
  • improve user experience with Scribunto and Lua modules to build advanced templates
  • improve patrolling with partial blocks

See also this page we've contributed to:

For historical reasons here the Wikimini's version matrix at November, 27 2020 (before this upgrade):

Upgrade Plan

Here we can work on an upgrade plan.

Hours are expressed as working-hours, considering a certain margin of unexpected last-minute mess on common sense - I mean, not a fire disaster in the datacenter.

  • understand the fate of the spam-filled beta edition (drop or clean)
    • 0 h drop
    • 8 h clean
  • 4 h deploy a separated test environment of the wiki farm (T277880)
    • databases
      • fr
      • stock
    • filesystem files
  • 4 h disable all the extensions and try a clean database upgrade in the testing environment for each edition
  • T331153: Wikimini extensions review
  • 6 h try to update each needed extension
  • 4 h re-import again the production databases in testing and re-try a full one-step upgrade
  • plan and announce a read-only window
  • 8 h final production upgrade
    • activate maintenance mode in production
    • backup production again (database and files)
    • overwrite production's core
    • overwrite production's extensions
    • upgrade each edition
    • test
    • something really weird happened (e.g. the datacenter is completely on fire)
      • eventually rollback everything
    • disable maintenance mode
    • last minute fixes
    • Champagne!

Event Timeline

valerio.bozzolan updated the task description. (Show Details)
valerio.bozzolan set the point value for this task to 4.

(This Tag was added automagically but I think it has no sense here.)

valerio.bozzolan removed the point value for this task.
valerio.bozzolan renamed this task from Upgrade Wikimini from MediaWiki 1.28.0 to at least 1.31 (current Debian GNU/Linux stable) to Upgrade production Wikimini from MediaWiki 1.28.0 to at least 1.31 (current Debian GNU/Linux stable).Mar 21 2021, 4:34 PM

Just some quick inputs:


  1. It would be OK to drop (and maybe archive) the current forum (AWC`s MediaWiki Forum extension) if there is a better discussion system available for our young users. StructuredDiscussions looks like a good alternative.
  2. The same StructuredDiscussions extension might also be a good alternative to our old LiquidThreads extension.
  3. The Duplicator extension was being used when an article needed to be "split" into two different articles. But there is probably a simpler way to achieve this.
  4. I installed the TorBlock extension myself, but I'm quite sure it doesn't work and has no effect on Wikimini (bad configuration?). I implemented a custom solution instead (look for "Wikiminicustom" in SpecialCreateAccount.php), which works quite well (even if the code should probably be put somewhere else, in order to be executed only when necessary (i.e. after form submit)).
  5. WikiminiLanguage is a custom extension that the previous technical team created, because we needed to add some custom translatable text strings for the Wikimini interface. However, I don't know if this was the correct way to do it.


  1. Do not forget that Wikimini uses a custom skin, and that it also may need some fixes with the new MW version.

(I'm Rififi on Wikimini)
Or at the alternative of AWC we may consider WikiForum, but it's still in beta. I wonder if it would be possible to keep the current forum's convarsations (but if it's take too long, we may drop it).

Unassigning to allow more people to contribute. I'm available to help as volunteer, having said that now I cannot contribute on this in my working time for WMCH.

If you want to plan a tech boost on this, please contact WMCH or Ilario Valdelli directly. Let's continue our discussion in the meanwhile.

Please make sure not to upgrade MediaWiki to any version affected by (such as 1.32-1.34) as in these version any users can insert arbitrary scripts to Common.js.

Probably the best way will be to jump to the latest 1.35 (until 1.35.5
included there is the security bug if I remember well), then 1.39. If
really needed, then we might also make a step to 1.31.