# Mediawiki installation

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

## 1 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


### 1.1 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

### 1.2 Prior to installing MediaWiki

#### 1.2.1 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


#### 1.2.2 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


#### 1.2.3 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";


#### 1.2.4 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.

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

#### 1.3.1 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.

#### 1.3.2 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

### 1.4 Web server configuration and mediawiki directories

#### 1.4.1 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

#### 1.4.2 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>
ServerName YOUR.VIRTUALSERVER.DOMAIN
ServerSignature Off
DocumentRoot /web

<Directory />
AllowOverride All
</Directory>

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

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

ErrorLog /var/log/apache2/error.log

# Possible values include: debug, info, notice, warn, error, crit,
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

#### 1.4.3 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


#### 1.4.4 PHP configuration

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


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


### 1.5 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)

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
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)


## 2 Mediawiki Installation with GIT

Step 1

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

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.

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/p/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 !

### 2.2 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)

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";


## 3 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


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

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


Tips for creating somewhat safer upgrades

• Upgrade to a different directory, then copy the files
• Backup the database (dump it)

See ManageMediaWiki for some rather chaotic additional tips.

## 4 Configuration

### 4.1 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).

List of default settings (source code)

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

### 4.2 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.

### 4.3 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

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>
ServerName YOUR.VIRTUALSERVER.DOMAIN

<Directory />
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:Search
Disallow: /wt/Special:WhosOnline


### 4.4 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');


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.

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;


### 4.6 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
• 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.

#### 4.6.1 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.

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

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)

#### 4.6.2 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 = '....';

/*
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;


#### 4.6.3 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.

#### 4.6.4 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


### 4.7 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).

1. List all messages with the special page Special:Allmessages
2. 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: ### 4.8 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)

In LocalSettings.php, set

$wgSiteNotice = " ........ ";  ### 4.9 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


### 4.10 Changes to the navigation sidebar to the left

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

* SEARCH

** mainpage|Mainpage
<!-- ** 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 ?

** 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 ....)

### 4.11 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.

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
)


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.

• 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="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


### 4.13 Default user preferences

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  ### 4.14 Instant Commons If you wish you could share multimedia files with Wikimedia Commons. 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".

## 5 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
• 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.

### 5.1 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";
// $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 ... ## 6 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... ### 6.1 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. ### 6.2 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. ### 6.3 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


## 7 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 !

### 7.1 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)

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

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


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


# 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: ${\displaystyle \sum _{m=1}^{\infty }\sum _{n=1}^{\infty }{\frac {m^{2}\,n}{3^{m}\left(m\,3^{n}+n\,4^{m}\right)}}}$

### 7.2 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.

1. 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.
2. 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
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

### 7.3 Graphviz

This extension can generate graphs with the dot syntax.

#### 7.3.1 Installation of Graphviz libraries

Extension page: http://www.mediawiki.org/wiki/Extension:GraphViz
Extension page for Image map: https://www.mediawiki.org/wiki/Extension:ImageMap

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


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


#### 7.3.3 Trouble

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).

### 7.4 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.

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


#### 7.4.1 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' );


#### 7.4.2 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


### 7.5 Semantic Mediawiki (SMW) and SMW extensions

Explained in a different article:

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
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");

# 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");


### 7.6 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

### 7.7 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);


## 8 System and administrative extensions

### 8.1 WikiEditor

• Provides a better Edit bar that includes more buttons. Must-have for an educational wiki
cd extensions
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;


### 8.2 Parser Functions

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

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;


### 8.3 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


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"


### 8.4 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;


### 8.7 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' );


### 8.9 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



### 8.11 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;


### 8.12 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.

Installation:

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


In LocalSettings:

wfLoadExtension( 'ReplaceText' );


### 8.14 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.

## 9 Easy to install extensions to enhance page contents

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][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


### 9.3 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.

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


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; }  ### 9.4 Subpage list If you allow subpages, it's good to be able to list them like this: {{subpages:}}  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, ...) ### 9.5 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. 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


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. ### 9.7 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. 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) • 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 }}

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.

Installation:

cd extensions


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 ...)

### 9.9 Tag cloud

This extension will display a tag cloud with all categories of your wiki

Install:

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


LocalSettings.php

require_once "IP/extensions/WikiCategoryTagCloud/WikiCategoryTagCloud.php";  Hints: • If you want an accurate cloud that is auto-update without edits, you should create/edit the MediaWiki:Tagcloudpages page and add the pages to invalidate the cache for. • For styling, edit MediaWiki:Common.css and do something links this: /* CSS placed here will be applied to all skins */ .tagcloud { width: 98%; text-align: center; background-color: #FDFDFD; border: 1px solid #EEEEEE; padding: 15px 10px 15px 10px; } .tagcloud a { color: #0052CB; margin-left: 10px; margin-right: 10px; font-weight: bold; }  Use of tagcloud: Insert <tagcloud></tagcloud> • You should probably filter out some categories, using this non-XML syntax: <tagcloud> min_size=55 exclude=Category1,category2 </tagcloud>  Typically, you could exclude all maintenance categories. ### 9.10 Dynamic Page List 3 Dynamic page list allows creating various dynamic page list and also to do maintenance operations. Installation (as of oct. 2018) git clone https://github.com/Alexia/DynamicPageList.git git checkout REL1_31  In Localsettings.php: wfLoadExtension( 'DynamicPageList' ); // configurationwgDplSettings['functionalRichness'] = 2



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 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');  See also: ## 10 Extensions about users ### 10.1 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:

## 11 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 ....

### 11.1 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.

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:

1. 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/>