Mediawiki installation

This article or chapter is incomplete and its contents need further attention. Some information may be missing or may be wrong, spelling and grammar may have to be improved, use your judgment!

Mediawiki installation and configuration tips for Ubuntu linux distributions, in particular for an educational context.

The documentation was tailored for Ubuntu 16LTS and MediaWiki 1.27. Originally, these installation tips were made for MW 1.24 (early 2015) using Ubuntu 14LTS.
Some parts have been updated to MediaWiki 1.31 in Sept. 2018. Since then I did not try to install fresh systems, some information below may be misleading. Overall, upgrading information and information about extensions should be fairly accurate as of Setp. 2018. However, please do check other sources and do carefully read official extension documentations !.
Some of the documentation also can be useful for other platforms (other unix systems, windows, mac) and different MW distributions.

Also consider buying Yaron Koren's book

First time installation of essential Ubuntu/Debian software

I recommend first installing your favorite text editor (I have been using the same thing for the last 30+ years: emacs). A simple editor like pico (alias nano) can do. If you don't know how to use vi or vim, avoid !

apt-get install nano

Prerequisites

Starting point: Ubuntu 16.04.x LTS
PHP/Apache/MySQL and curl installed
PHPMyAdmin installed (not really needed)

To see what packages are installed, you could use for example:

sudo apt-cache showpkg apache2 mysql-server php php-mysql libapache2-mod-php php-cli phpmyadmin

or

dpkg -l | egrep 'apache2|mysql-server|php|php-mysql|libapache2-mod-php|php-cli|phpmyadmin'

To install Apache/PHP/MySQL, try something like this (if needed). Ubuntu 16 now officially supports PHP7, but after an upgrade I still found php5 around.

sudo apt-get install apache2 mysql-server php php-mysql libapache2-mod-php php-cli phpmyadmin

Sendmail (postfix) must be installed and configured
- Check if /etc/postfix is there

Prior to installing MediaWiki

Git

Git is Revision control system and is needed to download MW and extension software and to manage versions. You could do it the traditional way (e.g. download file archives), but using git can save time.

apt-get install git

Composer

Composer is a PHP package management system and it is needed to manage some important Mediawiki extensions

You can download it to any directory (here I used "/src"), but then the composer.phar file should be copied to /usr/local/composer

mkdir /src
cd /src
curl -sS https://getcomposer.org/installer | php
# testing
./composer.phar
# installing
mv composer.phar /usr/local/bin/composer
# testing
composer self-update

Essential libraries

This section lists all sorts of libraries you need to have if you plan to use extensions. It is better to have them installed before installing the Mediawiki, since the installation script can detect and configure these

php-intl provides unicode support
imagemagick allows to create thumbnails.

sudo apt-get install php-intl imagemagick
#restart is needed !!
apache2ctl restart

You then also should configure the LocalSettings.php file to use Imagemagik for rendering SVG files.

Read SVG in the Image Manual.

Finding a solution that both works and produces acceptable quality can be fairly difficult.

batik is difficult to install (complains about security)
ImageMagik cannot deal with certain SVG
rsvg is today maybe the best compromise

sudo apt-get install librsvg2-bin

In your Local file use something like this. You may have to adapt the executable path, e.g. rsvg is called rsvg-convert in Ubuntu.

# SVG conversion
$wgMaxShellMemory = 512000
# $wgMaxShellMemory = 5000000;
$wgAllowTitlesInSVG = true;

$wgSVGConverters = array(	
  'ImageMagick' => '/usr/bin/convert -background white -thumbnail $widthx$height\! $input PNG:$output',
  'batik' => '/usr/bin/java -Djava.awt.headless=true -jar /usr/share/java/batik-rasterizer.jar -w $width -d $output $input',
  'rsvg' => '/usr/bin/rsvg -w $width -h $height $input $output'
);

$wgSVGConverter = "rsvg";
# Batik - best results but slow
# $wgSVGConverter = "batik";
# $wgSVGConverter = "ImageMagik";

Currently, we use the following under Ubuntu 18LTS and MW 1.31

# SVG conversion
# $wgMaxShellMemory = 512000
$wgMaxShellMemory = 5000000;
$wgAllowTitlesInSVG = true;

$wgSVGConverters = array(	
  'ImageMagick' => '/usr/bin/convert -background white -thumbnail $widthx$height\! $input PNG:$output',
  'batik' => '/usr/bin/java -Djava.awt.headless=true -jar /usr/share/java/batik-rasterizer.jar -w $width -d $output $input',
  'rsvg' => '/usr/bin/rsvg-convert -w $width -h $height -o $output $input'
);

$wgSVGConverter = "rsvg";
# Batik - best results but slow
# $wgSVGConverter = "batik";
# $wgSVGConverter = "ImageMagik";

Finally, make sure that your wiki can deal with large SVG Files

# hack pour un bug https://phabricator.miraheze.org/T3278
# I multiplied the size by 4, e.g. 1M instead of 256K
$wgSVGMetadataCutoff = 1000000;

Choosing a release

In principle one should use the latest stable release when you install a new wiki. This way you are fairly sure that new extensions you will install should last a bit. Alternatively, install the latest long term version (see next item).

We then recommend upgrading to each new release until you reach an LTS (long term support) version. Once you have an LTS installed you can wait about two years before upgrading to the next LTS. As of Sept 2018, use 1.31 LTS. IKt should last until June 2021. Read Version lifecycle release policy from Mediwiki.org for more information.

Additional web services

These are optional, but required by some extensions (see in the extension chapter below)

Node.js

This is a JavaScript web server and is needed for the VisualEditor

Its installation is explained in VisualEditor, since it is is needed for that extension.

Mw-lib

Is needed to run a local PDH / DocBook server and it works with the Collection extension.

Its installation and configuration is explained in Mediawiki collection extension installation

Web server configuration and mediawiki directories

Mediawiki directories

In principle, you could install a mediawiki installation within the web directory.

I usually prefer to install all portals in some other place and then configure the web server to include this place using the Apache ALIAS directive (see below). IMHO, this makes administration easier in the long run. Also, in times of crisis it's easier to take a portal offline: just disable the ALIAS or restrict access to the local network.

The structure of our portals directory (portails in french) is the following:

src (various source files)

mediawiki (Edutechwiki/en, this wiki) <= Exposed to web with an ALIAS

fmediawiki (french version) <= Exposed to web with an ALIAS

testwiki <= Exposed to web with an ALIAS

.....

extensions (shared ones)

Create a directory, e.g.

/data/portails/wikitest

or

/portals/wikitest

We will put the mediawiki code there

Apache2 virtual sites file for your mediawikis

On system that shares various web applications, I suggest using a virtual web server name for your wiki. Ask for an Internet alias instead of using the "main name of your machine". This way you can migrate your wiki more easily from one machine to another. Move the files, export/import the database and have the alias move to the new machine.

Web server configuration of the virtual host

Create an Apache2 site file, e.g. I called it mediawiki.conf.

Site files are located in the following directory:

/etc/apache2/sites-available/

Contents of /etc/apache2/sites-available/mediawiki.conf (some optional and repetitive stuff removed)

Replace the stuff in capital letters

Important:

