Upgrading Mediawiki


Working in a team to upgrade Mediawiki is always a fun experience, and only half in the traditional sense! When upgrading, code is guaranteed to explode miraculously. One time after upgrading, it was found that several server files were truncated, and some completely blank.

Time again and again, it has been our saving grace to preform server upgrades on a test server.

Currently, the International Scratch Wikis are going through another Mediawiki upgrade cycle, and new bugs are popping up. In this blog post, I'll talk about some of the issues we've encountered.

Windows Strikes Back

The most confusing bug caused every file with special characters (ex: ò, á) in their name to be inaccessible. However, file names appeared unchanged between the production and test servers. Maybe the bug was internal? Instantly, I started speculating that Mediawiki was at fault.

Another confusing revelation was that double escaped file urls worked. Maybe this is an Apache issue?

After digging through the Mediawiki release notes, I found a clue! For Mediawiki 1.27, the PHP extension mbstring is required. However, that was enabled, so what else is going wrong?

One morning, I opened my computer to a new email. The sysop who performed the upgrade had copied the images directory from Unix onto Windows, and back to Linux. This pipe caused encoding issues for the wiki images. To think encoding issues still happen today!

Missing CSS

This is the first bug we found after upgrading our wikis. The Scratchwikiskin CSS was not loading! The script url appeared correct...

Until it was noticed that the CSS was hosted on http, while the test wiki used https. If you don't know by know, browsers hate getting http resources for an https website. Updating the script's url from hard to relative fixed the issue.

Perpetual Edit Conflict

Another confusing bug caused all page edits to trip "edit conflicts". There were no error messages logged, so I started digging through Mediawiki's source code. Times called for drastic measures. Namely, tons of echo() and PHP exceptions.

I started by poking around EditPage.php to see why the page was assuming there was an edit conflict. There are two places where this could happen. It was soon revealed that place #1 wasn't running, so now to check doEditContent() in WikiPage.php.

What is doEditContent()? It attempts to save a page's contents after an edit, and returns a list of errors. Inside doEditContent(), errors are generated by either doCreate() or doModify().

<?php
public function doEditContent(
Content $content, $summary, $flags = 0, $baseRevId = false,
User $user = null, $serialFormat = null, $tags = []
) {
    // ...

    // Actually create the revision and create/update the page
    if ( $flags & EDIT_UPDATE ) {
        $status = $this->doModify( $pstContent, $flags, $user, $summary, $meta );
    } else {
        $status = $this->doCreate( $pstContent, $flags, $user, $summary, $meta );
    }

    // ...

    return $status;
}

In my test cases, doCreate() was running.

What is doCreate()? It creates an article, and saves it in the wiki database. This is definitely room for error!

```php

$dbw = wfGetDB( DB_MASTER );
$dbw->startAtomic( __METHOD__ );

// Add the page record unless one already exists for the title
$newid = $this->insertOn( $dbw );
if ( $newid