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
See also:
- Older more chaotic installation hints can be found in ManageMediaWiki
- General information about MediaWiki and nice extensions can be found in the Mediawiki article
- Mediawiki collection extension installation (tips for the "PDF/Pediapress books extension)
- Semantic MediaWiki and Semantic Forms (some stuff about these very ambitious extensions)
- VisualEditor. How to install the visual editor (rather difficult)
- Category:Mediawiki documentation (everything)
First time installation of essential Ubuntu/Debian software
I recommend first installing your favorite text editor (I have been using the same thing for the last 30+ years: emacs). A simple editor like pico (alias nano) can do. If you don't know how to use vi or vim, avoid !
apt-get install nano
Prerequisites
- Starting point: Ubuntu 16.04.x LTS
- PHP/Apache/MySQL and curl installed
- PHPMyAdmin installed (not really needed)
To see what packages are installed, you could use for example:
sudo apt-cache showpkg apache2 mysql-server php php-mysql libapache2-mod-php php-cli phpmyadmin
- or
dpkg -l | egrep 'apache2|mysql-server|php|php-mysql|libapache2-mod-php|php-cli|phpmyadmin'
To install Apache/PHP/MySQL, try something like this (if needed). Ubuntu 16 now officially supports PHP7, but after an upgrade I still found php5 around.
sudo apt-get install apache2 mysql-server php php-mysql libapache2-mod-php php-cli phpmyadmin
- Sendmail (postfix) must be installed and configured
- Check if /etc/postfix is there
Prior to installing MediaWiki
Git
Git is Revision control system and is needed to download MW and extension software and to manage versions. You could do it the traditional way (e.g. download file archives), but using git can save time.
apt-get install git
Composer
Composer is a PHP package management system and it is needed to manage some important Mediawiki extensions
- You can download it to any directory (here I used "/src"), but then the composer.phar file should be copied to /usr/local/composer
mkdir /src cd /src curl -sS https://getcomposer.org/installer | php # testing ./composer.phar # installing mv composer.phar /usr/local/bin/composer # testing composer self-update
Essential libraries
This section lists all sorts of libraries you need to have if you plan to use extensions. It is better to have them installed before installing the Mediawiki, since the installation script can detect and configure these
- php-intl provides unicode support
- imagemagick allows to create thumbnails.
sudo apt-get install php-intl imagemagick #restart is needed !! apache2ctl restart
You then also should configure the LocalSettings.php file to use Imagemagik for rendering SVG files.
- Read SVG in the Image Manual.
Finding a solution that both works and produces acceptable quality can be fairly difficult.
- batik is difficult to install (complains about security)
- ImageMagik cannot deal with certain SVG
- rsvg is today maybe the best compromise
sudo apt-get install librsvg2-bin
In your Local file use something like this. You may have to adapt the executable path, e.g. rsvg is called rsvg-convert in Ubuntu.
# SVG conversion
$wgMaxShellMemory = 512000
# $wgMaxShellMemory = 5000000;
$wgAllowTitlesInSVG = true;
$wgSVGConverters = array(
'ImageMagick' => '/usr/bin/convert -background white -thumbnail $widthx$height\! $input PNG:$output',
'batik' => '/usr/bin/java -Djava.awt.headless=true -jar /usr/share/java/batik-rasterizer.jar -w $width -d $output $input',
'rsvg' => '/usr/bin/rsvg -w $width -h $height $input $output'
);
$wgSVGConverter = "rsvg";
# Batik - best results but slow
# $wgSVGConverter = "batik";
# $wgSVGConverter = "ImageMagik";
Currently, we use the following under Ubuntu 18LTS and MW 1.31
# SVG conversion
# $wgMaxShellMemory = 512000
$wgMaxShellMemory = 5000000;
$wgAllowTitlesInSVG = true;
$wgSVGConverters = array(
'ImageMagick' => '/usr/bin/convert -background white -thumbnail $widthx$height\! $input PNG:$output',
'batik' => '/usr/bin/java -Djava.awt.headless=true -jar /usr/share/java/batik-rasterizer.jar -w $width -d $output $input',
'rsvg' => '/usr/bin/rsvg-convert -w $width -h $height -o $output $input'
);
$wgSVGConverter = "rsvg";
# Batik - best results but slow
# $wgSVGConverter = "batik";
# $wgSVGConverter = "ImageMagik";
Finally, make sure that your wiki can deal with large SVG Files
# hack pour un bug https://phabricator.miraheze.org/T3278
# I multiplied the size by 4, e.g. 1M instead of 256K
$wgSVGMetadataCutoff = 1000000;
Choosing a release
In principle one should use the latest stable release when you install a new wiki. This way you are fairly sure that new extensions you will install should last a bit. Alternatively, install the latest long term version (see next item).
We then recommend upgrading to each new release until you reach an LTS (long term support) version. Once you have an LTS installed you can wait about two years before upgrading to the next LTS. As of Sept 2018, use 1.31 LTS. IKt should last until June 2021. Read Version lifecycle release policy from Mediwiki.org for more information.
Additional web services
These are optional, but required by some extensions (see in the extension chapter below)
Node.js
This is a JavaScript web server and is needed for the VisualEditor
Its installation is explained in VisualEditor, since it is is needed for that extension.
Mw-lib
Is needed to run a local PDH / DocBook server and it works with the Collection extension.
Its installation and configuration is explained in Mediawiki collection extension installation
Web server configuration and mediawiki directories
Mediawiki directories
In principle, you could install a mediawiki installation within the web directory.
I usually prefer to install all portals in some other place and then configure the web server to include this place using the Apache ALIAS directive (see below). IMHO, this makes administration easier in the long run. Also, in times of crisis it's easier to take a portal offline: just disable the ALIAS or restrict access to the local network.
The structure of our portals directory (portails in french) is the following:
- src (various source files)
- mediawiki (Edutechwiki/en, this wiki) <= Exposed to web with an ALIAS
- fmediawiki (french version) <= Exposed to web with an ALIAS
- testwiki <= Exposed to web with an ALIAS
- .....
- extensions (shared ones)
Create a directory, e.g.
/data/portails/wikitest
or
/portals/wikitest
We will put the mediawiki code there
Apache2 virtual sites file for your mediawikis
On system that shares various web applications, I suggest using a virtual web server name for your wiki. Ask for an Internet alias instead of using the "main name of your machine". This way you can migrate your wiki more easily from one machine to another. Move the files, export/import the database and have the alias move to the new machine.
- Web server configuration of the virtual host
Create an Apache2 site file, e.g. I called it mediawiki.conf.
Site files are located in the following directory:
/etc/apache2/sites-available/
Contents of /etc/apache2/sites-available/mediawiki.conf
(some optional and repetitive stuff removed)
Replace the stuff in capital letters
Important:
- The VirtualHost must be the name of the machine.
*:80
will no longer work ! That cost me 2 hours :( - Security has tightened. You cannot just declare an Alias. In addition, you must provide directory access explicitly to each directory outside the default web tree
- We will use "pretty" Wikinames (see below). This is why we need two aliases. One will be point to the installation directory and the other to the main php file of the mediawiki server. The latter is the one that people will see in a normal URL.
<VirtualHost YOUR.VIRTUALSERVER.DOMAIN>
ServerAdmin YOUR-NAME@YOURSERVER.DOMAIN
ServerName YOUR.VIRTUALSERVER.DOMAIN
ServerSignature Off
DocumentRoot /web
<Directory />
Options FollowSymLinks
AllowOverride All
</Directory>
<Directory /web>
Options Indexes
AllowOverride All
</Directory>
ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
<Directory "/usr/lib/cgi-bin">
AllowOverride None
Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from all
</Directory>
ErrorLog /var/log/apache2/error.log
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn
CustomLog /var/log/apache2/access.log combined
# ALIASES for wikitest: TWO alias for each WIKI
Alias /wikitest "/data/portails/wikitest"
Alias /wt "/data/portails/wikitest/index.php"
<Directory /data/portails/wikitest>
require all granted
</Directory>
# ALIASES for edutechwiki_en: TWO alias for each WIKI
Alias /mediawiki "/data/portails/mediawiki"
Alias /en "/data/portails/mediawiki/index.php"
<Directory /data/portails/mediawiki>
require all granted
</Directory>
</VirtualHost>
Create a symbolic link in the /etc/apache2/sites-enabled directory. The file will now be loaded into the apach2.conf.
pushd /etc/apache2/sites-enabled/ ln -s ../sites-available/mediawiki.conf .
Test it:
apache2ctl restart
Repeat for ssl configuration
- If you also serve via SSL, you will have to do this again with the SSL configuration file
Changes to the main configuration file
- Log files
- If you use a dedicated machine for your wikis, you may just have all the logs in a single place.
# Define an access log for VirtualHosts that don't define their own logfile CustomLog /var/log/apache2/other_vhosts_access.log vhost_combined
- Web user ID
- By default, the server will run under the ID www-data:www-data. I suggest leaving this as is.
- Default server name
- You could add a default server name, e.g. the name of the physical machine
ServerName REAL.NAME.DOMAIN
- Local Apache documentation
- Can help maybe, but it's not needed
apt-get install apache2-doc
PHP configuration
Add crypting to PHP
On the command line, type:
phpenmod mcrypt
Configuration of PHP for Web
Mediawiki takes quite a lot of memory. Some extensions can run for quite a while. If you don't have many other portals where scripts can run wild, you could use fairly large values here (even go higher than below). Warning after upgrading from Ubuntu 14LTS to 16LTS, you will have to edit the PHP files again. Notice that php.ini will sit in different places, E.g. in 16_LTS it sits in /etc/php/7.0/apache2 !!
For Ubuntu 18LTS, make sure that you use PHP 7.2. In a terminal, type:
php --version
- Edit file
/etc/php/7.2/apache2/php.ini
Make sure that PHP can compute your most complex pages:
max_execution_time = 180 max_input_time = 180 memory_limit = 256M
Alternatively
memory_limit = -1
File upload: If people can upload videos, etc. you do have to accommodate.
post_max_size = 50M upload_max_filesize = 50M
Allow people time for editing (students will freak out if the wiki refuses to save and edit, else explain that they could copy the edited text someplace and then edit again)
session.gc_maxlifetime = 10800
Remove error messages from file caching in wiki
apc.slam_defense = 0 apc.write_lock = 1
Configuration of command line PHP
Default values should be ok, although for larger wikis, you may have to raise values.
- Edit /etc/php/7.2/cli/php.ini
// cannot remember why
session.gc_maxlifetime = 3600
Create a MySQL database
You will have to create a database (we strongly suggest not to use prefixes, i.e. not to share tables of this portal with another one
- Database Name (e.g. WIKITEST)
- Database User (will be inserted into the LocalSettings.php MW configuration file)
- Database user password.
For such simple operations we suggest using the mysql command line as shown below. Prepare the command in a text editor, the copy/paste. Otherwise use PhpMyAdmin, the SQL tab. In the code below, replace words WIKITEST, USER_TO_REMEMBER, PASSWORD_TO_REMEMBER
mysql -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 39
Server version: 5.5.41-0ubuntu0.14.04.1 (Ubuntu)
mysql> create database WIKITEST;
Query OK, 1 row affected (0.00 sec)
mysql> grant index, create, select, insert, update, delete, drop, alter, lock tables on WIKITEST.* to 'USER_TO_REMEMBER'@'localhost' identified by 'PASSWORD_TO_REMEMBER' ;
Query OK, 0 rows affected (0.01 sec)
Mediawiki Installation with GIT
Download
Step 1
Firstly, make sure that the basic Ubuntu infrastructure is working ! (see above)
Step2 - Download the core
If you want to be able to upgrade quickly or work with a bleeding edge alpha version (sometimes this is recommended, sometimes not), the simplest way is using GIT (formerly SVN was used). The reason not to use the latest version, is that extensions can break and that very early versions may have bugs.
- Read Download from Git
Get the core
Go to your installation parent directory
cd /portails
Get the files, files will be copied to a "core" directory.
git clone https://gerrit.wikimedia.org/r/mediawiki/core.git
Now make sure to select the right version, e.g. as of Sept. 2018, this provides the latest stable MW version.
git checkout REL1_31
Move the core directory to a more meaningful name, e.g.
# move mv core wikitest
Your files should be in the /portails/wikitest directory (or rather in a place that suits your needs)
Step 3 - Install the mandatory extensions
- If you don't do this, the GUI will be missing and you couldn't even display the installation script.
"LightnCandy class not defined"
would be an indicator of forgetting this step.
composer install --no-dev
Step 4 - install a skin
- The core system from GIT does not include skins, except for a text-based simple one
cd skins git clone https://phabricator.wikimedia.org/diffusion/SVEC/Vector
Location of the repositories changes all the time, e.g. for MW 1.27 it was git clone https://git.wikimedia.org/git/mediawiki/skins/Vector.git. Read the README
file in the skins directory. It will tell where to look for.
Note: Later you must load the skin in the LocalSettings.php file !
Initial configuration
Go to the long Wiki URL (this depends on how where you installed the wiki and how you created your web server alias, see above)
Select language of the wiki (user interface) and your own language (for the installation)
Environmental checks should be just fine, e.g. you should see something like this (from an older installation a few years back).
Basic checks will now be performed to see if this environment is suitable for MediaWiki installation. Remember to include this information if you seek support on how to complete the installation. PHP 5.5.9-1ubuntu4.7 is installed. Found ImageMagick: /usr/bin/convert. Image thumbnailing will be enabled if you enable uploads. Found the Git version control software: /usr/bin/git. Using server name "http://tecfalx5.unige.ch". Using server URL "http://tecfalx5.unige.ch/wikitest". Using the intl PECL extension for Unicode normalization. The environment has been checked. You can install MediaWiki.
Answer all the questions :) I suggest using most of the defaults, in particular the ones that relate to database architecture. Since you will have to tune the configuration file manually, you will have learn how to configure the MediaWiki manually anyhow. Just make sure to remember: database name, database user, database user password.
At the end you will get a configuration file that you can copy into the wiki directory.
If you work in a decent environment, just edit file LocalSettings.php, paste contents and then save. Else you will have to copy the file to the server.
Step 2 - Repair the configuration file
In particular, make sure that short URLs work and that you have a skin (the graphical user interface)
Edit LocalSettings.php and create short URLs
The script will only generate some like:
$wgScriptPath = "/wikitest";
But you will have to add:
$wgScript = "$wgScriptPath/index.php"; $wgRedirectScript = "$wgScriptPath/redirect.php"; $wgArticlePath = "/wt/$1";
Edit LocalSettings.php to define a skin
Vector skin is defined as default, but the Wiki won't find it. See also the section on skins. I f you get MediaWiki from GIT, you will have to download separately
Add the following line:
wfLoadSkin( 'Vector' );
or maybe:
wfLoadSkin( 'vector' );
In older installation it was:
require_once "$IP/skins/Vector/Vector.php";
Hacks
Usually modifying any file in the source code because you will have to redo the fixes after each minor update. In addition, git will become confused.
Inkstitch namespace
InkStitch is an Inkscape extension to create digital embroidery designs. Its SVG namespace is not recognized by MediaWiki and SVG files using not listed namespaces will not display.
- InkStitch namespace (https://phabricator.wikimedia.org/T197595)
- https://www.mediawiki.org/wiki/Manual:UploadBase.php
Around line 1542 of file includes/upload/UploadBase.php
xmlns:inkstitch="http://inkstitch.org/namespace"
Updating with GIT
(section must be moved - Daniel K. Schneider (talk) 18:16, 9 April 2015 (CEST))
Updating the same version:
git pull php maintenance/update.php
But see also the composer information below. You may have to rerun it using various weird tricks to get it going ... :(
Changing versions:
(1) Update the code
git checkout <new version>
- for example
git checkout REL1_31
(2) Run the composer (if necessary, install and then repair the json file if needed. E.g. it seems to remove all the SMW extensions)
cp composer.json composer.json.SAVE composer install composer update
(3) update
php maintenance/update.php
Sometimes the composer is way to sensitive to differences in subversions. Try the following (even if it is not a smart thing to do per se ...)
php maintenance/update.php --skip-external-dependencies
If update breaks, then it is likely that an extension did become incompatible.
- Comment the extension in LocalSettings.php
- upgrade the extension
Trouble
We repeat: If you get Error: your composer.lock file is not up to date. Run "composer update --no-dev" to install newer dependencies
and you are sure that you installed the correct versions,
try:
php maintenance/update.php --skip-external-dependencies
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.
Configuration
The configuration file, minimal settings
Unless you use some configuration extension, all the configuration (except for styles and user messages) is done in file LocalSettings.php (in the top-level directory of the distribution).
Reading:
- http://www.mediawiki.org/wiki/Manual:Configuration_settings
- http://www.mediawiki.org/wiki/Manual:LocalSettings.php
List of default settings (source code)
- https://github.com/wikimedia/mediawiki-core/blob/master/includes/DefaultSettings.php (Look at this file after upgrading. If you got a ten year old MediaWiki, you may have stuff in your Localsettings.php that you may want to change / get rid off !
LocalSettings.php will read first the file includes/DefaultSettings.php and then override its settings with your own settings.
Below are a few settings (also read "nice URLs" below).
Wikiname:
// The site name is also used as namespace for certain pages, so select it with care
$wgSitename = "EduTech Wiki";
File cache can speed up serving non-dynamic contents a lot. However, caching is a complicated art .... (more later)
// Use the file cache and gzip the files
$wgUseFileCache = true;
$wgFileCacheDirectory = "$IP/cache";
$wgShowIPinHeader = false;
$wgDisableOutputCompression = true; // in case you have some leftover code that will gzip any output (not compatible)
$wgUseGzip = true;
Rights and icons I suggest creating a subdirectory of the main directory where you can put picture files for icon that are read in via PHP. I used tecfa, pick your own, e.g. call it local
// Rights
$wgEnableCreativeCommonsRdf = true;
$wgRightsPage = "EduTech_Wiki:Copyrights"; # Set to the title of a wiki page that describes your license/copyright
$wgRightsUrl = "http://creativecommons.org/licenses/by-nc-sa/3.0/";
$wgRightsText = "CC BY-NC-SA Licence";
$wgRightsIcon = "$wgScriptPath/tecfa/somerights.png";
// Icon on top left of your pages (change the sunflower)
$wgLogo = "$wgScriptPath/tecfa/wiki.png";
Permissions: I suggest using somewhat restrictive permissions, i.e. users have to create a login before editing. However, this cannot last for long unless you can hire a community manager to clean up spam. Once your wiki is online, it will take only a few month before it's filled up with tens of thousands of spam pages. We shall explain later how to manage user rights and how to fight spam. This is just for starters ...
// Permissions - editing users need to have a login
$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['*']['createaccount'] = true;
# $wgGroupPermissions['*']['createaccount'] = false;
$wgGroupPermissions['*']['read'] = true;
Various
// Strongly suggest to keep this (enabled by default). Puts all the messages in the database
// (easier to edit and edits will survive upgrades
$wgUseDatabaseMessages = true;
Files uploads: In an educational setting you might allow more file formats than in a fully open wiki. Certainly PDF should be included, unless you have some stable and easy to use document systems that is available to your learners. In any case, you 'must firstly enable file upload.
$wgEnableUploads = true;
$wgFileExtensions = array( 'png', 'gif', 'jpg', 'jpeg', 'ogg', 'pdf', 'mp3', 'svg', 'doc', 'xls', 'ppt', 'pub', 'txt', 'ps', 'zip' );
At the server level, you should make sure that the web server can write into the images directory. E.g. on a Ubuntu system, type:
# cd your_wiki_installation_directory chown -R www-data:www-data images/
Other image related settings may have to be defined, e.g. read Manual:Configuring file uploads
PHP Caching
Bytecode caching
Since PHP5.5, it is suggested to use OpCache for bytecode caching, i.e. the php code that is executed each time a page is called. (Unless I am wrong), it already is installed and configured in Ubuntu 16LTS.
See:
php -r 'phpinfo();' | grep opcache
Object caching
Quote from the manual: “When MediaWiki assembles a page to show to a user, it performs database queries to gather lots of different pieces of data and then combines it all into the page. Object caching allows MediaWiki to store these combined objects for later retrieval reducing the time spent communicating with the database and assembling pages. This is arguably the most important cache for most installations.”
In PHP > 5.5 since you already have OpCache, you could use APCu (not yet tested). For PHP 7x, try:
apt-get install php-apcu
Page caching
Will cache pages as static HTML pages. This works for most pages and for users that are not connected. Page caching was was introduced above, in the basic settings.
Nice URLs
We already explained above how to define short URLs. This little section, summarizes the information in one place. You always can first with default (ugly) URLs and then change later. But as a principle, you don't want ugly default URLs
- Example of a nice URL: http://edutechwiki.unige.ch/en/Mediawiki_installation
- Example of the ugly (default version) http://edutechwiki.unige.ch/mediawiki/index.php?title=Mediawiki_installation).
Reading: http://www.mediawiki.org/wiki/Manual:Short_URL
Here is an easy way to do achieve this for the content pages. The method described below is probably not exactly the one that is now being suggested by the manual, but it has been working for years.
Apache configuration file directives of direct interest to nice URLs:
<VirtualHost YOUR.VIRTUALSERVER.DOMAIN>
ServerAdmin YOUR-NAME@YOURSERVER.DOMAIN
ServerName YOUR.VIRTUALSERVER.DOMAIN
<Directory />
Options FollowSymLinks
AllowOverride All
</Directory>
# This should include the robot.txt file
<Directory /web>
Options Indexes
AllowOverride All
</Directory>
# ALIASES for wikitest: TWO alias for each WIKI
Alias /wikitest "/data/portails/wikitest"
Alias /wt "/data/portails/wikitest/index.php"
<Directory /data/portails/wikitest>
require all granted
</Directory>
</VirtualHost>
Then in LocalSettings.php:
$wgSitename = "Wiki test";
$wgScriptPath = "/wikitest"; $wgScript = "$wgScriptPath/index.php"; $wgRedirectScript = "$wgScriptPath/redirect.php";
Therefore only "normal" pages look nice. Special pages remain ugly, but this doesn't matter IMHO.
Also consider excluding all or most special pages in robots.txt. No reason that these should be indexed and they really eat away CPU cycles if you need another argument.
Disallow: /wikitest/
Disallow: /wt/Special:AllPages
Disallow: /wt/Special:Book
Disallow: /wt/Special:NewPages
Disallow: /wt/Special:PopularPages
Disallow: /wt/Special:RecentChanges
Disallow: /wt/Special:RecentChangesLinked
Disallow: /wt/Special:Search
Disallow: /wt/Special:Whatlinkshere
Disallow: /wt/Special:WhosOnline
Permissions
In some wikis you may want to set permissions, e.g. only allow people in an author group to edit or only allow registered users to read. Since Mediawikis are designed to support either open sites like Wikipedia or closed sites or read-only sites, the permissions system is fairly simple. In our opinion it's good enough for most educational scenarios:
Example (from an early EduTechWiki): Only registered could edit, but anyone could create an account
$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['*']['createaccount'] = true;
$wgGroupPermissions['*']['read'] = true;
Nowaday, we use a confirm edit and captcha extensions that we shall explain in the next section. Only folks in the author group can edit hassle free:
## Extension must be installed (see below)
$wgGroupPermissions['authors']['skipcaptcha'] = true;
Creating special user groups
As soon as you use a user group in a $wgGroupPermissions
statement, the group is created and you can add users to it through the Special:UserRights
page. E.g. if you decide that you should have an author group as above, it will be created as soon as you define a permission for such a group (see above)
Example (from a biology teaching wiki): Only current students can edit, all others can read
$wgGroupPermissions['*']['createaccount'] = true;
$wgGroupPermissions['*']['read'] = true;
$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['*']['createpage'] = false;
$wgGroupPermissions['*']['move'] = false;
$wgGroupPermissions['*']['createtalk'] = false;
$wgGroupPermissions['*']['upload'] = false;
$wgGroupPermissions['*']['reupload'] = false;
$wgGroupPermissions['*']['reupload-shared'] = false;
$wgGroupPermissions['*']['minoredit'] = false;
$wgGroupPermissions['user' ]['read'] = true;
$wgGroupPermissions['user' ]['move'] = false;
$wgGroupPermissions['user' ]['edit'] = false;
$wgGroupPermissions['user' ]['createpage'] = false;
$wgGroupPermissions['user' ]['createtalk'] = false;
$wgGroupPermissions['user' ]['upload'] = false;
$wgGroupPermissions['user' ]['reupload'] = false;
$wgGroupPermissions['user' ]['reupload-shared'] = false;
$wgGroupPermissions['user' ]['minoredit'] = false;
$wgGroupPermissions['eleve7']['read'] = true;
$wgGroupPermissions['eleve7']['edit'] = true;
$wgGroupPermissions['eleve7']['move'] = true;
$wgGroupPermissions['eleve7']['createpage'] = true;
$wgGroupPermissions['eleve7']['createtalk'] = true;
$wgGroupPermissions['eleve7']['upload'] = true;
$wgGroupPermissions['eleve7']['reupload'] = true;
$wgGroupPermissions['eleve7']['reupload-shared'] = true;
$wgGroupPermissions['eleve7']['minoredit'] = true;
Restrict permissions in name spaces
The Lockdown extension allows to restrict permission for both special pages and namespaces. This extension did install and work with MW 1.22 (Jan 2014).
Example from a project-oriented learning wiki, that only allows some users to read the discussion pages (these pages may contain confidential discussion/data)
// Lockdown Permissions:
require_once "$IP/extensions/Lockdown/Lockdown.php";
$wgNamespacePermissionLockdown[NS_TALK]['read'] = array('author');
$wgNamespacePermissionLockdown[NS_TALK]['read'] = array('sysop');
Secure login
As of 2017, browsers start seriously complaining when people use the non secure http protocol to login in.
Therefore you will have to do two things (1) Configure the web server for SSL / https. This can require some serious work.
- Read Ubuntu configuration help
- Follow the links at the bottom.
(2) Instruct your wiki
Add the two following lines to LocalSettings.php (much easier than trying to mess with Apache rewrite rules)
$wgServer = "//edutechwiki.unige.ch"; // Change this to your server root (not wiki root) $wgSecureLogin = true;
Fighting spam
For maintaining a spam free wiki there are only two solutions, according to our experience
- Hire a full time person to remove daily spam
- Make it difficult to become an author. Since we don't have the funding or hundreds of helpers that work for free, we opted for this solution.
Here are the principles:
- Only registered users can edit (using a captcha)
- Only registered users in an author group can edit hassle free
- Extension: ConfirmEdit
- Login creation is subject to a review and uses a form that requires the user to enter information about him/herself. In addition, a captcha must be solved.
- Extension: ConfirmAccount
Installation of ConfirmAccount and ConfirmEdit
ConfirmAccount will require users to fill an form. Administrators will be notified and then can accept a user or not.
#To to the extensions directory
cd extensions
# Clone the ConfirmAccount repository
git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/ConfirmAccount
# Go to ConfirmAccount directory
cd ConfirmAccount/
# See what's in the repository
git branch -r
# Adjust the version number ('''this is crucial''')
git checkout REL1_31
Welcome message. By default, the welcome message to new users has a mistake (as of 2018 there is a wrong link to the help in both the English and the French version) and you may want to change it anyhow.
- Edit MediaWiki:Confirmaccount-welc
- You also can find this message also by looking at your Special:AllMessages
Now install ConfirmEdit if you want to avoid that spamming scripts fill in the application form. In addition, ConfirmEdit can then be used as last defense layer, i.e. each confirmed used still will have to solve a recaptcha (no captcha) when editing a page.
cd extensions
git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/ConfirmEdit
cd ConfirmEdit
git checkout REL1_31
Finally, update the wiki. This is crucial since it will create two database tables.
# Run the update script ! cd your_installation_directory php maintenance/update.php
ConfirmEdit is not strong enough to deter scripts and untrained humans. Some "Search engine optimization" companies pay people from very poor countries to create logins and you need to filter both. Therefore you could use a domain-specific text questions with difficult (but not too difficult answers). To do this correctly would require some work. Anyhow, for using either captcha or captcha (no captcha) reduced spam-related user requests to a tolerable minimum
Get a reCaptcha key from Google
Either from the propaganda page or the developer page:
Copy/paste the two keys and use them in the configuration file as show below.
- Privatekey (Wiki) = secret key (google)
- PublicKey (Wiki) = site key (Google)
Configuration
As of this wiki in Aug 2016 and Sept 2018. On other wikis, we use different setups, e.g. on low traffic wikis, we do not install ConfirmEdit.
MediaWiki 1.27.1 PHP 7.0.8-0ubuntu0.16.04.2 Confirm User Accounts – (840191a) 01:36, 22 August 2016 ConfirmEdit 1.4.0 (38711ed) 15:14, 21 August 201
# NEW ReCaptcha (NoCaptcha)
require_once "$IP/extensions/ConfirmEdit/ConfirmEdit.php";
wfLoadExtensions( array( 'ConfirmEdit', 'ConfirmEdit/ReCaptchaNoCaptcha' ) );
$wgCaptchaClass = 'ReCaptchaNoCaptcha';
$wgReCaptchaSiteKey = '....';
$wgReCaptchaSecretKey = '....';
/*
# OLD ReCaptcha VERSION
require_once( "$IP/extensions/ConfirmEdit/ConfirmEdit.php" );
require_once( "$IP/extensions/ConfirmEdit/ReCaptcha.php" );
$wgCaptchaClass = 'ReCaptcha';
$wgReCaptchaPublicKey = '....';
$wgReCaptchaPrivateKey = '...';
*/
# Confirm Account
// wfLoadExtension( 'ConfirmAccount' );
require_once("$IP/extensions/ConfirmAccount/ConfirmAccount.php");
// $wgAllowAccountRequestFiles = false;
$wgConfirmAccountContact = "daniel.schneider....";
$wgConfirmAccountRequestFormItems['Biography']['minWords'] = 10 ;
# our users must be registered, once they are in they they still must fill in captchas.
$wgCaptchaTriggers['edit'] = true;
$wgCaptchaTriggers['addurl'] = false;
$wgCaptchaTriggers['create'] = true;
$wgCaptchaTriggers['createaccount'] = true;
# Skip recaptcha for confirmed authors (they will inherit normal user rights)
$wgGroupPermissions['authors']['skipcaptcha'] = true;
Removed spam
- The Nuke extension allows to remove all pages recently added by a user or IP address.
In LocalSettings.php
wfLoadExtension( 'Nuke' );
- The deleteBatch.php maintenance script can remove pages that are listed in a file
php deleteBatch.php somepages.txt
- This extensions does not remove links in other pages or images.
- The DeleteBatch extension adds a user interface.
To kill unused accounts, use removeUnusedAccounts.php, e.g. type this in the maintenance folder to remove untouched accounts that are older than one year.
php ./removeUnusedAccounts.php --ignore-touched 360 --delete
Messages
Configuring interface messages is quite easy. Use the following procedure, if you can't recall the names of the appropriate Mediawiki pages (each message is defined in its own page).
- List all messages with the special page Special:Allmessages
- You then can customize each Mediawiki message, by clicking on a message and edit
Notice:
- Works by default, i.e. $wgUseDatabaseMessages = true;
- If you are not using database messages, you can edit the languages/Language.php file (for English) or languages/LanguageXX.php for non-English languages, where XX is the two-letter language code for your language
- Be careful: entering wrong data may disable some messages ....
Each of the Mediawiki:XXX pages you may configure are listed in Special:Allmessages as we said above. The ones you did redefine will be in green. Below are two examples:
Slogan and site notices
- A slogan message
The page MediaWiki:Sitesubtitle will allow you to add some sort of slogan (you also can kill this default page). Has the same effect as setting the $wgExtraSubtitle variable.
- Sitenotices (e.g. to annonce an important event)
Read: http://www.mediawiki.org/wiki/Manual:Interface/Sitenotice
In LocalSettings.php, set
$wgSiteNotice = " ........ ";
Skins and CSS
Skin selection
Unless you have time to spend, I suggest to use the standard Vector skin. Other skins are not as well supported. E.g. some important extensions like the Visual Editor just won't work with other skins.
For some kind of installations, the skin is not included, i.e. you must install one yourself. See below.
Fine tuning CSS
You should adjust the CSS (in particular class or id selectors for extensions) in the MediaWiki:Common.css page. Do not edit CSS files in the server if you can avoid. This strategy makes maintenance much easier.
Install with composer
composer require mediawiki/vector-skin
- If you change from manual to composer installation, you may have to remove old files first.
Get the Vector skin with GIT
Important: If you download the mediawiki code via Git, the skin is not included starting version 1.24 (read this, summer/fall 2014)
Do the following:
cd <install-dir> cd skins # git clone https://gerrit.wikimedia.org/r/mediawiki/skins/Vector git clone https://phabricator.wikimedia.org/diffusion/SVEC/vector.git
After downloading the git archive, I suggest adjusting the version, since skins depend on version-specific features, for example:
git checkout REL1_31
In Localsettings, load it:
wfLoadSkin( 'Vector' ); $wgVectorUseSimpleSearch = false; // set to true if you don't want the search/go buttons $wgVectorUseIconWatch = true; $wgVectorResponsive = true; // make it more mobile friendly
Reading: Navigation bar help
Configuration: Edit MediaWiki:Sidebar (menu definition page) in your wiki
Since version 1.14 (or earlier) you may use keywords to change the order of portlets (boxes with menu items). E.g.
* SEARCH * navigation and help ** mainpage|Mainpage ** EduTech_Wiki:About|about <!-- ** portal-url|portal --> <!-- ** currentevents-url|currentevents --> ** randompage-url|randompage ** helppage|Help ** Help:Editing rules|Editing rules ** Blog:DKS|Blog (D.K.S.) * categorytree-portlet * TOOLBOX * LANGUAGES * big brother ** Special:Newpages|New Pages ** recentchanges-url|recentchanges ** Special:Guestbook|Guestbook ** Special:Popularpages|Popular Pages ** Special:WhosOnline|Who is online ? * TECFA links ** http://tecfa.unige.ch/ |TECFA ** http://tecfaseed.unige.ch/door/ |TECFA Portal
In addition one also could add more sophisticated custom items (instead of hand editing the skin files, to do ....)
Subpages
According to the MediaWiki help pages Subpages can be useful for three major purposes.
- to create archives of old discussions under a talk page
- to create scratchpad editing spaces under a user page
- to create other language versions of a document in multilingual wikis
Slashes (/) within a page name break the page into parent and subpages, recursively
- Avoid subpages for regular pages for two reasons: It's against the wiki/hypertext philosophy and some crucial extensions (like the book creator) can't find them !
- Allow subpages for regular pages, if you want users to add some kind of "attachments", e.g. code examples, student productions related to a page, note taking elements, etc. In that case, make sure that users will not create CMS-like content hierarchies.
Read:
It you plan to enable supages everywhere, use:
# Enable subpages in all namespaces $wgNamespacesWithSubpages = array_fill(0, 200, true);
Else use something like:
$wgNamespacesWithSubpages = array( NS_TALK => true, NS_USER => true, NS_USER_TALK => true, NS_PROJECT_TALK => true, NS_IMAGE_TALK => true, NS_MEDIAWIKI_TALK => true, NS_TEMPLATE => true, NS_TEMPLATE_TALK => true, NS_HELP_TALK => true, NS_CATEGORY_TALK => true, 102 => true, 103 => true )
Adding extra namespaces
Some extensions, e.g. wikilog or semantic mediawiki use additional namespaces. It is difficult to know what namespaces are used and more so what index number they are.
- Read Help:Namespace
- To list the prefixes in use of th the use visible namespaces, use the pull-down menu: Special:PrefixIndex
- To figure out the index number look at the source of the above page.
E.g. you will see something like this:
<option value="100">Admin</option>
<option value="101">Admin Discussion</option>
<option value="102">STIC</option>
<option value="103">STIC Discussion</option>
<option value="104">Blog</option>
<option value="105">Blog talk</option>
<option value="106">COAP</option>
<option value="107">COAP Discussion</option>
<option value="110">Property</option>
<option value="111">Property talk</option>
<option value="114">Form</option>
<option value="115">Form talk</option>
<option value="116">Concept</option>
<option value="117">Concept talk</option>
<option value="118">Filter</option>
<option value="119">Filter talk</option>
If you want to list 'all' namespaces, use the API, e.g.
api.php?action=query&meta=siteinfo&siprop=namespaces&formatversion=2
Default user preferences
In a wiki with long pages like this one, you could make numbered titles the default:
$wgDefaultUserOptions['numberheadings'] = 1;
Insert pages edited by a user on their watchlist
$wgDefaultUserOptions['watchdefault'] = 1;
Send email if a watched page is changed (only do this in a small "organizational" wiki ....)
$wgDefaultUserOptions['enotifwatchlistpages'] = 1;
If you change user preferences, you maybe should plan to update the old users. To do so, use a maintenance script:
- Updating number headings preferences for all users
- In the terminal, type
cd your_mediawiki_directory php maintenance/userOptions.php numberheadings --old 0 --new 1
Instant Commons
If you wish you could share multimedia files with Wikimedia Commons.
- Read InstantCommons
In LocalSettings.php:
$wgUseInstantCommons = true;
You then can upload pictures to Wikimedia Commons
Of course, this means that you will have to respect all the requirements of Wikimedia Commons. In brief:
- fill in a detailed form
- the picture should be of general interest (potentially includable in a Wikipedia or Wikibooks article)
- Use an acceptable license: Creative Commons CC-BY-SA, Creative Commons CC-BY license, CC0 Public Dedication 1.0 license. A BY-NC-SA (used per default in this wiki) cannot be accepted. You can only impose "attribution" and "share alike" but not "non-commercial".
Performance tuning
Read:
- How to make MediaWiki fast by Aaron Schulz
Moving the wiki to a new machine
I suggest the following steps:
- Install all the software dependencies on the new machine (dozens of libraries, languages, etc.)
- Configure the web server and other services that are needed (see above for the essentials and below for optional stuff)
- Install a wiki test server or export one that you already have
- Upgrade the current wiki(s) to a stable and (if possible) most recent version
- Then lock the wiki for writing, move it, test it, then move the Internet alias (virtual server) if you keep the old machine alive for some other purpose.
Moving a wiki
Step 1 - Freeze it
- Lock it for writing. In LocalSettings.php:
$wgReadOnly = 'Moving the wiki to another machine, back to normal in/at ....';
Step 2 - Dump the database
- Exporting, then importing the SQL is probably a better option than copying the binary database files.
Export:
mysqlshow -p -u root // in case you forgot the db name mysqldump -p -u root data_base > yourwikiDB.sql gzip yourwikiDB.sql
Move it to the target machine, e.g. use sftp. The "un-gzip" the file again.
gunzip yourwikiDB.sql.gz
Step 3 - Create a new database and import
Create a new database with the same name and permissions
- Note: you can identify db_user name and its password by looking at the LocalSettings.php file
$wgDBuser = "db_user"; $wgDBpassword = "secret";
MySQL command line commands (";" on a new line so that you can safely copy/paste and change):
mysql -p -u root
mysql> create database yourwikiDB
mysql> ;
mysql> GRANT INDEX, CREATE, SELECT, INSERT, UPDATE, DELETE, DROP, ALTER, LOCK TABLES, CREATE TEMPORARY TABLES, EXECUTE ON yourwikiDB.* TO 'db_user'@'localhost' IDENTIFIED BY 'secret'
mysql> ;
Import the database tables and contents
On the Linux command line, type:
mysql -p -u root -D yourwikiDB < yourwikiDB.sql
or alternatively
mysql -p -u db_user -D yourwikiDB < yourwikiDB.sql
This will execute all the SQL commands in the yourwikiDB.sql file and create tables + contents for the yourwikiDB database.
Step 4 (option A) - Archive, then move the files
- I prefer option B (see below)
- Create a file archive (or move everything in one single step, see below). You could be tempted to move the files before dumping/moving the database in order to get some more uptime. IMHO, you would not gain much. The bulk of the files sit in the images directory and its contents can change as long as users can edit.
cd installation_dir cd .. tar zcf wiki_name.tgz installation_dir
- Move the files with stfp to the target machine
- On the target machine:
cd /new_parent_directory tar xfz wiki_name.tgz
Option B: All-in-one archiving/moving
- Works best if you are root and root access is open from your machine, else the file permissions will be wrong. If you cannot, then firstly create a directory on the new server and give it to you.
(cd /data/portails/installation_dir && tar cfz - .) | ssh root@new.machine 'cd /some/absolute_path/installation_dir && tar xfz -'
Or a variant:
// In the target machine: mkdir /absolute_path/directory_above chown to_you:to_group /absolute_path/directory_above // In the source machine cd /directory_above_installation ls -l tar cfz - installation_dir | ssh root@new.machine 'cd /some/absolute_path/ && tar xfz -'
If you did this without being root, then fix the permissions on the target machine
cd installation_directory chown www-data:www-data images cache
Tuning
Make the wiki writable again
- Comment the $wgReadOnly line, if necessary.
// $wgReadOnly = 'Moving the wiki to another machine, back to normal in/at ....';
Test it
- If the pages display and if you can log in, then you can switch the Internet Alias
If your old wiki ran a recent version of MediaWiki, the transfer should go smoothly. Else, you may suffer in the same way as you could suffer after a major OS upgrade. Upgrade the wiki first, then repeat transfer. Also, some extensions may be broken. See debugging.
Verify the configuration file
I also suggest looking at the configuration file and adapt to the changes. Some stuff in there may not hurt, but it could be outdated.
Troubleshooting
- Verify that the new database really exists
mysqlshow -p -u root yourwiki
- Make sure that the web server permissions are ok
- Some extensions may not work with new PHPs. Uncomment all extensions in the LocalSettings.php file and uncomment one by one ...
Extensions installation and configuration principles
See also the Mediawiki article where we list extensions we find useful to have. Here, we only document installation and configuration of the more difficult ones.
Download and documentation: You will find most extensions on MediaWiki.org. The Extensions category page will provide several entry points. I sort of like the Extension_Matrix page.
Most extensions are well documented, just read the instructions and follow them. However, since some are badly maintained you sometimes will have to read the discussion page for finding appropriate patches...
Installing extensions the traditional way
A checklist of things to look at and to do:
(1) Check if the extension is compatible with your MW version (this is not always obvious, therefore you also should look for hints in its dicussion page).
(2) Read the discussion page that will tell you something about the quality of an extension.
(3) Download the extension either as archive (zip etc.) or via GIT (see next item). Some simple extensions are just available as code section from the wiki page that you must copy to a file.
- Make sure that the files sit in a directory unless its a simple single file extension
- Move the extension directory to the extensions folder of your installation
- Add all the extra stuff an extension may need. This can sometimes be a lot of work (e.g. days), sometimes nothing (minutes). Most extensions are simple and don't need other server-side programs.
- If the extension needs a cache, you may have to change write permissions in some subdirectory.
(4) Load and configure:
- Edit LocalSettings.php to configure and to load the extension.
- You may have to define configuration variables in the LocalSettings.php file and/or by defining Mediawiki:XXX pages
- You may have the option to add CSS definitions to the MediaWiki:Common.css pages
- Some extensions will update the database. In that case it is important to run the update script, something that you should anyhow after each addition and/or upgrade.
php maintenance/update.php
- Sometimes you need to define templates, modify the CSS, etc.
Using Git repositories with the method above
Mediawiki git repositories can change over the years, but the principle is the same.
- Most extensions are available from the official repository
- Its location is often undocumented on the extension page, but you can easily guess it:
- As of 2017, the location is
https://gerrit.wikimedia.org/r/p/mediawiki/extensions/ExtensionName.git
- e.g.
https://gerrit.wikimedia.org/r/p/mediawiki/extensions/CategoryTree.git
Before, it was:
https://git.wikimedia.org/git/mediawiki/extensions/........
Some links in this document may not be updated yet. E.g. if git.wikimedia.org doesn't work (it should not), try gerrit.wikimedia.org.
Installing extensions with Composer
For MediaWiki installations, younger than mid-november 2013, you should learn how to use composer, a PHP dependency manager. It should work with the following combination of server software:
- PHP 5.3.2+
- MySQL 5.0.2+
- CURL
- MediaWiki 1.22 (nov 2013) or better.
If your server doesn't meet these requirements (in particular a new 1.22 MediaWiki), then use the traditional way.
If you run several wikis, it's probably best to install composer on system level:
cd /some/src curl -sS https://getcomposer.org/installer | php mv composer.phar /usr/local/bin/composer
- Removing old extension versions
- Remove the old files in the extensions directory
- In LocalSettings.php remove the line that loads the extension, e.g.
require_once( "$IP/extensions/DataValues/DataValues.php" );
- Install extensions using composer
Composer is run from the base directory (and not the extensions directory) !!
See the documentation for each extension. Examples:
composer require mediawiki/semantic-media-wiki "1.9.*,>=1.9.0.1" composer require mediawiki/semantic-media-wiki "~2.0"
- Update all extensions using composer.
- If the dependencies are right, this should work without worrying about versions.
composer update - or, for stable versions - composer update --no-dev
- Trouble
- If composer updates, but maintenance/update.php balks with "Error: your composer.lock file is not up to date. Run "composer update --no-dev" to install newer dependencies
", try
php maintenance/update.php --skip-external-dependencies
Difficult to install text and graphics extensions
Actually some of these may be quite easy to install. However more than just downloading is always required. Some extensions are sometimes very difficult to install, i.e. they do install but may either not work or break your wiki. Upgrading or downgrading the extension version can help. Upgrading/downgrading the wiki also, but downgrading a wiki is near impossible and not recommended, since the database structure may have changed !
The math extension
The match extension allows to display mathematical formula that are written in Latex. Instructions below may be outdated (i.e. were not checked for MW 1.31)
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:
Collection extension and mwlib server
This extension is crucial for an educational wiki. It allows creating print books or just simply print a page in PDF format. The print book can be downloaded as PDF (or optionally in Open document format) or it can be ordered through your wiki as print book from Pediapress.
There exist two ways of using this PDF/OO/DocBook book generator.
- The easy strategy is to install just the extension files and use the PediaPress server for generating the PDF or OO documents. This strategy did not work out well and we use our own server.
- The other strategy is to install a combo of various services that will collect and generate documents on your own server. Installation is fairly complex.
- Detailed instructions for collection and server installation
- Mediawiki collection extension installation
- Most important documentation and download pages
- Extension page Collection: http://www.mediawiki.org/wiki/Extension:Collection
- Extension page PDF_Writer: http://www.mediawiki.org/wiki/Extension:PDF_Writer
- MwLib/Collection server installation guide (if needed): http://code.pediapress.com/wiki/wiki/mwlib-install
Graphviz
This extension can generate graphs with the dot syntax.
Installation of Graphviz libraries
- Most important documentation and download pages
- Extension page: http://www.mediawiki.org/wiki/Extension:GraphViz
- Extension page for Image map: https://www.mediawiki.org/wiki/Extension:ImageMap
- Additional installs: Graphviz from http://www.graphviz.org/Download.php plus needed libraries that you may or may not have on your server
Linux dependencies and installation
Graphviz itself needs several libraries like GD, Zlib, Freetype, PNG, JPEG, EXPAT, etc. (read http://www.graphviz.org/Download_source.php Requirements). The following should get all the dependencies right:
apt-get install graphviz graphviz-dev
Download and installation of the MW extension
This extensions is installed with composer. The extension also requires the imagemap extension.
composer require mediawiki/graph-viz '*'
You also should image-map if it is not already installed. Note that the MediaWiki documentation claims this to be bundled but I couldn't see any of it. Maybe it's just in the tar balls.
composer require mediawiki/image-map @dev
Trouble
Syntax change for links
If you get a message like this:
Error: No valid link was found at the end of line 2.
then you got a syntax error for the links
In an older version of this extension, the syntax for a label with a link was the following and that is wrong now. The change was made because rendering is now done with the imagemap extension.
"Learning Theory" [URL="Learning theory"];
New syntax:
"Learning Theory" [URL="[[Learning theory]]"];
Models are ugly after upgrading or break
I don't think that there is a good easy solution.
Below you can see the use of nodesep=2 and len=2.0 parameters that may or may not work with your graphviz/extension combination. The model can be found in the 3D printing page, but its parameters may not be the same.
<graphviz caption="Ambitious model">
graph ThreeD_printing_2 {
node [fontsize=10,fontname="Arial",shape=none,nodesep=2];
edge [fontsize=10,fontname="Arial", len=2.0];
# List of nodes
Idea [shape=box, color=red, label="Design idea"];
.....
Graphvis is not recognized by the collection extension
i.e. a generated graph will not print in PDF.
- Workaround: Put the code in the discussion page, then link to the generated *.png from the page. Example: Stitch Era embroidery software (look at the source code and the discussion page).
Timed Media Handler
The TimedMediaHandler extension allows you to display audio and video files in wiki pages, using the same syntax as for image files. It includes the Kaltura HTML5 Player, which supports integrated standard timed text support, real time stream switching between multiple WebM and Ogg derivatives and many other features. TMH server side support includes multiple transcode profiles, php based medata parsing via PEAR Ogg / OggHandler and getID3 for WebM files, and integrates with mediaWiki's jobQueue system for scheduling transcoding jobs.
The official installation instructions in the extension page are not exactly accurate (the README file is a bit better). As of April 2015, the following did work:
System prerequisites (Ubuntu 14.04LTS)
apt-get install php-pear ffmpeg2theora imagemagick apt-get install libav-tools
Mediawiki prior to 1.31
Installation wiki
git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/MwEmbedSupport.git git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/TimedMediaHandler.git
In LocalSettings.php:
# Somewhere in the beginning I guess ini_set( "include_path", ".:$IP:$IP/includes:$IP/languages:/usr/share/php");
# ---- VIDEO - TimeMediaHandler # TimedMediaHandler is dependent on mwEmbedSupport require_once( "$IP/extensions/MwEmbedSupport/MwEmbedSupport.php" ); #TimedMediaHandler require_once( "$IP/extensions/TimedMediaHandler/TimedMediaHandler.php" );
# Adjust file extensions, e.g. $wgFileExtensions = array( 'png', 'gif', 'jpg', 'jpeg', 'ogg', 'pdf', 'mp3', 'svg', 'doc', 'xls', 'ppt', 'pub', 'txt', 'ps', 'zip', 'ogg', 'ogv', 'mp4', 'webm' );
Mediawiki > 1.31
Installation wiki
git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/TimedMediaHandler.git
cd TimedMediaHandler
Update composer within the extension directory. Normally this should be done by the update script if I am not wrong ....
composer update
In LocalSettings.php:
# Somewhere in the beginning I guess ini_set( "include_path", ".:$IP:$IP/includes:$IP/languages:/usr/share/php");
# ---- VIDEO - TimeMediaHandler wfLoadExtension ('TimedMediaHandler');
# Adjust file extensions, e.g. $wgFileExtensions = array( 'png', 'gif', 'jpg', 'jpeg', 'ogg', 'pdf', 'mp3', 'svg', 'doc', 'xls', 'ppt', 'pub', 'txt', 'ps', 'zip', 'ogg', 'ogv', 'mp4', 'webm' );
Update
Cannot hurt:
cd your_installation_directory php maintenance/update.php
Semantic Mediawiki (SMW) and SMW extensions
Explained in a different article:
- Read Semantic MediaWiki
Below just the short form we sometimes used (adapt the version numbers).:
cd your_installation_directory
composer require mediawiki/semantic-media-wiki "~2.0"
composer require mediawiki/maps "*"
composer require mediawiki/semantic-maps "*"
composer require mediawiki/semantic-forms
composer require mediawiki/semantic-result-formats "*"
php maintenance/update.php
cd extensions
git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/SemanticFormsInputs.git
git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/SemanticDrilldown.git
# if not already done so
# git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/AdminLinks.git
cd ..
php maintenance/update.php
Alternatively, edit the composer.json file. As of Sept 2016, ours looks like this:
"mediawiki/semantic-media-wiki": "~2.5",
"mediawiki/maps": "~5.1",
"mediawiki/semantic-result-formats": "~2.5",
"mediawiki/sub-page-list": "~1.5",
"mediawiki/graph-viz": "*",
"mediawiki/image-map": "dev-master"
But that can change anytime, e.g. in principle one could include page forms also, but last time we tried it did not work well...
In LocalSettings.php
# ---- Semantic MediaWiki
$smwgNamespaceIndex = 108;
enableSemantics('edutechwiki.unige.ch'); // adjust to yours
$smwgShowFactbox = SMW_FACTBOX_NONEMPTY;
$shcAgreedToHCLicense = true;
// include_once("$IP/extensions/SemanticForms/SemanticForms.php");
wfLoadExtension( 'PageForms' );
# If one or more of your fields can contain internal links entered by users (e.g., "This is a [[cat]]")
$smwgLinksInValues = true;
# Semantic Drilldown. Needs yet another namespace
$sdgNamespaceIndex = 118;
include_once("$IP/extensions/SemanticDrilldown/SemanticDrilldown.php");
# Semantic Forms Inputs. Since fall 2015, I use composer for this
# require_once("$IP/extensions/SemanticFormsInputs/SemanticFormsInputs.php");
Visual Editor
Installing the Visual Editor requires a JavaScript server, i.e. you either need a hosting service that provides node.js or full access to a machine. It also requires MW 1.24 or better. Visual Editor doesn't integrate SemanticMediaWiki, but it can deal with templates. Therefore, if you want to use both in a Wiki, use templates to define SMW properties.
Installation
- Is explained in VisualEditor
CategoryTree
updated for REL1_29 / Nov 2017, check for REL1_31 upgrade. It seems that this extension is now included in the standard distribution.
Allows to create menus of categories and its members. Adds a "CMS" like layer to the wiki
Installation
git clone https://git.wikimedia.org/git/mediawiki/extensions/CategoryTree.git
In Localsettings.php (version 29 >)
wfLoadExtension( 'CategoryTree' );
In Localsettings.php (version 1.27 or older)
$wgUseAjax = true; // not sure if which versions this is required require_once("{$IP}/extensions/CategoryTree/CategoryTree.php");
If you use a Categorytree in the sidebar, you will have to give the name of a category. In this wiki I tagged all content categories with category "Contents".
$wgCategoryTreeSidebarRoot = "Contents"; $wgCategoryTreeSidebarOptions['mode']=CT_MODE_CATEGORIES;
Other options I use:
$wgCategoryTreeForceHeaders = true; $wgCategoryTreeDynamicTag = false; $wgCategoryTreeDisableCache = false; $wgCategoryTreeMaxDepth = array(CT_MODE_PAGES => 2, CT_MODE_ALL => 2, CT_MODE_CATEGORIES => 3);
System and administrative extensions
WikiEditor
- Provides a better Edit bar that includes more buttons. Must-have for an educational wiki
cd extensions git clone ssh://gerrit.wikimedia.org:29418/mediawiki/extensions/WikiEditor
In LocalSettings.php
require_once "$IP/extensions/WikiEditor/WikiEditor.php"; # To enable a preference by default but still allow users to disable it in preferences, use something like... $wgDefaultUserOptions['usebetatoolbar'] = 1; $wgDefaultUserOptions['usebetatoolbar-cgd'] = 1; $wgDefaultUserOptions['wikieditor-preview'] = 1;
Parser Functions
Are essential if plan to write templates. Some advanced extensions also may use these.
git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/ParserFunctions.git
In LocalSettings.php:
require_once "$IP/extensions/ParserFunctions/ParserFunctions.php"; # For programming templates the following could be handy (but can cost CPU when used): $wgPFEnableStringFunctions = true;
Debugging
- You can expand the template with the ExpandTemplates page that can be found in the Special Pages ([[[Special:ExpandTemplates]]]). Different name in other languages !
Scribunto
Scribunto is a Mediawiki extension that allows end-user (within-wiki) scripting. It currently supports the lua language. Scribuntu is an alternative to programming with templates and parser extensions, i.e. it's easier to learn and to use. .
E.g. on Wikipedia, the citation modules are programmed with that.
Prerequisites
lua must be installed in your system, e.g. in Ubuntu, type:
sudo apt-get install lua5.1
Installation via GIT
cd extensions git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/Scribunto.git
// adapt to your OS chmod a+x Scribunto/engines/LuaStandalone/binaries/lua5_1_5_linux_64_generic/lua
Adapt to your wiki version, e.g.
git checkout origin/REL1_25 -b REL1_25
If you forget this, then you likely will see a blank screen when you try to save a module page.
Configuration
In Localsettings.php:
require_once "$IP/extensions/Scribunto/Scribunto.php"; $wgScribuntoDefaultEngine = 'luastandalone';
Via composer As of March 8 2016, the following did not work:
composer require mediawiki/scribunto "composer/installers: >=1.0.1"
https://www.mediawiki.org/wiki/Extension:CodeEditor
Code Editor
The CodeEditor extension extends the WikiEditor advanced editing toolbar with an embedded Ace editor widget, providing some handy features for user/site JS, CSS pages, and when Extension:Scribunto is also installed, for pages in Module namespace.
git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/CodeEditor
In LocalSettings.php
require_once "$IP/extensions/CodeEditor/CodeEditor.php"; $wgCodeEditorEnableCore = true; $wgScribuntoUseCodeEditor = true;
We found this extensions particularly useful to edit MediaWiki:Common.css since it provides CSS tips and warnings. This extensions, however does not provide any support for editing (much more difficult) template code.
Admin links
Adds a special page with useful links to administration. The link to this page appears on top right.
composer require "enterprisemediawiki/admin-links" "dev-master"
Regexp Functions
The Regex Fun extension provides four new parser functions for performing regular expression handling within wiki pages. Useful for template programming.
git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/RegexFun.git
In LocalSettings.php:
require_once( "$IP/extensions/RegexFun/RegexFun.php" );
Interwiki
The Interwiki extension allows to edit the interwiki database table, that we use for example to create short links to the french sister version using the :fr prefix or to link to a WikiPedia article using :WikiPedia.
In LocalSettings:
wfLoadExtension( 'Interwiki' ); $wgGroupPermissions['sysop']['interwiki'] = true;
My Variables
The MyVariables extension adds new built-in variables which are very handy if you plan to "program" templates.
E.g. {{CURRENTUSER}}
produces: 54.198.200.128
git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/MyVariables.git
In LocalSettings.php:
require_once "$IP/extensions/MyVariables/MyVariables.php";
Check user
Allows administrators to retrieve some information about suspicious users. Only important for a relatively open wiki.
git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/CheckUser.git
In LocalSettings.php
include_once("$IP/extensions/CheckUser/CheckUser.php");
Rename user
In an educational context it's important to be able to "fix" user names. Often, students just pick an ugly "mail account" type of name and then want to change
git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/Renameuser.git // adapt git checkout REL1_29
In Localsettings.php
wfLoadExtension( 'Renameuser' );
In Localsettings (OLD versions)
include_once('$IP/extensions/Renameuser/SpecialRenameuser.php');
MassEdit Regexp
Allows administrators to make mass find/replaces throughout the whole wiki, using regular expressions.
MassEditRegex allows to change expressions in multiple pages. Very useful for instance, if you plan to add/remove or rename categories. Replace Text is another alternative that probably has similar functionality (not tested yet).
git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/MassEditRegex.git
In LocalSettings:
include_once("$IP/extensions/MassEditRegex/MassEditRegex.php"); $wgGroupPermissions['sysop']['masseditregex'] = true;
Replace Text
This extension has similar functionality as the above one. It also allows searching through a whole name space, i.e. you do not need to enter page names.
Installation:
cd extensions git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/ReplaceText
In LocalSettings:
wfLoadExtension( 'ReplaceText' ); $wgGroupPermissions['bureaucrat']['replacetext'] = true; // optional to give this right to bureacrats
User merge
It can happen that some contributors have more than one account since they forgot their old login or maybe because they want to change their name and cannot do it by themselves.
The UserMerge extension allows to:
- merge (refer contributions, texts, watchlists, edit count of a first account A to a second account B
- delete the first account A after the merge (option box)
cd extensions git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/UserMerge // adapt git checkout REL1_29
In LocalSettings.php:
wfLoadExtension( 'UserMerge' ); // By default nobody can use this function, enable for bureaucrat? $wgGroupPermissions['bureaucrat']['usermerge'] = true;
Deleting users
Users that did contribute should not be deleted but just blocked. All edits must have a user, this is why. So, there are neither maintenance scripts to do that nor extensions.
- However, you can merge all unwanted users into one with the UserMerge extension (see above), but this is tedidious.
- You could remove a user from the database, but that is not recommended.
See also: You can kill spam pages with the Nuke extension for a given user.
Easy to install extensions to enhance page contents
Discussion Threading
Works OK with MW 1.31 (sept. 2018)
This extension that will modify the discussion pages and make it look like traditional hierarchical forums (that did work very well in the past and are now replaced by php/mysql horrors....). The pages are still real wiki pages and can be edited as such. This makes this extension less intrusive than various other alternatives like liquidthreads.
- Minimal threading - Subject headings are used to identify what discussion a particular comment belongs to. These headings are not dated and cannot be sorted.
- Users explicitly sign their comments - signatures are automatically added to the discussions.
- Transparent response mechanism - users can reply to existing comments or create new ones using the [new][edit][reply]
- Conversation tracking - the [reply] allows users to specify existing objects (sections) in the system, and effectively track comments one has left, responses received (regardless of the location), and so on.
Installation:
git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/DiscussionThreading.git
In LocalSettings.php:
wfLoadExtension( 'DiscussionThreading' ); // old Mediawikis < 1.24 // require_once("$IP/extensions/DiscussionThreading/DiscussionThreading.php");
Warning: If you also installed VisualEditor, this line must be inserted after the Visual Editor code... or you won't see any buttons.
Notice
This extension was broken somtimes in the past. We do not know if new fixes repair old Mediwiki versions. If not, you can do manual fixes as we did. See the discussion page of this extension.
You also can consider installing other extensions, like Flow (used on Wikipedia), but these require longer list of prerequisites.
Embedd Video
Allows to embed videos from various services, such as YouTube.
Installation (fix the installation directory)
git clone https://github.com/Alexia/mediawiki-embedvideo mv mediawiki-embedvideo EmbedVideo
In LocalSettings;
require_once "$IP/extensions/EmbedVideo/EmbedVideo.php";
Read the extension page
Syntax highlight
SyntaxHighlight allows to display various kinds of computer code. A must have for technical wikis, also useful to get better rendering for the Collection extension.
Installing it the traditional way
cd extensions git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/SyntaxHighlight_GeSHi.git
Starting MW 1.26 you also must update the downloaded files with composer:
cd ../extensions/SyntaxHighlight_GeSHi/" composer install
In Localsettings.php add:
require_once "$IP/extensions/SyntaxHighlight_GeSHi/SyntaxHighlight_GeSHi.php";
Installing it via composer (MW 1.26+)
Hand edit the composer.json file in the root directory and do as instructed in the official instructions. I got the following code fragment:
"extra": { "merge-plugin": { "include": [ "composer.local.json", "extensions/SyntaxHighlight_GeSHi/composer.json" ], "merge-dev": false } }
Then type:
composer update
In Localsettings.php add:
wfLoadExtension( 'SyntaxHighlight_GeSHi' );
Tuning
In addition you could restyle the way boxes appear by editing MediaWiki:Common.css
div.mw-geshi {
padding: 1em;
margin: 0 0;
border: 1px dashed #2f6fab;
background-color: #f9f9f9;
}
Subpage list
If you allow subpages, it's good to be able to list them like this:
{{subpages:}}
Installation:
composer require "mediawiki/sub-page-list" "*@dev"
This will actually install a whole bunch of other extensions, if you don't already have them (data-values, param-processor, ...)
Cite
The Cite extension allows a user to create references as footnotes on a page. It adds two parser hooks to MediaWiki, <ref> and <references /> , these operate together to add citations to pages.
git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/Cite.git
In LocalSettings
include_once("$IP/extensions/Cite/Cite.php");
In installation directory
php maintenance/update.php
Cite this page
Helps people citing correctly a page.
cd extensions git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/CiteThisPage
In LocalSettings
require_once "$IP/extensions/CiteThisPage/CiteThisPage.php";
You then should include the item in the menu to the left.
- Edit MediaWiki:Sidebar
Wikilog
Old version
Wikilog is an extension that implements blogs within the wiki. Useful for various purposes like announcements, personal blogs, etc. Blogs use their own namespaced pages, but postings can be transcluded into wiki pages.
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 }}
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 ...)
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)
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.
Dynamic Page List 3
Dynamic page list allows creating various dynamic page list and also to do maintenance operations.
- Extension:DynamicPageList3
- Source on GitHub. It includes configuration information and basic use.
- complete manual at GamePedia.
Installation (as of oct. 2018)
git clone https://github.com/Alexia/DynamicPageList.git git checkout REL1_31
In Localsettings.php:
wfLoadExtension( 'DynamicPageList' ); // configuration $wgDplSettings['functionalRichness'] = 2
Google Analytics
Google Analytics allows to study user behaviors and demographics. If compatible with your privacy concerns you can install it.
- Firstly you will need a Google account and then register your website
- Retrieve the Tracking ID number, e.g. UA-1234567-1
cd extensions git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/googleAnalytics.git // adjust your branch git branch -r git checkout REL1_25
Minimal configuration in LocalSettings.php
require_once "$IP/extensions/googleAnalytics/googleAnalytics.php"; // REPLACE BY YOUR TRACKING NUMBER below $wgGoogleAnalyticsAccount = 'UA-12345678-1'; $wgGoogleAnalyticsIgnoreSpecials = array( 'Userlogin', 'Userlogout', 'Preferences', 'ChangePassword');
See also:
Extensions about users
Contribution Scores
The Contribution Scores extension polls the wiki database to locate contributors with the highest contribution volume – it is also in stable use on a high-volume wiki such as translatewiki.net. The extension is intended to add a fun metric for contributors to see how much they are helping out. The score is defined as (number of unique pages edited) + 2 * square root ((number of edits) - (number of unique pages edited)).
git clone https://git.wikimedia.org/git/mediawiki/extensions/ContributionScores.git
In Localsettings.php:
require_once("$IP/extensions/ContributionScores/ContributionScores.php"); # Some configuration options we use $wgContribScoreIgnoreBots = true; // Exclude Bots from the reporting $wgContribScoreIgnoreBlockedUsers = true; // Exclude Blocked Users from the reporting $wgContribScoresUseRealName = true; // Use real user names when available $wgContribScoreDisableCache = false; // Set to true to disable cache for parser function and inclusion of table.
Example:
Other extensions / not officially maintained
As we said before, many extensions are really simple to install and don't need any difficult work. See the Special:Version page for the ones we currently use.
- Most extensions we use and that are displayed in the Version page provide an URL that will directly lead you to the extensions download and documentation page.
Some extensions are no longer maintained but still work. Do not count on these ....
PageBy
The PageBy extension provides a custom tag, <pageby>, that renders as a summary of the pages edit history. It may be useful to provide a quick overview of who contributed to a page, especially on site with editorial nature, like news reports, blogs, etc.
Warning: This extension is fragile, e.g. it may not run in your wiki !! In this wiki, as of version 1.27, this extension is broken
Installation:
- In case you don't have svn (the version control system used prior to GitHub):
apt-get install subversion
svn co https://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/PageBy/
In LocalSettings.php
require_once("extensions/PageBy/PageBy.php");
Test: <pageby/>
Problems
User name not found
User names are not found after an upgrade, e.g. the user cannot log in and the wiki attempts to create a new user and then fails. Ghis happened to us on on wiki, migrating from 1.27 to 1.35
Fix:
cd maintenance php resetUserTokens.php
resetUserTokens.php file is a maintenance script to reset the user_token of users on the wiki. On the one hand it can reset the token for all users. Note that this may log some of them out. Resetting all tokens is not necessary unless you believe your user table has been compromised. On the other hand you can use the script to change those tokens, which currently are NULL. This is useful to improve security for the affected users.