The VirtualHost must be the name of the machine. *:80 will no longer work ! That cost me 2 hours :(
Security has tightened. You cannot just declare an Alias. In addition, you must provide directory access explicitly to each directory outside the default web tree
We will use "pretty" Wikinames (see below). This is why we need two aliases. One will be point to the installation directory and the other to the main php file of the mediawiki server. The latter is the one that people will see in a normal URL.

<VirtualHost YOUR.VIRTUALSERVER.DOMAIN>
ServerAdmin YOUR-NAME@YOURSERVER.DOMAIN
ServerName YOUR.VIRTUALSERVER.DOMAIN
ServerSignature Off
DocumentRoot /web

	<Directory />
	     Options FollowSymLinks
	     AllowOverride All
	</Directory>

	<Directory /web>
		Options Indexes
		AllowOverride All
	</Directory>

	ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
	<Directory "/usr/lib/cgi-bin">
		AllowOverride None
		Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
		Order allow,deny
		Allow from all
	</Directory>

	ErrorLog /var/log/apache2/error.log

	# Possible values include: debug, info, notice, warn, error, crit,
	# alert, emerg.
	LogLevel warn

	CustomLog /var/log/apache2/access.log combined

# ALIASES for wikitest: TWO alias for each WIKI
	Alias /wikitest "/data/portails/wikitest"
	Alias /wt "/data/portails/wikitest/index.php"
	<Directory /data/portails/wikitest>
	        require all granted
	</Directory>

# ALIASES for edutechwiki_en: TWO alias for each WIKI
	Alias /mediawiki "/data/portails/mediawiki"
	Alias /en "/data/portails/mediawiki/index.php"
	<Directory /data/portails/mediawiki>
	        require all granted
	</Directory>

</VirtualHost>

Create a symbolic link in the /etc/apache2/sites-enabled directory. The file will now be loaded into the apach2.conf.

pushd /etc/apache2/sites-enabled/
ln -s ../sites-available/mediawiki.conf .

Test it:

apache2ctl restart

Repeat for ssl configuration

If you also serve via SSL, you will have to do this again with the SSL configuration file

Changes to the main configuration file

Log files: If you use a dedicated machine for your wikis, you may just have all the logs in a single place.

# Define an access log for VirtualHosts that don't define their own logfile
CustomLog /var/log/apache2/other_vhosts_access.log vhost_combined

Web user ID: By default, the server will run under the ID www-data:www-data. I suggest leaving this as is.

Default server name: You could add a default server name, e.g. the name of the physical machine

ServerName REAL.NAME.DOMAIN

Local Apache documentation: Can help maybe, but it's not needed

apt-get install apache2-doc

PHP configuration

Add crypting to PHP

On the command line, type:

phpenmod mcrypt

Configuration of PHP for Web

Mediawiki takes quite a lot of memory. Some extensions can run for quite a while. If you don't have many other portals where scripts can run wild, you could use fairly large values here (even go higher than below). Warning after upgrading from Ubuntu 14LTS to 16LTS, you will have to edit the PHP files again. Notice that php.ini will sit in different places, E.g. in 16_LTS it sits in /etc/php/7.0/apache2 !!

For Ubuntu 18LTS, make sure that you use PHP 7.2. In a terminal, type:

php --version

Edit file /etc/php/7.2/apache2/php.ini

Make sure that PHP can compute your most complex pages:

max_execution_time = 180
max_input_time = 180
memory_limit = 256M

Alternatively

memory_limit = -1

File upload: If people can upload videos, etc. you do have to accommodate.

post_max_size = 50M
upload_max_filesize = 50M

Allow people time for editing (students will freak out if the wiki refuses to save and edit, else explain that they could copy the edited text someplace and then edit again)

session.gc_maxlifetime = 10800

Remove error messages from file caching in wiki

apc.slam_defense = 0
apc.write_lock = 1

Configuration of command line PHP

Default values should be ok, although for larger wikis, you may have to raise values.

Edit /etc/php/7.2/cli/php.ini

// cannot remember why

session.gc_maxlifetime = 3600

Create a MySQL database

You will have to create a database (we strongly suggest not to use prefixes, i.e. not to share tables of this portal with another one

Database Name (e.g. WIKITEST)
Database User (will be inserted into the LocalSettings.php MW configuration file)
Database user password.

For such simple operations we suggest using the mysql command line as shown below. Prepare the command in a text editor, the copy/paste. Otherwise use PhpMyAdmin, the SQL tab. In the code below, replace words WIKITEST, USER_TO_REMEMBER, PASSWORD_TO_REMEMBER

mysql -p
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 39
Server version: 5.5.41-0ubuntu0.14.04.1 (Ubuntu)

mysql> create database WIKITEST;
Query OK, 1 row affected (0.00 sec)

mysql> grant index, create, select, insert, update, delete, drop, alter, lock tables on WIKITEST.* to 'USER_TO_REMEMBER'@'localhost' identified by 'PASSWORD_TO_REMEMBER' ;
Query OK, 0 rows affected (0.01 sec)

Mediawiki Installation with GIT

Download

Step 1

Firstly, make sure that the basic Ubuntu infrastructure is working ! (see above)

Step2 - Download the core

If you want to be able to upgrade quickly or work with a bleeding edge alpha version (sometimes this is recommended, sometimes not), the simplest way is using GIT (formerly SVN was used). The reason not to use the latest version, is that extensions can break and that very early versions may have bugs.

Read Download from Git

Get the core

Go to your installation parent directory

cd /portails

Get the files, files will be copied to a "core" directory.

git clone https://gerrit.wikimedia.org/r/mediawiki/core.git

Now make sure to select the right version, e.g. as of Sept. 2018, this provides the latest stable MW version.

git checkout REL1_31

Move the core directory to a more meaningful name, e.g.

# move
mv core wikitest

Your files should be in the /portails/wikitest directory (or rather in a place that suits your needs)

Step 3 - Install the mandatory extensions

If you don't do this, the GUI will be missing and you couldn't even display the installation script. "LightnCandy class not defined" would be an indicator of forgetting this step.

composer install --no-dev

Step 4 - install a skin

The core system from GIT does not include skins, except for a text-based simple one

cd skins
git clone https://phabricator.wikimedia.org/diffusion/SVEC/Vector

Location of the repositories changes all the time, e.g. for MW 1.27 it was git clone https://git.wikimedia.org/git/mediawiki/skins/Vector.git. Read the README file in the skins directory. It will tell where to look for.

Note: Later you must load the skin in the LocalSettings.php file !

Initial configuration

Go to the long Wiki URL (this depends on how where you installed the wiki and how you created your web server alias, see above)

http://YOUR.SERVER.DOMAIN/wt/index.php

Select language of the wiki (user interface) and your own language (for the installation)

Environmental checks should be just fine, e.g. you should see something like this (from an older installation a few years back).

Basic checks will now be performed to see if this environment is suitable for MediaWiki installation. Remember to include this information if you seek support on how to complete the installation.
PHP 5.5.9-1ubuntu4.7 is installed.
Found ImageMagick: /usr/bin/convert.

Image thumbnailing will be enabled if you enable uploads.
Found the Git version control software: /usr/bin/git.
Using server name "http://tecfalx5.unige.ch".
Using server URL "http://tecfalx5.unige.ch/wikitest".
Using the intl PECL extension for Unicode normalization.
The environment has been checked. You can install MediaWiki.

Answer all the questions :) I suggest using most of the defaults, in particular the ones that relate to database architecture. Since you will have to tune the configuration file manually, you will have learn how to configure the MediaWiki manually anyhow. Just make sure to remember: database name, database user, database user password.

At the end you will get a configuration file that you can copy into the wiki directory.

If you work in a decent environment, just edit file LocalSettings.php, paste contents and then save. Else you will have to copy the file to the server.

Step 2 - Repair the configuration file

In particular, make sure that short URLs work and that you have a skin (the graphical user interface)

Edit LocalSettings.php and create short URLs

The script will only generate some like:

$wgScriptPath = "/wikitest";

But you will have to add:

$wgScript           = "$wgScriptPath/index.php";
$wgRedirectScript   = "$wgScriptPath/redirect.php";
$wgArticlePath      = "/wt/$1";

Edit LocalSettings.php to define a skin

Vector skin is defined as default, but the Wiki won't find it. See also the section on skins. I f you get MediaWiki from GIT, you will have to download separately

Add the following line:

wfLoadSkin( 'Vector' );

or maybe:

 wfLoadSkin( 'vector' );

In older installation it was:

require_once "$IP/skins/Vector/Vector.php";

Hacks

Usually modifying any file in the source code because you will have to redo the fixes after each minor update. In addition, git will become confused.

Inkstitch namespace

InkStitch is an Inkscape extension to create digital embroidery designs. Its SVG namespace is not recognized by MediaWiki and SVG files using not listed namespaces will not display.

InkStitch namespace (https://phabricator.wikimedia.org/T197595)
https://www.mediawiki.org/wiki/Manual:UploadBase.php

Around line 1542 of file includes/upload/UploadBase.php

'http://inkstitch.org/namespace',

Updating with GIT

(section must be moved - Daniel K. Schneider (talk) 18:16, 9 April 2015 (CEST))

Updating the same version:

git pull
php maintenance/update.php

But see also the composer information below. You may have to rerun it using various weird tricks to get it going ... :(

Changing versions:

(1) Update the code

git checkout <new version>

for example

git checkout REL1_31

(2) Run the composer (if necessary, install and then repair the json file if needed. E.g. it seems to remove all the SMW extensions)

cp composer.json composer.json.SAVE
composer install 
composer update

(3) update

php maintenance/update.php

Sometimes the composer is way to sensitive to differences in subversions. Try the following (even if it is not a smart thing to do per se ...)

php maintenance/update.php --skip-external-dependencies

If update breaks, then it is likely that an extension did become incompatible.

Comment the extension in LocalSettings.php
upgrade the extension

Trouble

We repeat: If you get Error: your composer.lock file is not up to date. Run "composer update --no-dev" to install newer dependencies and you are sure that you installed the correct versions, try:

php maintenance/update.php --skip-external-dependencies

Configuration

The configuration file, minimal settings

Unless you use some configuration extension, all the configuration (except for styles and user messages) is done in file LocalSettings.php (in the top-level directory of the distribution).

Reading:

List of default settings (source code)

https://github.com/wikimedia/mediawiki-core/blob/master/includes/DefaultSettings.php (Look at this file after upgrading. If you got a ten year old MediaWiki, you may have stuff in your Localsettings.php that you may want to change / get rid off !

LocalSettings.php will read first the file includes/DefaultSettings.php and then override its settings with your own settings.

Below are a few settings (also read "nice URLs" below).

Wikiname:

// The site name is also used as namespace for certain pages, so select it with care
$wgSitename   = "EduTech Wiki";

File cache can speed up serving non-dynamic contents a lot. However, caching is a complicated art .... (more later)

// Use the file cache and gzip the files
$wgUseFileCache = true;
$wgFileCacheDirectory = "$IP/cache";
$wgShowIPinHeader = false; 
$wgDisableOutputCompression = true; // in case you have some leftover code that will gzip any output (not compatible)
$wgUseGzip = true;

Rights and icons I suggest creating a subdirectory of the main directory where you can put picture files for icon that are read in via PHP. I used tecfa, pick your own, e.g. call it local

// Rights
$wgEnableCreativeCommonsRdf = true;
$wgRightsPage = "EduTech_Wiki:Copyrights"; # Set to the title of a wiki page that describes your license/copyright
$wgRightsUrl = "http://creativecommons.org/licenses/by-nc-sa/3.0/";
$wgRightsText = "CC BY-NC-SA Licence";
$wgRightsIcon = "$wgScriptPath/tecfa/somerights.png";

// Icon on top left of your pages (change the sunflower)
$wgLogo = "$wgScriptPath/tecfa/wiki.png";

Permissions: I suggest using somewhat restrictive permissions, i.e. users have to create a login before editing. However, this cannot last for long unless you can hire a community manager to clean up spam. Once your wiki is online, it will take only a few month before it's filled up with tens of thousands of spam pages. We shall explain later how to manage user rights and how to fight spam. This is just for starters ...

// Permissions - editing users need to have a login
$wgGroupPermissions['*']['edit']            = false;
$wgGroupPermissions['*']['createaccount']   = true;
# $wgGroupPermissions['*']['createaccount']   = false;
$wgGroupPermissions['*']['read']            = true;

Various

// Strongly suggest to keep this (enabled by default). Puts all the messages in the database
// (easier to edit and edits will survive upgrades
$wgUseDatabaseMessages = true;

Files uploads: In an educational setting you might allow more file formats than in a fully open wiki. Certainly PDF should be included, unless you have some stable and easy to use document systems that is available to your learners. In any case, you 'must firstly enable file upload.

$wgEnableUploads = true;
$wgFileExtensions = array( 'png', 'gif', 'jpg', 'jpeg', 'ogg', 'pdf', 'mp3', 'svg', 'doc', 'xls', 'ppt', 'pub', 'txt', 'ps', 'zip' );

At the server level, you should make sure that the web server can write into the images directory. E.g. on a Ubuntu system, type:

# cd your_wiki_installation_directory
chown -R www-data:www-data images/

Other image related settings may have to be defined, e.g. read Manual:Configuring file uploads

PHP Caching

Bytecode caching

Since PHP5.5, it is suggested to use OpCache for bytecode caching, i.e. the php code that is executed each time a page is called. (Unless I am wrong), it already is installed and configured in Ubuntu 16LTS.

See:

php -r 'phpinfo();' | grep opcache

Object caching

Quote from the manual: “When MediaWiki assembles a page to show to a user, it performs database queries to gather lots of different pieces of data and then combines it all into the page. Object caching allows MediaWiki to store these combined objects for later retrieval reducing the time spent communicating with the database and assembling pages. This is arguably the most important cache for most installations.”

In PHP > 5.5 since you already have OpCache, you could use APCu (not yet tested). For PHP 7x, try:

apt-get install php-apcu

Page caching

Will cache pages as static HTML pages. This works for most pages and for users that are not connected. Page caching was was introduced above, in the basic settings.

Nice URLs

We already explained above how to define short URLs. This little section, summarizes the information in one place. You always can first with default (ugly) URLs and then change later. But as a principle, you don't want ugly default URLs

Example of a nice URL: http://edutechwiki.unige.ch/en/Mediawiki_installation
Example of the ugly (default version) http://edutechwiki.unige.ch/mediawiki/index.php?title=Mediawiki_installation).

Reading: http://www.mediawiki.org/wiki/Manual:Short_URL

Here is an easy way to do achieve this for the content pages. The method described below is probably not exactly the one that is now being suggested by the manual, but it has been working for years.

Apache configuration file directives of direct interest to nice URLs:

<VirtualHost YOUR.VIRTUALSERVER.DOMAIN>
ServerAdmin YOUR-NAME@YOURSERVER.DOMAIN
ServerName YOUR.VIRTUALSERVER.DOMAIN

<Directory />
   Options FollowSymLinks
   AllowOverride All
</Directory>
 
# This should include the robot.txt file
<Directory /web>
   Options Indexes
   AllowOverride All
</Directory>

# ALIASES for wikitest: TWO alias for each WIKI
Alias /wikitest "/data/portails/wikitest"
Alias /wt "/data/portails/wikitest/index.php"
<Directory /data/portails/wikitest>
    require all granted
</Directory>

</VirtualHost>

Then in LocalSettings.php:

$wgSitename         = "Wiki test";

$wgScriptPath	    = "/wikitest";
$wgScript           = "$wgScriptPath/index.php";
$wgRedirectScript   = "$wgScriptPath/redirect.php";

Therefore only "normal" pages look nice. Special pages remain ugly, but this doesn't matter IMHO.

Also consider excluding all or most special pages in robots.txt. No reason that these should be indexed and they really eat away CPU cycles if you need another argument.

Disallow: /wikitest/
Disallow: /wt/Special:AllPages
Disallow: /wt/Special:Book
Disallow: /wt/Special:NewPages
Disallow: /wt/Special:PopularPages
Disallow: /wt/Special:RecentChanges
Disallow: /wt/Special:RecentChangesLinked
Disallow: /wt/Special:Search
Disallow: /wt/Special:Whatlinkshere
Disallow: /wt/Special:WhosOnline

Permissions

In some wikis you may want to set permissions, e.g. only allow people in an author group to edit or only allow registered users to read. Since Mediawikis are designed to support either open sites like Wikipedia or closed sites or read-only sites, the permissions system is fairly simple. In our opinion it's good enough for most educational scenarios:

Example (from an early EduTechWiki): Only registered could edit, but anyone could create an account

$wgGroupPermissions['*']['edit']            = false;
$wgGroupPermissions['*']['createaccount']   = true;
$wgGroupPermissions['*']['read']            = true;

Nowaday, we use a confirm edit and captcha extensions that we shall explain in the next section. Only folks in the author group can edit hassle free:

## Extension must be installed (see below)
$wgGroupPermissions['authors']['skipcaptcha'] = true;

Creating special user groups

As soon as you use a user group in a $wgGroupPermissions statement, the group is created and you can add users to it through the Special:UserRights page. E.g. if you decide that you should have an author group as above, it will be created as soon as you define a permission for such a group (see above)

Example (from a biology teaching wiki): Only current students can edit, all others can read

$wgGroupPermissions['*']['createaccount']   = true;
$wgGroupPermissions['*']['read']            = true;
$wgGroupPermissions['*']['edit']            = false;
$wgGroupPermissions['*']['createpage']      = false;
$wgGroupPermissions['*']['move']            = false;
$wgGroupPermissions['*']['createtalk']      = false;
$wgGroupPermissions['*']['upload']          = false;
$wgGroupPermissions['*']['reupload']        = false;
$wgGroupPermissions['*']['reupload-shared'] = false;
$wgGroupPermissions['*']['minoredit']       = false;
$wgGroupPermissions['user' ]['read']            = true;
$wgGroupPermissions['user' ]['move']            = false;
$wgGroupPermissions['user' ]['edit']            = false;
$wgGroupPermissions['user' ]['createpage']      = false;
$wgGroupPermissions['user' ]['createtalk']      = false;
$wgGroupPermissions['user' ]['upload']          = false;
$wgGroupPermissions['user' ]['reupload']        = false;
$wgGroupPermissions['user' ]['reupload-shared'] = false;
$wgGroupPermissions['user' ]['minoredit']       = false;
$wgGroupPermissions['eleve7']['read']            = true;
$wgGroupPermissions['eleve7']['edit']            = true;
$wgGroupPermissions['eleve7']['move']            = true;
$wgGroupPermissions['eleve7']['createpage']      = true;
$wgGroupPermissions['eleve7']['createtalk']      = true;
$wgGroupPermissions['eleve7']['upload']          = true;
$wgGroupPermissions['eleve7']['reupload']        = true;
$wgGroupPermissions['eleve7']['reupload-shared'] = true;
$wgGroupPermissions['eleve7']['minoredit']       = true;

Restrict permissions in name spaces

The Lockdown extension allows to restrict permission for both special pages and namespaces. This extension did install and work with MW 1.22 (Jan 2014).

Example from a project-oriented learning wiki, that only allows some users to read the discussion pages (these pages may contain confidential discussion/data)

// Lockdown Permissions:
require_once "$IP/extensions/Lockdown/Lockdown.php";
$wgNamespacePermissionLockdown[NS_TALK]['read'] = array('author');
$wgNamespacePermissionLockdown[NS_TALK]['read'] = array('sysop');

Secure login

As of 2017, browsers start seriously complaining when people use the non secure http protocol to login in.

Therefore you will have to do two things (1) Configure the web server for SSL / https. This can require some serious work.

Read Ubuntu configuration help
Follow the links at the bottom.

(2) Instruct your wiki

Add the two following lines to LocalSettings.php (much easier than trying to mess with Apache rewrite rules)

$wgServer           = "//edutechwiki.unige.ch"; // Change this to your server root (not wiki root)
$wgSecureLogin      = true;

Read Manual:$wgSecureLogin

Fighting spam

For maintaining a spam free wiki there are only two solutions, according to our experience

Hire a full time person to remove daily spam
Make it difficult to become an author. Since we don't have the funding or hundreds of helpers that work for free, we opted for this solution.

Here are the principles:

Only registered users can edit (using a captcha)
Only registered users in an author group can edit hassle free
- Extension: ConfirmEdit
Login creation is subject to a review and uses a form that requires the user to enter information about him/herself. In addition, a captcha must be solved.
- Extension: ConfirmAccount

Installation of ConfirmAccount and ConfirmEdit

ConfirmAccount will require users to fill an form. Administrators will be notified and then can accept a user or not.

#To to the extensions directory
cd extensions

# Clone the ConfirmAccount repository
git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/ConfirmAccount

# Go to ConfirmAccount directory
cd ConfirmAccount/

# See what's in the repository
git branch -r

# Adjust the version number ('''this is crucial''')
git checkout REL1_31

Welcome message. By default, the welcome message to new users has a mistake (as of 2018 there is a wrong link to the help in both the English and the French version) and you may want to change it anyhow.

Edit MediaWiki:Confirmaccount-welc
You also can find this message also by looking at your Special:AllMessages

Now install ConfirmEdit if you want to avoid that spamming scripts fill in the application form. In addition, ConfirmEdit can then be used as last defense layer, i.e. each confirmed used still will have to solve a recaptcha (no captcha) when editing a page.

 cd extensions
 git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/ConfirmEdit
 cd ConfirmEdit
 git checkout REL1_31

Finally, update the wiki. This is crucial since it will create two database tables.

# Run the update script ! 
cd your_installation_directory
php maintenance/update.php

ConfirmEdit is not strong enough to deter scripts and untrained humans. Some "Search engine optimization" companies pay people from very poor countries to create logins and you need to filter both. Therefore you could use a domain-specific text questions with difficult (but not too difficult answers). To do this correctly would require some work. Anyhow, for using either captcha or captcha (no captcha) reduced spam-related user requests to a tolerable minimum

Get a reCaptcha key from Google

Either from the propaganda page or the developer page:

Copy/paste the two keys and use them in the configuration file as show below.

Privatekey (Wiki) = secret key (google)
PublicKey (Wiki) = site key (Google)

Configuration

As of this wiki in Aug 2016 and Sept 2018. On other wikis, we use different setups, e.g. on low traffic wikis, we do not install ConfirmEdit.

MediaWiki     1.27.1
PHP     7.0.8-0ubuntu0.16.04.2
Confirm User Accounts    – (840191a) 01:36, 22 August 2016
ConfirmEdit    1.4.0 (38711ed) 15:14, 21 August 201

# NEW ReCaptcha (NoCaptcha)

require_once "$IP/extensions/ConfirmEdit/ConfirmEdit.php";
wfLoadExtensions( array( 'ConfirmEdit', 'ConfirmEdit/ReCaptchaNoCaptcha' ) );
$wgCaptchaClass = 'ReCaptchaNoCaptcha';
$wgReCaptchaSiteKey = '....';
$wgReCaptchaSecretKey = '....';

/*
# OLD ReCaptcha VERSION
require_once( "$IP/extensions/ConfirmEdit/ConfirmEdit.php" );
require_once( "$IP/extensions/ConfirmEdit/ReCaptcha.php" );
$wgCaptchaClass = 'ReCaptcha';
$wgReCaptchaPublicKey = '....';
$wgReCaptchaPrivateKey = '...';
*/

# Confirm Account

// wfLoadExtension( 'ConfirmAccount' );
require_once("$IP/extensions/ConfirmAccount/ConfirmAccount.php");
// $wgAllowAccountRequestFiles = false;
$wgConfirmAccountContact = "daniel.schneider....";
$wgConfirmAccountRequestFormItems['Biography']['minWords'] = 10 ;

# our users must be registered, once they are in they they still must fill in captchas.
$wgCaptchaTriggers['edit']          = true;
$wgCaptchaTriggers['addurl']        = false;
$wgCaptchaTriggers['create']        = true;
$wgCaptchaTriggers['createaccount'] = true;

# Skip recaptcha for confirmed authors (they will inherit normal user rights)
$wgGroupPermissions['authors']['skipcaptcha'] = true;

Removed spam

The Nuke extension allows to remove all pages recently added by a user or IP address.

In LocalSettings.php

wfLoadExtension( 'Nuke' );

The deleteBatch.php maintenance script can remove pages that are listed in a file

php deleteBatch.php somepages.txt

This extensions does not remove links in other pages or images.

The DeleteBatch extension adds a user interface.

Other user-related operations

To kill unused accounts, use removeUnusedAccounts.php, e.g. type this in the maintenance folder to remove untouched accounts that are older than one year.

php ./removeUnusedAccounts.php --ignore-touched 360 --delete

Messages

Configuring interface messages is quite easy. Use the following procedure, if you can't recall the names of the appropriate Mediawiki pages (each message is defined in its own page).

List all messages with the special page Special:Allmessages
You then can customize each Mediawiki message, by clicking on a message and edit

Notice:

Works by default, i.e. $wgUseDatabaseMessages = true;
If you are not using database messages, you can edit the languages/Language.php file (for English) or languages/LanguageXX.php for non-English languages, where XX is the two-letter language code for your language
Be careful: entering wrong data may disable some messages ....

Each of the Mediawiki:XXX pages you may configure are listed in Special:Allmessages as we said above. The ones you did redefine will be in green. Below are two examples:

Slogan and site notices

A slogan message

The page MediaWiki:Sitesubtitle will allow you to add some sort of slogan (you also can kill this default page). Has the same effect as setting the $wgExtraSubtitle variable.

Sitenotices (e.g. to annonce an important event)

Read: http://www.mediawiki.org/wiki/Manual:Interface/Sitenotice

In LocalSettings.php, set

$wgSiteNotice = " ........ ";

Skins and CSS

Skin selection

Unless you have time to spend, I suggest to use the standard Vector skin. Other skins are not as well supported. E.g. some important extensions like the Visual Editor just won't work with other skins.

For some kind of installations, the skin is not included, i.e. you must install one yourself. See below.

Fine tuning CSS

You should adjust the CSS (in particular class or id selectors for extensions) in the MediaWiki:Common.css page. Do not edit CSS files in the server if you can avoid. This strategy makes maintenance much easier.

Install with composer

composer require mediawiki/vector-skin

If you change from manual to composer installation, you may have to remove old files first.

Get the Vector skin with GIT

Important: If you download the mediawiki code via Git, the skin is not included starting version 1.24 (read this, summer/fall 2014)

Do the following:

cd <install-dir>
cd skins
# git clone https://gerrit.wikimedia.org/r/mediawiki/skins/Vector
git clone https://phabricator.wikimedia.org/diffusion/SVEC/vector.git

After downloading the git archive, I suggest adjusting the version, since skins depend on version-specific features, for example:

git checkout REL1_31

In Localsettings, load it:

wfLoadSkin( 'Vector' );
$wgVectorUseSimpleSearch = false; // set to true if you don't want the search/go buttons
$wgVectorUseIconWatch = true;
$wgVectorResponsive = true; // make it more mobile friendly

Changes to the navigation sidebar to the left

Reading: Navigation bar help

Configuration: Edit MediaWiki:Sidebar (menu definition page) in your wiki

Since version 1.14 (or earlier) you may use keywords to change the order of portlets (boxes with menu items). E.g.

* SEARCH

* navigation and help
** mainpage|Mainpage
** EduTech_Wiki:About|about
<!-- ** portal-url|portal -->
<!-- ** currentevents-url|currentevents --> 
** randompage-url|randompage
** helppage|Help
** Help:Editing rules|Editing rules
** Blog:DKS|Blog (D.K.S.)

* categorytree-portlet

* TOOLBOX

* LANGUAGES

* big brother
** Special:Newpages|New Pages
** recentchanges-url|recentchanges
** Special:Guestbook|Guestbook
** Special:Popularpages|Popular Pages
** Special:WhosOnline|Who is online ?

* TECFA links
** http://tecfa.unige.ch/ |TECFA
** http://tecfaseed.unige.ch/door/ |TECFA Portal

In addition one also could add more sophisticated custom items (instead of hand editing the skin files, to do ....)

Subpages

According to the MediaWiki help pages Subpages can be useful for three major purposes.

to create archives of old discussions under a talk page
to create scratchpad editing spaces under a user page
to create other language versions of a document in multilingual wikis

Slashes (/) within a page name break the page into parent and subpages, recursively

Avoid subpages for regular pages for two reasons: It's against the wiki/hypertext philosophy and some crucial extensions (like the book creator) can't find them !
Allow subpages for regular pages, if you want users to add some kind of "attachments", e.g. code examples, student productions related to a page, note taking elements, etc. In that case, make sure that users will not create CMS-like content hierarchies.

Read:

Manual:$wgNamespacesWithSubpages

It you plan to enable supages everywhere, use:

# Enable subpages in all namespaces
$wgNamespacesWithSubpages = array_fill(0, 200, true);

Else use something like:

$wgNamespacesWithSubpages =
     array(
	NS_TALK           => true,
	NS_USER           => true,
	NS_USER_TALK      => true,
	NS_PROJECT_TALK   => true,
	NS_IMAGE_TALK     => true,
	NS_MEDIAWIKI_TALK => true,
        NS_TEMPLATE       => true,
	NS_TEMPLATE_TALK  => true,
	NS_HELP_TALK      => true,
	NS_CATEGORY_TALK  => true,
       102  => true,
       103  => true
)

Adding extra namespaces

Some extensions, e.g. wikilog or semantic mediawiki use additional namespaces. It is difficult to know what namespaces are used and more so what index number they are.

Read Help:Namespace

To list the prefixes in use of th the use visible namespaces, use the pull-down menu: Special:PrefixIndex
To figure out the index number look at the source of the above page.

E.g. you will see something like this:

<option value="100">Admin</option>
<option value="101">Admin Discussion</option>
<option value="102">STIC</option>
<option value="103">STIC Discussion</option>
<option value="104">Blog</option>
<option value="105">Blog talk</option>
<option value="106">COAP</option>
<option value="107">COAP Discussion</option>
<option value="110">Property</option>
<option value="111">Property talk</option>
<option value="114">Form</option>
<option value="115">Form talk</option>
<option value="116">Concept</option>
<option value="117">Concept talk</option>
<option value="118">Filter</option>
<option value="119">Filter talk</option>

If you want to list 'all' namespaces, use the API, e.g.

api.php?action=query&meta=siteinfo&siprop=namespaces&formatversion=2

Default user preferences

Read Manual:$wgDefaultUserOptions

In a wiki with long pages like this one, you could make numbered titles the default:

$wgDefaultUserOptions['numberheadings'] = 1;

Insert pages edited by a user on their watchlist

$wgDefaultUserOptions['watchdefault'] = 1;

Send email if a watched page is changed (only do this in a small "organizational" wiki ....)

$wgDefaultUserOptions['enotifwatchlistpages'] = 1;

If you change user preferences, you maybe should plan to update the old users. To do so, use a maintenance script:

Updating number headings preferences for all users

In the terminal, type

cd your_mediawiki_directory
php maintenance/userOptions.php numberheadings --old 0 --new 1

Instant Commons

If you wish you could share multimedia files with Wikimedia Commons.

Read InstantCommons

A picture from Wikimedia Commons embedded in this Wiki

In LocalSettings.php:

$wgUseInstantCommons = true;

You then can upload pictures to Wikimedia Commons

Of course, this means that you will have to respect all the requirements of Wikimedia Commons. In brief:

fill in a detailed form
the picture should be of general interest (potentially includable in a Wikipedia or Wikibooks article)
Use an acceptable license: Creative Commons CC-BY-SA, Creative Commons CC-BY license, CC0 Public Dedication 1.0 license. A BY-NC-SA (used per default in this wiki) cannot be accepted. You can only impose "attribution" and "share alike" but not "non-commercial".

Performance tuning

Read:

How to make MediaWiki fast by Aaron Schulz

Moving the wiki to a new machine

I suggest the following steps:

Install all the software dependencies on the new machine (dozens of libraries, languages, etc.)
Configure the web server and other services that are needed (see above for the essentials and below for optional stuff)
Install a wiki test server or export one that you already have
Upgrade the current wiki(s) to a stable and (if possible) most recent version
Then lock the wiki for writing, move it, test it, then move the Internet alias (virtual server) if you keep the old machine alive for some other purpose.

Moving a wiki

Step 1 - Freeze it

Lock it for writing. In LocalSettings.php:

$wgReadOnly = 'Moving the wiki to another machine, back to normal in/at ....';

Step 2 - Dump the database

Exporting, then importing the SQL is probably a better option than copying the binary database files.

Export:

mysqlshow -p -u root // in case you forgot the db name
mysqldump -p -u root data_base > yourwikiDB.sql
gzip yourwikiDB.sql

Move it to the target machine, e.g. use sftp. The "un-gzip" the file again.

gunzip yourwikiDB.sql.gz

Step 3 - Create a new database and import

Create a new database with the same name and permissions

Note: you can identify db_user name and its password by looking at the LocalSettings.php file

$wgDBuser           = "db_user";
$wgDBpassword       = "secret";

MySQL command line commands (";" on a new line so that you can safely copy/paste and change):

 mysql -p -u root
 mysql> create database yourwikiDB
 mysql> ;
 mysql> GRANT INDEX, CREATE, SELECT, INSERT, UPDATE, DELETE, DROP, ALTER, LOCK TABLES, CREATE TEMPORARY TABLES, EXECUTE ON yourwikiDB.* TO 'db_user'@'localhost' IDENTIFIED BY 'secret'
 mysql> ;

Import the database tables and contents

On the Linux command line, type:

mysql -p -u root -D yourwikiDB < yourwikiDB.sql

or alternatively

mysql -p -u db_user -D yourwikiDB < yourwikiDB.sql

This will execute all the SQL commands in the yourwikiDB.sql file and create tables + contents for the yourwikiDB database.

Step 4 (option A) - Archive, then move the files

I prefer option B (see below)
Create a file archive (or move everything in one single step, see below). You could be tempted to move the files before dumping/moving the database in order to get some more uptime. IMHO, you would not gain much. The bulk of the files sit in the images directory and its contents can change as long as users can edit.

cd installation_dir
cd ..
tar zcf wiki_name.tgz installation_dir

Move the files with stfp to the target machine

On the target machine:

 cd /new_parent_directory
 tar xfz wiki_name.tgz

Option B: All-in-one archiving/moving

Works best if you are root and root access is open from your machine, else the file permissions will be wrong. If you cannot, then firstly create a directory on the new server and give it to you.

(cd /data/portails/installation_dir && tar cfz - .)  | ssh root@new.machine 'cd /some/absolute_path/installation_dir && tar xfz -'

Or a variant:

// In the target machine:
mkdir /absolute_path/directory_above
chown to_you:to_group /absolute_path/directory_above

// In the source machine
cd /directory_above_installation
ls -l
tar cfz - installation_dir | ssh root@new.machine 'cd /some/absolute_path/ && tar xfz -'

If you did this without being root, then fix the permissions on the target machine

cd installation_directory
chown www-data:www-data images cache

Tuning

Make the wiki writable again

Comment the $wgReadOnly line, if necessary.

// $wgReadOnly = 'Moving the wiki to another machine, back to normal in/at ....';

Test it

If the pages display and if you can log in, then you can switch the Internet Alias

If your old wiki ran a recent version of MediaWiki, the transfer should go smoothly. Else, you may suffer in the same way as you could suffer after a major OS upgrade. Upgrade the wiki first, then repeat transfer. Also, some extensions may be broken. See debugging.

Verify the configuration file

I also suggest looking at the configuration file and adapt to the changes. Some stuff in there may not hurt, but it could be outdated.

Troubleshooting

Verify that the new database really exists

mysqlshow -p -u root yourwiki

Make sure that the web server permissions are ok
Some extensions may not work with new PHPs. Uncomment all extensions in the LocalSettings.php file and uncomment one by one ...

Extensions installation and configuration principles

See also the Mediawiki article where we list extensions we find useful to have. Here, we only document installation and configuration of the more difficult ones.

Download and documentation: You will find most extensions on MediaWiki.org. The Extensions category page will provide several entry points. I sort of like the Extension_Matrix page.

Most extensions are well documented, just read the instructions and follow them. However, since some are badly maintained you sometimes will have to read the discussion page for finding appropriate patches...

Installing extensions the traditional way

A checklist of things to look at and to do:

(1) Check if the extension is compatible with your MW version (this is not always obvious, therefore you also should look for hints in its dicussion page).

(2) Read the discussion page that will tell you something about the quality of an extension.

(3) Download the extension either as archive (zip etc.) or via GIT (see next item). Some simple extensions are just available as code section from the wiki page that you must copy to a file.

Make sure that the files sit in a directory unless its a simple single file extension

Move the extension directory to the extensions folder of your installation

Add all the extra stuff an extension may need. This can sometimes be a lot of work (e.g. days), sometimes nothing (minutes). Most extensions are simple and don't need other server-side programs.

If the extension needs a cache, you may have to change write permissions in some subdirectory.

(4) Load and configure:

Edit LocalSettings.php to configure and to load the extension.
You may have to define configuration variables in the LocalSettings.php file and/or by defining Mediawiki:XXX pages
You may have the option to add CSS definitions to the MediaWiki:Common.css pages
Some extensions will update the database. In that case it is important to run the update script, something that you should anyhow after each addition and/or upgrade.

php maintenance/update.php

Sometimes you need to define templates, modify the CSS, etc.

Using Git repositories with the method above

Mediawiki git repositories can change over the years, but the principle is the same.

Most extensions are available from the official repository
Its location is often undocumented on the extension page, but you can easily guess it:

As of 2017, the location is

https://gerrit.wikimedia.org/r/p/mediawiki/extensions/ExtensionName.git

e.g.

https://gerrit.wikimedia.org/r/p/mediawiki/extensions/CategoryTree.git

Before, it was:

https://git.wikimedia.org/git/mediawiki/extensions/........

Some links in this document may not be updated yet. E.g. if git.wikimedia.org doesn't work (it should not), try gerrit.wikimedia.org.

Installing extensions with Composer

For MediaWiki installations, younger than mid-november 2013, you should learn how to use composer, a PHP dependency manager. It should work with the following combination of server software:

PHP 5.3.2+
MySQL 5.0.2+
CURL
MediaWiki 1.22 (nov 2013) or better.

If your server doesn't meet these requirements (in particular a new 1.22 MediaWiki), then use the traditional way.

If you run several wikis, it's probably best to install composer on system level:

 cd /some/src
 curl -sS https://getcomposer.org/installer | php
 mv composer.phar /usr/local/bin/composer

Removing old extension versions

Remove the old files in the extensions directory
In LocalSettings.php remove the line that loads the extension, e.g.

require_once( "$IP/extensions/DataValues/DataValues.php" );

Install extensions using composer

Composer is run from the base directory (and not the extensions directory) !!

See the documentation for each extension. Examples:

composer require mediawiki/semantic-media-wiki "1.9.*,>=1.9.0.1"
composer require mediawiki/semantic-media-wiki "~2.0"

Update all extensions using composer.: If the dependencies are right, this should work without worrying about versions.

composer update
- or, for stable versions -
composer update --no-dev

Trouble: If composer updates, but maintenance/update.php balks with "Error: your composer.lock file is not up to date. Run "composer update --no-dev" to install newer dependencies

", try

php maintenance/update.php --skip-external-dependencies

Difficult to install text and graphics extensions

Actually some of these may be quite easy to install. However more than just downloading is always required. Some extensions are sometimes very difficult to install, i.e. they do install but may either not work or break your wiki. Upgrading or downgrading the extension version can help. Upgrading/downgrading the wiki also, but downgrading a wiki is near impossible and not recommended, since the database structure may have changed !

The math extension

The match extension allows to display mathematical formula that are written in Latex. Instructions below may be outdated (i.e. were not checked for MW 1.31)

https://www.mediawiki.org/wiki/Extension:Math

Since several other extensions rely on this and since there is always a chance that you would like to display a formula, it's a good idea to have it. However, this solution has now a better alternative as explained in the configuration section of the extension page e.g. either a server or client-side translator of LateX to MathML and SVG. So far, we did not test how it would fit with the collection extension.

Installation on the Linux side

The following should install auxiliary libraries that are needed plus fonts.

apt-get install build-essential texlive texlive-bibtex-extra\
texlive-font-utils texlive-fonts-extra texlive-latex-extra texlive-math-extra\
texlive-pictures texlive-pstricks texlive-publishers dvipng gsfonts make ocaml ploticus

Extensions installation

1) Download the match extension to the extensions directory

cd extensions
git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/Math.git

2) Adapt to your wiki version

git branch -r
git checkout REL1_31

3) Compile the Mediawiki part.

