# Difference between revisions of "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";


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;  #### 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. ### 1.3 Additional web services 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> 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 #### 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 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  ### 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) • 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)  ## 2 Mediawiki Installation with GIT ### 2.1 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. 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 ! ### 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

wfLoadSkin( 'Vector' );


or maybe:

 wfLoadSkin( 'vector' );


In older installation it was:

require_once "$IP/skins/Vector/Vector.php";  ## 3 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. ### 3.1 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. Around line 1542 of file includes/upload/UploadBase.php xmlns:inkstitch="http://inkstitch.org/namespace"  ## 4 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  See also: Semantic mediawiki 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. ## 5 Configuration ### 5.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). Reading: 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;

$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  ### 5.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');  ### 5.5 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. (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;  ### 5.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. #### 5.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 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) #### 5.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";
$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

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;  #### 5.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. #### 5.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  ### 5.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:

### 5.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 = " ........ ";


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


git checkout REL1_31


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  ### 5.10 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 ....) ### 5.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. Read: 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 )  ### 5.12 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. • 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  ### 5.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


### 5.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.15 Performance tuning Read: ## 6 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. ### 6.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";$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


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

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

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

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

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

### 7.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  ## 8 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 ! ### 8.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 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: ${\displaystyle \sum _{m=1}^{\infty }\sum _{n=1}^{\infty }{\frac {m^{2}\,n}{3^{m}\left(m\,3^{n}+n\,4^{m}\right)}}}$ ### 8.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 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 ### 8.3 Graphviz This extension can generate graphs with the dot syntax. #### 8.3.1 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  #### 8.3.2 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  #### 8.3.3 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). ### 8.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  #### 8.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' );  #### 8.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

#  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  ### 8.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 # 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;
$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");  ### 8.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 ### 8.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);  ## 9 System and administrative extensions ### 9.1 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  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;  ### 9.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):
$wgScribuntoDefaultEngine = 'luastandalone';  Via composer As of March 8 2016, the following did not work: composer require mediawiki/scribunto "composer/installers: >=1.0.1"  ### 9.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;$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.

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


### 9.6 Regexp Functions

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

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


In LocalSettings.php:



### 9.8 My Variables

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

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

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


In LocalSettings.php:



### 9.10 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
git checkout REL1_29


In Localsettings.php

wfLoadExtension( 'Renameuser' );


In Localsettings (OLD versions)



### 9.13 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
git checkout REL1_29


In LocalSettings.php:

wfLoadExtension( 'UserMerge' );
// By default nobody can use this function, enable for bureaucrat?
$wgGroupPermissions['bureaucrat']['usermerge'] = true;  ### 9.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. ## 10 Easy to install extensions to enhance page contents ### 10.1 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][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.

### 10.2 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";  ### 10.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. 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


wfLoadExtension( 'SyntaxHighlight_GeSHi' );


Tuning

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

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


### 10.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, ...)

### 10.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  ### 10.6 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.

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

Backtrace:

#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 }} ### 10.8 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. 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 ...) ### 10.9 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) ### 10.10 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;
}
.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.

### 10.11 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' );
// configuration
$wgDplSettings['functionalRichness'] = 2  ### 10.12 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');


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

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

### 12.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/>