Mediawiki installation

The educational technology and digital learning wiki
Jump to navigation Jump to search

This article or section is currently under construction

In principle, someone is working on it and there should be a better version in a not so distant future.
If you want to modify this page, please discuss it with the person working on it (see the "history")

Some installation tips, in particular for an educational context. This documentation should be extended/completed - Daniel K. Schneider (talk) 16:18, 16 January 2014 (CET) - Daniel K. Schneider (talk) 18:02, 9 April 2015 (CEST)

Also consider buying Yaron Koren's book

See also:

Installation tips are for Ubuntu. The old version runs under Solaris (IMHO a superior but much more difficult environment, this is why we decided to switch).

First time installation and upgrading

These instructions are being upgraded to describe installation of MW 1.25 (early 2015) using Ubuntu 14LTS

I also recommend installing your favorite text editor (I have been using the same thing for the last 30+ years: emacs)


Installation of essential Ubuntu/Debian software

(taking notes for a fresh installation Daniel K. Schneider (talk) 13:42, 9 April 2015 (CEST) - should be ok in a few days)

Prerequisites

  • Starting point: Ubuntu 14.04.2 LTS
  • PHP/Apache/MySQL and curl installed
  • PHPMyAdmin installed (not really needed)
sudo apt-get install apache2 mysql-server php5 php5-mysql libapache2-mod-php5 php5-cli phpmyadmin
  • Sendmail (postfix) installed and configured
    • Check if /etc/postfix is there

This section summaries software that must be installed if you plan to use all sorts of interesting extensions.

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

It is better to have them installed before installing the Mediawiki, since the installation script can detect and configure these

  • php-apc is a caching system
  • php5-intl provides unicode support
  • imagemagick allows to create thumbnails.
sudo apt-get install php-apc php5-intl imagemagick
#restart is needed !!
apache2ctl restart

Additional web services

Node.js

This is a JavaScript web server and is needed for the Visual editor

Mw-lib

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


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

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.

Site files are located in the following directory: 

/etc/apache2/sites-available/

Contents of /etc/apache2/sites-available/mediawiki (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 tightend. You cannot just declare an Alias. In addition, you must provide directory access explicitly to all 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 ln -s ../sites-available/mediawiki.conf .

Test it: 

apache2ctl restart

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

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.

  • Edit file /etc/php5/apache2/php.ini
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 accomodate. 

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

Get the core

Go to your installation parent directory 

cd /portails

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

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

Now make sure to select the right version, e.g. as of April 2015, this provides the latest MW beta version. 

git checkout REL1_25

Move the directory 

# if needed
rmdir wikitest
# 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://git.wikimedia.org/git/mediawiki/skins/Vector.git

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

Initial configuration

Go to the nice wiki URL

Environmental checks should be just fine, e.g. you should see something like this: 

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 LocaSettings.php and create short URLs

The script will only generate: 

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

Add the following line: 

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

Updating with GIT

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

Updating the same version: 

git pull
php maintenance/update.php

Changing versions: 

git checkout <new version>
for example
git checkout REL1_23

Tips:

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

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

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

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

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

Fighting spam

For maintaining a spam free wiki there are only too 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.

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 repository
git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/ConfirmAccount.git

# Go to ConfirmAccount directory
cd ConfirmAccount/

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

# Adjust the version number
git checkout REL1_24

Notice:

  • As of April 10 2015 you will get the Could not create directory "mwstore://accountcreds-backend/accountcreds-public/w/wi/wik" error message if you install MW1_25 and Confirm Account REL1_25. Work around, type:
git checkout REL1_24

Now install ConfirmEdit 

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

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 some kind of captcha. The best solution would be creating domain-specific text questions with difficult (but not too difficult answers). To do this correctly would require some work. We therefore chose to install recaptcha.

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

# Anti Spam ConfirmEdit
# Recaptcha relies on ConfirmEdit, but only ONE needs to be loaded
# require_once("extensions/ConfirmEdit/ConfirmEdit.php");

# Confirm Account
require_once("$IP/extensions/ConfirmAccount/ConfirmAccount.php");
$wgAllowAccountRequestFiles = false;
$wgConfirmAccountContact = "daniel.schneider@unige.ch";
$wgConfirmAccountRequestFormItems['Biography']['minWords'] = 10 ;

# ReCaptcha
# See the docs in extensions/recaptcha/ConfirmEdit.php
# http://wiki.recaptcha.net/index.php/Main_Page
require_once( "$IP/extensions/ConfirmEdit/ConfirmEdit.php" );
require_once( "$IP/extensions/ConfirmEdit/ReCaptcha.php" );
$wgCaptchaClass = 'ReCaptcha';
$wgReCaptchaPublicKey = '.... your key .....';
$wgReCaptchaPrivateKey = '.... your key .....';

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

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:

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

Another way way of using it is to define $wgSiteNotice = " ........ "; in LocalSettings.php

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 extensions just won't work with other skins.

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

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/p/mediawiki/skins/Vector.git

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

git checkout REL1_25

In Localsettings, load it: 

require_once "$IP/skins/Vector/Vector.php";
$wgDefaultSkin = 'vector';

Get all skins with GIT 

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

The, switch to the skins folder, that was just cloned. To get all the skins use: 

git submodule update --init --recursive

Changes to the navigation bar to the left

Reading: Navigation bar help

Configuration: Edit MediaWiki:Sidebar 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.

  • To list the prefixes in 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>

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

Extensions

Notice: This section should be moved to a different page and be merged with some contents of the Mediawiki page - Daniel K. Schneider (talk) 17:04, 21 August 2013 (CEST)

See also the Mediawiki article where we list extensions we find useful to have. Here, we only document installation and/or 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.

The easy method

If you use a bleeding Mediawiki edge server then you simply can cut/past git commands into a terminal

General extension installation principles

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. 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 (e.g. a days work!), sometimes nothing). 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
php maintenance/update.php
  • Sometimes you need to define templates, modify the CSS, etc.

Installing extensions with Composer

After mid-november 2013, you should learn how to use composer, a PHP dependency manager. It should work with the following:

Installing Composer
  • 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


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

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

Graphviz itself needs several libraries like GD, Zlib, Freetype, PNG, JPEG, EXPAT, etc. (read http://www.graphviz.org/Download_source.php Requirements).

There exist binary packages for most systems (not yet tested)

Tag cloud

There are several tag cloud extensions, we use the following one (at the time of writing)

Extension page: http://www.mediawiki.org/wiki/Extension:WikiCategoryTagCloud

Extension page (old): http://wiki-tools.com/wiki/Wiki_Category_Tag_Cloud

Additional installs: None

Hints:

  • If you want an accurate cloud, you should edit MediaWiki:Tagcloudpages and add the pages to invalidate the cache for.

UML extension

UML is an extension that allows to generate graphs from MetaUML format. This extension dates back to 2007, but still seems to work. MetaUML also was kind of sleeping, but seems to be an active project again (Aug 2009).

Update: Removed in 2013 since (1) it worked less well and (2) because it is dangerous if you got a nasty user...

Most important documentation and download pages
Extension page: http://www.mediawiki.org/wiki/Extension:UML
Additional installs
MetaUML from http://metauml.sourceforge.net/
Dependencies
ImageMagick and Ghostscript

SVG visualization

See: Mediawiki SvGViz extension

Other extensions

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 provide an URL that will directly lead you to the extensions download and documentation page.

Retrieved from "https://edutechwiki.unige.ch/mediawiki/index.php?title=Mediawiki_installation&oldid=55421"