cd extensions/Math/math
make

3b) Compile texvccheck (do not forget)

cd /data/portails/wikitest/extensions/Math/texvccheck/
make

4) Edit Localsettings.php and add:

# LaTEX
require_once "$IP/extensions/Math/Math.php";
// $wgUseTeX = true;

5) Update

cd your_installation_directory (or change path below)
php maintenance/update.php

Test it: $\sum _{m=1}^{\infty }\sum _{n=1}^{\infty }{\frac {m^{2}\,n}{3^{m}\left(m\,3^{n}+n\,4^{m}\right)}}$

Collection extension and mwlib server

This extension is crucial for an educational wiki. It allows creating print books or just simply print a page in PDF format. The print book can be downloaded as PDF (or optionally in Open document format) or it can be ordered through your wiki as print book from Pediapress.

There exist two ways of using this PDF/OO/DocBook book generator.

The easy strategy is to install just the extension files and use the PediaPress server for generating the PDF or OO documents. This strategy did not work out well and we use our own server.
The other strategy is to install a combo of various services that will collect and generate documents on your own server. Installation is fairly complex.

Detailed instructions for collection and server installation: Mediawiki collection extension installation

Most important documentation and download pages: Extension page Collection: http://www.mediawiki.org/wiki/Extension:Collection; Extension page PDF_Writer: http://www.mediawiki.org/wiki/Extension:PDF_Writer; MwLib/Collection server installation guide (if needed): http://code.pediapress.com/wiki/wiki/mwlib-install

