Installation

The instructions at http://mediawiki.org are really straightforward. All you have to do is unzip the MediaWiki tarball/zip file into your web server's main directory. Their recommendation is to put it in a folder called w/, and I recommend following their recommendation.

Permissions

Setting Permissions for LocalSettings.php file

your mediawiki instance is configured using a localsettings.php file. this file usually contains sensitive info like DB password or MW secret key. what permissions should be set for this file?

If the owner of the file is the same as the web server user, set permissions to 600.

If the owner of the file is different from the web server user, set permissions to 640.

MW manual page on LocalSettings.php: https://www.mediawiki.org/wiki/Manual:LocalSettings.php

The webserver user must have access to this file. If this is the same account, who is the owner of the file, then you can set permissions to 600. Sometimes, the webserver user is not the file owner, but they are in the owner's UNIX user group. In this case, permissions of 640 should be fine. For improved security you should narrow permissions down as far as possible.

Changing Images Folder Permissions

After a recent upgrade to the latest MediaWiki, I was encountering an issue trying to upload files. I saw this error message when attempting to upload an image:

MediaWiki: Could not open lock file for <temporary path to image file>

The problem was permissions on the images/ directory in the MediaWiki installation. This problem was easy to solve: make the www user the owner of the images folder.

$ cd /path/to/mediawiki/installation/
$ chown -R www:www images/

That solved the problem.

Changing Namespace Permissions

This is a handy way for you to create custom permissions for parts of your wiki.

Step 1: Select Protected Namespace

This step consists of either selecting an existing namespace to protect, or creating a new namespace.

I will use the example of the "Secret" namespace. As an example, on a public wiki the page [[Message]] would be open to the public, and viewable by anyone. But if this were added to the Secret nanemspace, i.e. if it were at [[Secret:Message]], then it would only be viewable by those with permission to view the Secret namespace.

Add the new namespace to LocalSettings.php with the following code:

$wgExtraNamespaces = array( 100 => "Secret");

If you want to create more namespaces, you can number them 101, 102, 103, etc., or really, whatever you feel like. (Just keep the numbers big so they don't interfere with existing namespaces.)

Step 2: Modify includes/Title.php

The file includes/Title.php is a header file that is included on all MediaWiki pages. When pages are loaded, the load request is processed through Title.php.

Look for the piece of code that looks like this:

        if( $wgUser->isAllowed( 'read' ) ) {
            return true;
        } else {
            global $wgWhitelistRead;

This piece of code checks if a user has global "read" permissions, and if so, it proceeds to load the page.

We will create a new permission called "read_secret" that, if a user has, will allow them to see any page in the Secret namespace.

Add a check for the new "read_secret" permission:

        if( $this->getNamespace() == 100 ) { 
            //this is "Secret" namespace
            return $wgUser->isAllowed('read_secret');
        }   
        if( $wgUser->isAllowed('read') ) {
            return true;
        } else {
            global $wgWhitelistRead;

Step 3: Create a group with the new permission

The next step is to create a MediaWiki group that will have the just-created permission, "read_secret". I'll name this group something really creative like "secret":

$wgGroupPermissions['secret']['read_secret'] = true;

Step 4: Add users to new group

The last step is to add users to the new group. You can go to the page Special:UserRights on your wiki, and it will prompt you for a user. Once you enter a user's name, you will see a list of groups that are available to add a user to:

(Of course, this will depend on your wiki's configuration. Also, you have to be an administrator or a bureaucrat to add users to new groups.)

You can check the "secret" box, and the user will now be a member of the group "secret" and have the permission "read_secret", making him or her able to access pages in the Secret namespace!

Extensions

20 MediaWiki extensions that are pretty handy: http://blog.fedecarg.com/2008/03/08/20-mediawiki-extensions-you-should-be-using/

Math

Also see MathTest for how to WRITE math formulas.

I was having a lot of trouble getting the MediaWiki Math extension to work. I kept seeing the following error:

"Failed to parse (PNG conversion failed; check for correct installation of latex, dvips, gs, and convert)"

Here's how I resolved it:

Step 1: Install all the stuff you need

# this is the "easy way" and is preferable
sudo apt-get install mediawiki-math

# this is the "manual way" and may not work
sudo apt-get install ghostscript imagemagick dvipng texlive-latex-base texlive-latex-extra

Step 2: Fix texvc

For me, I found the main problem was that I didn't have texvc. This page http://www.mediawiki.org/wiki/Texvc suggested installing mediawiki-math using aptitude, which the above instructions should help take care of.

Step 3: Test

You should be able to run the following command line and see some HTML:

$ texvc /tmp/junk /tmp/junk "y=x+2"
Cdaa63ef966cc412541190bc8794731de<i>y</i> = <i>x</i> + 2<mi>y</mi><mo>=</mo><mi>x</mi><mo>+</mo><mn>2</mn>-

And voila!

Moving MW From One Server To Another

Step 1: Set Up SQL

First step is NOT to copy everything from the original wiki to the clone wiki

The first step is to download mediawiki on your new wiki's server and install it like you would normally, to wherever you want to install it, but paying close attention to match the SQL settings in the original wiki's LocalSettings.php

This will then set up the necessary SQL framework.

You can throw away the new wiki you've set up, since the main point is to have MediaWiki create an empty SQL database with the right structure.

Step 2: Copy Apache Files

At that point you copy the original wiki to the clone wiki (at least, all the apache FILES).

Example: your old wiki is contained on your old server in /htdocs/wiki. Your new wiki is going onto your new server in the directory /apache/www/htdocs/wiki. You will copy /htdocs/wiki/ from your old server to /apache/www/htdocs/wiki on your new server.

Step 3: Copy MySQL

Last step remaining is covered on MySQL page: copy the actual database from one MySQL server (original wiki) to the other (clone wiki).

You can do this easily if you use PhpMyAdmin to administer your SQL databases. If not, you can do a SQL dump. If you're using MySQL, use mysqldump. See MySQL page.

Once you've loaded your old SQL database into your new SQL database, restart your MySQL server:

sudo service mysql restart

I also had to change my MySQL config file to make MySQL open to the public. (Apparently, this was not necessary.)

I have more information on my MySQL and PhpMyAdmin pages.

Problems with Cookies

When I migrated my MediaWiki site, I ran into some problems with cookies when trying to log in. I got error messages about my browser not accepting cookies, but cookies were enabled. The problem happened independent of what browser was used, and happened with several machines.

This ended up being a permissions problem - MediaWiki didn't have permission to create files in the directory where it normally stores sessions. I was able to fix this by changing my LocalSettings.php file to specify a particular location for sessions where there would be no permissions problems. I added the following line to the bottom:

session_save_path('/tmp');

Upgrading MediaWiki

Instructions are here: https://www.mediawiki.org/wiki/Manual:Upgrading

Basically, what you do is you download a new version of MediaWiki, then migrate your file content into the new directory. All the articles are contained in a database and new versions of MedaWiki will continue to utilize that same structure.

Procedure:

• Download the latest version (tarball)
• Extract the tarball and put it in a temporary location
• Copy files:
  • LocalSettings.php
  • images directory (chmod -R 755 images and chgrp -R www-data images
  • extensions
  • logo in skins/common/images/
  • Custom skins in skins/
  • Modifications made to old installation files or extensions
  • any custom .htaccess files

Now move the (now-old) "live" mediawiki directory somewhere old, and move the new directory to the "live" location.

Issues

After upgrading, I saw the following error whenever I tried to upload files:

[d5e9fc4f] /wiki/Special:Upload MWException from line 1868 of 
/www/w/includes/filerepo/file/LocalFile.php: Could not acquire 
lock for 'IMAGE_FILE_NAME.png.'

Backtrace:

#0 /www/w/includes/filerepo/file/LocalFile.php(1147): LocalFile->lock()
#1 /www/w/includes/upload/UploadBase.php(708): LocalFile->upload(string, string, string, integer, array, boolean, User)
#2 /www/w/includes/specials/SpecialUpload.php(486): UploadBase->performUpload(string, string, boolean, User)
#3 /www/w/includes/specials/SpecialUpload.php(197): SpecialUpload->processUpload()
#4 /www/w/includes/specialpage/SpecialPage.php(384): SpecialUpload->execute(NULL)
#5 /www/w/includes/specialpage/SpecialPageFactory.php(553): SpecialPage->run(NULL)
#6 /www/w/includes/MediaWiki.php(281): SpecialPageFactory::executePath(Title, RequestContext)
#7 /www/w/includes/MediaWiki.php(714): MediaWiki->performRequest()
#8 /www/w/includes/MediaWiki.php(508): MediaWiki->main()
#9 /www/w/index.php(41): MediaWiki->run()
#10 {main}

Solution:

chmod -R 755 images/
chown -R www-data:www-data images/

Skinning Mediawiki

This article is located at the Skinning MediaWiki page.

I have created two skins, along with explanations:

• CMR MediaWiki Skin
• Dash MediaWiki Skin

Errors

Errors post-nginx upgrade

I got some errors after transitioning to nginx+Apache instead of Apache alone, whenever I tried uploading an image I would see this:

"Problem With File Upload: Could not acquire lock for [filename]"

The solution is basically to change the permissions of the images directory:

cd /www/w/
sudo chmod -R 777 images/

Errors about MIME types

The short version: Modifying includes/mime.types should fix the issue.

When trying to upload an unusual file format/type, I saw an error message (regardless of whether I had checked "Ignore all warnings" checkbox or not) that said:

File extension ".stil" does not match the detected MIME type of the file (chemical/x-mdl-rgfile).

I wasn't sure exactly what the "chemical/x-mdl-rgfile" file type identifier was all about... but was able to fix this by editing the MediaWiki file that maps file extensions to MIME types, /path/to/mediawiki/w/includes/mime.types and adding a line mapping the MIME type listed on the error page ("chemical/x-mdl-rgfile") to the file extension ("stl"):

chemical/x-mdl-stlfile stl

This was listed after multiple other "chemical" file types listed:

chemical/x-mdl-molfile mol
chemical/x-mdl-sdfile sdf
chemical/x-mdl-rxnfile rxn
chemical/x-mdl-rdfile rd
chemical/x-mdl-rgfile rg
chemical/x-mdl-stlfile stl

Modifying includes/mime.types fixed the issue.

Debugging

If you are having problems (like, if your site suddenly becomes a blank white page!), try turning on errors from LocalSettings.php:

error_reporting( -1 );
ini_set( 'display_errors', 1 );

If that doesn't work, try php.ini (/etc/php5/apache2/php.ini on some Nix distros):

error_reporting = E_ALL
display_errors = On

or use .htaccess:

php_value error_reporting -1
php_flag display_errors On

Bots

Mediawiki has an API: https://www.mediawiki.org/wiki/API:Client_code

pywikibot is a Python library providing bindings for interfacing with mediawiki, enabling Python bots: https://github.com/wikimedia/pywikibot-core

pattern is a more powerful and more general text-mining library for the web, which has some functionality specific to mediawiki built in: https://github.com/clips/pattern

Project idea: use the API to extract data about the wiki, make some simple graphs, plot it.