Graphviz

This extension can generate graphs with the dot syntax.

Installation of Graphviz libraries

Most important documentation and download pages: Extension page: http://www.mediawiki.org/wiki/Extension:GraphViz; Extension page for Image map: https://www.mediawiki.org/wiki/Extension:ImageMap; Additional installs: Graphviz from http://www.graphviz.org/Download.php plus needed libraries that you may or may not have on your server

Linux dependencies and installation

Graphviz itself needs several libraries like GD, Zlib, Freetype, PNG, JPEG, EXPAT, etc. (read http://www.graphviz.org/Download_source.php Requirements). The following should get all the dependencies right:

 apt-get install graphviz graphviz-dev

Download and installation of the MW extension

This extensions is installed with composer. The extension also requires the imagemap extension.

composer require mediawiki/graph-viz '*'

You also should image-map if it is not already installed. Note that the MediaWiki documentation claims this to be bundled but I couldn't see any of it. Maybe it's just in the tar balls.

composer require mediawiki/image-map @dev

Trouble

Syntax change for links

If you get a message like this:

Error: No valid link was found at the end of line 2.

then you got a syntax error for the links

In an older version of this extension, the syntax for a label with a link was the following and that is wrong now. The change was made because rendering is now done with the imagemap extension.

"Learning Theory" [URL="Learning theory"];

New syntax:

"Learning Theory" [URL="[[Learning theory]]"];

Models are ugly after upgrading or break

I don't think that there is a good easy solution.

Below you can see the use of nodesep=2 and len=2.0 parameters that may or may not work with your graphviz/extension combination. The model can be found in the 3D printing page, but its parameters may not be the same.

<graphviz caption="Ambitious model">
graph ThreeD_printing_2 {

node [fontsize=10,fontname="Arial",shape=none,nodesep=2];
edge [fontsize=10,fontname="Arial", len=2.0];

# List of nodes
Idea          [shape=box,     color=red, label="Design idea"];
.....

Graphvis is not recognized by the collection extension

i.e. a generated graph will not print in PDF.

Workaround: Put the code in the discussion page, then link to the generated *.png from the page. Example: Stitch Era embroidery software (look at the source code and the discussion page).

Timed Media Handler

The TimedMediaHandler extension allows you to display audio and video files in wiki pages, using the same syntax as for image files. It includes the Kaltura HTML5 Player, which supports integrated standard timed text support, real time stream switching between multiple WebM and Ogg derivatives and many other features. TMH server side support includes multiple transcode profiles, php based medata parsing via PEAR Ogg / OggHandler and getID3 for WebM files, and integrates with mediaWiki's jobQueue system for scheduling transcoding jobs.

https://www.mediawiki.org/wiki/Extension:TimedMediaHandler

The official installation instructions in the extension page are not exactly accurate (the README file is a bit better). As of April 2015, the following did work:

System prerequisites (Ubuntu 14.04LTS)

apt-get install php-pear ffmpeg2theora imagemagick
apt-get install libav-tools

Mediawiki prior to 1.31

Installation wiki

git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/MwEmbedSupport.git
git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/TimedMediaHandler.git

In LocalSettings.php:

# Somewhere in the beginning I guess
ini_set( "include_path", ".:$IP:$IP/includes:$IP/languages:/usr/share/php");

# ---- VIDEO - TimeMediaHandler
# TimedMediaHandler is dependent on mwEmbedSupport 
require_once( "$IP/extensions/MwEmbedSupport/MwEmbedSupport.php" );
#TimedMediaHandler
require_once( "$IP/extensions/TimedMediaHandler/TimedMediaHandler.php" );

#  Adjust file extensions, e.g.
$wgFileExtensions = array( 'png', 'gif', 'jpg', 'jpeg', 'ogg', 'pdf', 'mp3', 'svg', 'doc', 'xls', 'ppt', 'pub', 'txt', 'ps', 'zip', 'ogg', 'ogv', 'mp4', 'webm' );

Mediawiki > 1.31

Installation wiki

git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/TimedMediaHandler.git

cd TimedMediaHandler

Update composer within the extension directory. Normally this should be done by the update script if I am not wrong ....

composer update

In LocalSettings.php:

# Somewhere in the beginning I guess
ini_set( "include_path", ".:$IP:$IP/includes:$IP/languages:/usr/share/php");

# ---- VIDEO - TimeMediaHandler
wfLoadExtension ('TimedMediaHandler');

#  Adjust file extensions, e.g.
$wgFileExtensions = array( 'png', 'gif', 'jpg', 'jpeg', 'ogg', 'pdf', 'mp3', 'svg', 'doc', 'xls', 'ppt', 'pub', 'txt', 'ps', 'zip', 'ogg', 'ogv', 'mp4', 'webm' );

Update

Cannot hurt:

cd your_installation_directory
php maintenance/update.php

Semantic Mediawiki (SMW) and SMW extensions

Explained in a different article:

Read Semantic MediaWiki

Below just the short form we sometimes used (adapt the version numbers).:

cd your_installation_directory
composer require mediawiki/semantic-media-wiki "~2.0"
composer require mediawiki/maps "*"
composer require mediawiki/semantic-maps "*"
composer require mediawiki/semantic-forms
composer require mediawiki/semantic-result-formats "*"
php maintenance/update.php

cd extensions
git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/SemanticFormsInputs.git
git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/SemanticDrilldown.git
# if not already done so
# git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/AdminLinks.git
cd ..
php maintenance/update.php

Alternatively, edit the composer.json file. As of Sept 2016, ours looks like this:

"mediawiki/semantic-media-wiki": "~2.5",
"mediawiki/maps": "~5.1",
"mediawiki/semantic-result-formats": "~2.5",
"mediawiki/sub-page-list": "~1.5",
"mediawiki/graph-viz": "*",
"mediawiki/image-map": "dev-master"

But that can change anytime, e.g. in principle one could include page forms also, but last time we tried it did not work well...

In LocalSettings.php

# ---- Semantic MediaWiki

$smwgNamespaceIndex = 108;
enableSemantics('edutechwiki.unige.ch'); // adjust to yours
$smwgShowFactbox = SMW_FACTBOX_NONEMPTY;

$shcAgreedToHCLicense = true;

// include_once("$IP/extensions/SemanticForms/SemanticForms.php");
wfLoadExtension( 'PageForms' );

# If one or more of your fields can contain internal links entered by users (e.g., "This is a [[cat]]")
$smwgLinksInValues = true;
 
# Semantic Drilldown. Needs yet another namespace
$sdgNamespaceIndex = 118;
include_once("$IP/extensions/SemanticDrilldown/SemanticDrilldown.php");
 
# Semantic Forms Inputs. Since fall 2015, I use composer for this
# require_once("$IP/extensions/SemanticFormsInputs/SemanticFormsInputs.php");

Visual Editor

Installing the Visual Editor requires a JavaScript server, i.e. you either need a hosting service that provides node.js or full access to a machine. It also requires MW 1.24 or better. Visual Editor doesn't integrate SemanticMediaWiki, but it can deal with templates. Therefore, if you want to use both in a Wiki, use templates to define SMW properties.

Installation

Is explained in VisualEditor

CategoryTree

updated for REL1_29 / Nov 2017, check for REL1_31 upgrade. It seems that this extension is now included in the standard distribution.

Allows to create menus of categories and its members. Adds a "CMS" like layer to the wiki

Installation

git clone https://git.wikimedia.org/git/mediawiki/extensions/CategoryTree.git

In Localsettings.php (version 29 >)

wfLoadExtension( 'CategoryTree' );

In Localsettings.php (version 1.27 or older)

$wgUseAjax = true; // not sure if which versions this is required
require_once("{$IP}/extensions/CategoryTree/CategoryTree.php");

If you use a Categorytree in the sidebar, you will have to give the name of a category. In this wiki I tagged all content categories with category "Contents".

$wgCategoryTreeSidebarRoot = "Contents";
$wgCategoryTreeSidebarOptions['mode']=CT_MODE_CATEGORIES;

Other options I use:

$wgCategoryTreeForceHeaders = true;
$wgCategoryTreeDynamicTag = false;
$wgCategoryTreeDisableCache = false;
$wgCategoryTreeMaxDepth = array(CT_MODE_PAGES => 2, CT_MODE_ALL => 2, CT_MODE_CATEGORIES => 3);

System and administrative extensions

WikiEditor

Provides a better Edit bar that includes more buttons. Must-have for an educational wiki

cd extensions
git clone ssh://gerrit.wikimedia.org:29418/mediawiki/extensions/WikiEditor

old: git clone https://git.wikimedia.org/git/mediawiki/extensions/WikiEditor.git

In LocalSettings.php

require_once "$IP/extensions/WikiEditor/WikiEditor.php";
# To enable a preference by default but still allow users to disable it in preferences, use something like...
$wgDefaultUserOptions['usebetatoolbar'] = 1;
$wgDefaultUserOptions['usebetatoolbar-cgd'] = 1;
$wgDefaultUserOptions['wikieditor-preview'] = 1;

Parser Functions

Are essential if plan to write templates. Some advanced extensions also may use these.

https://www.mediawiki.org/wiki/Extension:ParserFunctions

git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/ParserFunctions.git

In LocalSettings.php:

require_once "$IP/extensions/ParserFunctions/ParserFunctions.php";
# For programming templates the following could be handy (but can cost CPU when used):
$wgPFEnableStringFunctions = true;

Debugging

You can expand the template with the ExpandTemplates page that can be found in the Special Pages ([[[Special:ExpandTemplates]]]). Different name in other languages !

Scribunto

Scribunto is a Mediawiki extension that allows end-user (within-wiki) scripting. It currently supports the lua language. Scribuntu is an alternative to programming with templates and parser extensions, i.e. it's easier to learn and to use. .

E.g. on Wikipedia, the citation modules are programmed with that.

Prerequisites

lua must be installed in your system, e.g. in Ubuntu, type:

sudo apt-get install lua5.1

Installation via GIT

cd extensions
git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/Scribunto.git

// adapt to your OS
chmod a+x Scribunto/engines/LuaStandalone/binaries/lua5_1_5_linux_64_generic/lua

Adapt to your wiki version, e.g.

git checkout origin/REL1_25 -b REL1_25

If you forget this, then you likely will see a blank screen when you try to save a module page.

Configuration

In Localsettings.php:

require_once "$IP/extensions/Scribunto/Scribunto.php";
$wgScribuntoDefaultEngine = 'luastandalone';

Via composer As of March 8 2016, the following did not work:

composer require mediawiki/scribunto "composer/installers: >=1.0.1"

https://www.mediawiki.org/wiki/Extension:CodeEditor

Code Editor

The CodeEditor extension extends the WikiEditor advanced editing toolbar with an embedded Ace editor widget, providing some handy features for user/site JS, CSS pages, and when Extension:Scribunto is also installed, for pages in Module namespace.

git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/CodeEditor

In LocalSettings.php

require_once "$IP/extensions/CodeEditor/CodeEditor.php";
$wgCodeEditorEnableCore = true;
$wgScribuntoUseCodeEditor = true;

We found this extensions particularly useful to edit MediaWiki:Common.css since it provides CSS tips and warnings. This extensions, however does not provide any support for editing (much more difficult) template code.

Admin links

Adds a special page with useful links to administration. The link to this page appears on top right.

composer require "enterprisemediawiki/admin-links" "dev-master"

Regexp Functions

The Regex Fun extension provides four new parser functions for performing regular expression handling within wiki pages. Useful for template programming.

https://www.mediawiki.org/wiki/Extension:Regex_Fun

git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/RegexFun.git

In LocalSettings.php:

require_once( "$IP/extensions/RegexFun/RegexFun.php" );

Interwiki

The Interwiki extension allows to edit the interwiki database table, that we use for example to create short links to the french sister version using the :fr prefix or to link to a WikiPedia article using :WikiPedia.

In LocalSettings:

wfLoadExtension( 'Interwiki' );
$wgGroupPermissions['sysop']['interwiki'] = true;

My Variables

The MyVariables extension adds new built-in variables which are very handy if you plan to "program" templates.

E.g. {{CURRENTUSER}} produces: 3.135.206.166

https://www.mediawiki.org/wiki/Extension:MyVariables

git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/MyVariables.git

In LocalSettings.php:

require_once "$IP/extensions/MyVariables/MyVariables.php";

Check user

Allows administrators to retrieve some information about suspicious users. Only important for a relatively open wiki.

git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/CheckUser.git

In LocalSettings.php

include_once("$IP/extensions/CheckUser/CheckUser.php");

Rename user

In an educational context it's important to be able to "fix" user names. Often, students just pick an ugly "mail account" type of name and then want to change

git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/Renameuser.git
// adapt
git checkout REL1_29

In Localsettings.php

wfLoadExtension( 'Renameuser' );

In Localsettings (OLD versions)

include_once('$IP/extensions/Renameuser/SpecialRenameuser.php');

MassEdit Regexp

Allows administrators to make mass find/replaces throughout the whole wiki, using regular expressions.

MassEditRegex allows to change expressions in multiple pages. Very useful for instance, if you plan to add/remove or rename categories. Replace Text is another alternative that probably has similar functionality (not tested yet).

git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/MassEditRegex.git

In LocalSettings:

include_once("$IP/extensions/MassEditRegex/MassEditRegex.php");
$wgGroupPermissions['sysop']['masseditregex'] = true;

Replace Text

This extension has similar functionality as the above one. It also allows searching through a whole name space, i.e. you do not need to enter page names.

Replace Text

Installation:

cd extensions
git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/ReplaceText

In LocalSettings:

wfLoadExtension( 'ReplaceText' );
$wgGroupPermissions['bureaucrat']['replacetext'] = true; // optional to give this right to bureacrats

User merge

It can happen that some contributors have more than one account since they forgot their old login or maybe because they want to change their name and cannot do it by themselves.

The UserMerge extension allows to:

merge (refer contributions, texts, watchlists, edit count of a first account A to a second account B
delete the first account A after the merge (option box)

cd extensions 
git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/UserMerge
// adapt
git checkout REL1_29

In LocalSettings.php:

wfLoadExtension( 'UserMerge' );
// By default nobody can use this function, enable for bureaucrat?
$wgGroupPermissions['bureaucrat']['usermerge'] = true;

Deleting users

Users that did contribute should not be deleted but just blocked. All edits must have a user, this is why. So, there are neither maintenance scripts to do that nor extensions.

However, you can merge all unwanted users into one with the UserMerge extension (see above), but this is tedidious.
You could remove a user from the database, but that is not recommended.

See also: You can kill spam pages with the Nuke extension for a given user.

Easy to install extensions to enhance page contents

Discussion Threading

Works OK with MW 1.31 (sept. 2018)

This extension that will modify the discussion pages and make it look like traditional hierarchical forums (that did work very well in the past and are now replaced by php/mysql horrors....). The pages are still real wiki pages and can be edited as such. This makes this extension less intrusive than various other alternatives like liquidthreads.

Minimal threading - Subject headings are used to identify what discussion a particular comment belongs to. These headings are not dated and cannot be sorted.
Users explicitly sign their comments - signatures are automatically added to the discussions.
Transparent response mechanism - users can reply to existing comments or create new ones using the [new][edit][reply]
Conversation tracking - the [reply] allows users to specify existing objects (sections) in the system, and effectively track comments one has left, responses received (regardless of the location), and so on.

Installation:

git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/DiscussionThreading.git

In LocalSettings.php:

wfLoadExtension( 'DiscussionThreading' );
// old Mediawikis < 1.24
// require_once("$IP/extensions/DiscussionThreading/DiscussionThreading.php");

Warning: If you also installed VisualEditor, this line must be inserted after the Visual Editor code... or you won't see any buttons.

Notice

This extension was broken somtimes in the past. We do not know if new fixes repair old Mediwiki versions. If not, you can do manual fixes as we did. See the discussion page of this extension.

You also can consider installing other extensions, like Flow (used on Wikipedia), but these require longer list of prerequisites.

Embedd Video

Allows to embed videos from various services, such as YouTube.

Installation (fix the installation directory)

 git clone https://github.com/Alexia/mediawiki-embedvideo
 mv mediawiki-embedvideo EmbedVideo

In LocalSettings;

require_once "$IP/extensions/EmbedVideo/EmbedVideo.php";

Read the extension page

Syntax highlight

SyntaxHighlight allows to display various kinds of computer code. A must have for technical wikis, also useful to get better rendering for the Collection extension.

https://www.mediawiki.org/wiki/Extension:SyntaxHighlight_GeSHi

Installing it the traditional way

cd extensions
git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/SyntaxHighlight_GeSHi.git

Starting MW 1.26 you also must update the downloaded files with composer:

cd ../extensions/SyntaxHighlight_GeSHi/"
composer install

In Localsettings.php add:

require_once "$IP/extensions/SyntaxHighlight_GeSHi/SyntaxHighlight_GeSHi.php";

Installing it via composer (MW 1.26+)

Hand edit the composer.json file in the root directory and do as instructed in the official instructions. I got the following code fragment:

"extra": {
    "merge-plugin": {
            "include": [
                  "composer.local.json",
                  "extensions/SyntaxHighlight_GeSHi/composer.json"
                       ],
            "merge-dev": false
                    }
        }

Then type:

composer update

In Localsettings.php add:

wfLoadExtension( 'SyntaxHighlight_GeSHi' );

Tuning

In addition you could restyle the way boxes appear by editing MediaWiki:Common.css

div.mw-geshi {
  padding: 1em; 
  margin: 0 0; 
  border: 1px dashed #2f6fab;
  background-color: #f9f9f9;
}

Subpage list

If you allow subpages, it's good to be able to list them like this:

{{subpages:}}

https://github.com/JeroenDeDauw/SubPageList/blob/master/doc/USAGE.md

Installation:

composer require "mediawiki/sub-page-list" "*@dev"

This will actually install a whole bunch of other extensions, if you don't already have them (data-values, param-processor, ...)

Cite

The Cite extension allows a user to create references as footnotes on a page. It adds two parser hooks to MediaWiki, <ref> and <references /> , these operate together to add citations to pages.

https://www.mediawiki.org/wiki/Extension:Cite

git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/Cite.git

In LocalSettings

include_once("$IP/extensions/Cite/Cite.php");

In installation directory

php maintenance/update.php

Cite this page

Helps people citing correctly a page.

cd extensions
git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/CiteThisPage

In LocalSettings

require_once "$IP/extensions/CiteThisPage/CiteThisPage.php";

You then should include the item in the menu to the left.

Edit MediaWiki:Sidebar

Wikilog

Old version

Wikilog is an extension that implements blogs within the wiki. Useful for various purposes like announcements, personal blogs, etc. Blogs use their own namespaced pages, but postings can be transcluded into wiki pages.

https://www.mediawiki.org/wiki/Extension:Wikilog

Installation:

git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/Wikilog.git

In LocalSettings.php

require_once( 'extensions/Wikilog/Wikilog.php' );
Wikilog::setupNamespace( 104, 'Blog', 'Blog_talk' ); // one of these two should be redundant.
Wikilog::setupBlogNamespace( 100 );

Linux:

cd installation dir
php maintenance/update.php
# to get some documentation (broken as of April 2015)
php extensions/Wikilog/maintenance/wikilogImportDocumentation.php

In addition you should create templates

New version

As of 2015, there is a new version with more features. It does seem to work with MW 1.25.5 (c1fa430)

https://github.com/mediawiki4intranet/Wikilog

It uses different tables, i.e. there won't be any going back ?

  php maintenance/patchSql.php extensions/Wikilog/archives/fill-wikilog-comment-meta.sql

In order to install this, you also must make sure that MySQL Can create temporary tables

mysql -p
GRANT CREATE TEMPORARY TABLES, EXECUTE ON `wikitest` . * TO 'wiki'@'localhost';

In LocalSettings.php

require_once( 'extensions/Wikilog/Wikilog.php' );
Wikilog::setupNamespace( 104, 'Blog', 'Blog_talk' ); // one of these two should be redundant.
Wikilog::setupBlogNamespace( 100 );

Old Version - current status

After upgrading to MW 1.31, this extension is broken in this wiki. E.g.

Internal error

[e67cd310954dee06608ec8cd] /en/Blog:DKS/Changes_in_the_search_functionality_and_upgrades_in_the_near_future Error from line 544 of /data/portails/mediawiki/extensions/Wikilog/WikilogCommentsPage.php: Call to undefined method SkinVector::userLink()

Backtrace:

#0 /data/portails/mediawiki/extensions/Wikilog/WikilogCommentsPage.php(331): WikilogCommentsPage->getPostCommentForm(boolean)
#1 /data/portails/mediawiki/extensions/Wikilog/WikilogCommentsPage.php(198): WikilogCommentsPage->viewComments(WikilogCommentQuery)
#2 /data/portails/mediawiki/extensions/Wikilog/WikilogItemPage.php(130): WikilogCommentsPage->outputComments()
#3 /data/portails/mediawiki/includes/actions/ViewAction.php(68): WikilogItemPage->view()
#4 /data/portails/mediawiki/includes/MediaWiki.php(500): ViewAction->show()
#5 /data/portails/mediawiki/includes/MediaWiki.php(294): MediaWiki->performAction(WikilogItemPage, Title)
#6 /data/portails/mediawiki/includes/MediaWiki.php(861): MediaWiki->performRequest()
#7 /data/portails/mediawiki/includes/MediaWiki.php(524): MediaWiki->main()
#8 /data/portails/mediawiki/index.php(42): MediaWiki->run()
#9 {main}

I fixed that error by replacing line 544 like this (no idea why it should work since I do not develop code, I just know a bit how to read code)

// changed DKS
Linker::userLink( $wgUser->getId(), $wgUser->getName() ) 
// $this->mSkin->userLink( $wgUser->getId(), $wgUser->getName() )

Also a warning:

Warning: array_splice() expects parameter 2 to be integer, string given in /data/portails/mediawiki/extensions/Wikilog/Wikilog.php on line 388

I "fixed" this by commenting out the line. This will then create some logical bug I guess....

Finally, articles cannot be saved anymore, i.e. the remain drafts. Workaround; Manually insert a template like this: {{wl-publish: 2018-09-13 18:08:44 +0200 | Daniel K. Schneider }}

RSS extension

Allows to include RSS feeds. Doesn't work that well with respect to filtering out code from certain types of feeds, but it can be useful in project-oriented courses where learners are supposed to keep in touch with various feeds.

https://www.mediawiki.org/wiki/Extension:RSS

Installation:

cd extensions
git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/RSS.git

In LocalSettings.php

require_once("extensions/RSS/RSS.php");

Configuration

The extension page describes several configuration options, also for layout. The most important (mandatory) one is $wgRSSUrlWhitelist that allows to specify which feeds are authorized.

# allow any feed
$wgRSSUrlWhitelist=array("*");

To adapt display one should define the following templates (not yet done ...)

STL extension

There are several 3D extensions and some can do STL.

We use StlHandler. It works, but doesn't create thumbnails. Ideally it should create 3D thumbnails.

Maybe we also should test 3DAlloy.

All these extensions may slow down your wiki (to be investigated)

Dynamic Page List 3

Dynamic page list allows creating various dynamic page list and also to do maintenance operations.

Extension:DynamicPageList3
Source on GitHub. It includes configuration information and basic use.
complete manual at GamePedia.

Installation (as of oct. 2018)

git clone https://github.com/Alexia/DynamicPageList.git
git checkout REL1_31

In Localsettings.php:

wfLoadExtension( 'DynamicPageList' );
// configuration
$wgDplSettings['functionalRichness'] = 2

Google Analytics

Google Analytics allows to study user behaviors and demographics. If compatible with your privacy concerns you can install it.

Firstly you will need a Google account and then register your website
Retrieve the Tracking ID number, e.g. UA-1234567-1

cd extensions
git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/googleAnalytics.git
// adjust your branch
git branch -r
git checkout REL1_25

Minimal configuration in LocalSettings.php

require_once "$IP/extensions/googleAnalytics/googleAnalytics.php";
// REPLACE BY YOUR TRACKING NUMBER below
$wgGoogleAnalyticsAccount = 'UA-12345678-1'; 
$wgGoogleAnalyticsIgnoreSpecials = array( 'Userlogin', 'Userlogout', 'Preferences', 'ChangePassword');

Extensions about users

Contribution Scores

The Contribution Scores extension polls the wiki database to locate contributors with the highest contribution volume – it is also in stable use on a high-volume wiki such as translatewiki.net. The extension is intended to add a fun metric for contributors to see how much they are helping out. The score is defined as (number of unique pages edited) + 2 * square root ((number of edits) - (number of unique pages edited)).

git clone  https://git.wikimedia.org/git/mediawiki/extensions/ContributionScores.git

In Localsettings.php:

require_once("$IP/extensions/ContributionScores/ContributionScores.php");
# Some configuration options we use
$wgContribScoreIgnoreBots = true;        // Exclude Bots from the reporting 
$wgContribScoreIgnoreBlockedUsers = true;  // Exclude Blocked Users from the reporting 
$wgContribScoresUseRealName = true;        // Use real user names when available
$wgContribScoreDisableCache = false;       // Set to true to disable cache for parser function and inclusion of table.

Example:

http://edutechwiki.unige.ch/fr/Accueil

Other extensions / not officially maintained

As we said before, many extensions are really simple to install and don't need any difficult work. See the Special:Version page for the ones we currently use.

Most extensions we use and that are displayed in the Version page provide an URL that will directly lead you to the extensions download and documentation page.

Some extensions are no longer maintained but still work. Do not count on these ....

PageBy

The PageBy extension provides a custom tag, <pageby>, that renders as a summary of the pages edit history. It may be useful to provide a quick overview of who contributed to a page, especially on site with editorial nature, like news reports, blogs, etc.

https://www.mediawiki.org/wiki/Extension:PageBy

Warning: This extension is fragile, e.g. it may not run in your wiki !! In this wiki, as of version 1.27, this extension is broken

Installation:

In case you don't have svn (the version control system used prior to GitHub):

apt-get install subversion

svn co https://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/PageBy/

In LocalSettings.php

require_once("extensions/PageBy/PageBy.php");

Test: <pageby/>

Problems

User name not found

User names are not found after an upgrade, e.g. the user cannot log in and the wiki attempts to create a new user and then fails. Ghis happened to us on on wiki, migrating from 1.27 to 1.35

Fix:

cd maintenance
php resetUserTokens.php

resetUserTokens.php file is a maintenance script to reset the user_token of users on the wiki. On the one hand it can reset the token for all users. Note that this may log some of them out. Resetting all tokens is not necessary unless you believe your user table has been compromised. On the other hand you can use the script to change those tokens, which currently are NULL. This is useful to improve security for the affected users.