Scompattare l'archivio, attribuire permessi/ownership opportuni e rendere provvisoriamente scrivibile la directory di configurazione:

tar zxvf ../mediawiki-1.8.2.tar.gz
chown -R root.root mediawiki-1.8.2
mv mediawiki-1.8.2 wiki
chmod 777 wiki/config

Puntare un browser all'indirizzo http://host/wiki/config/index.php. Rispetto ai valori predefiniti si sono cambiati:

Il database e l'utente sono stati creati a mano dall'utente privilegiato postgres, l'utente è stato designato come proprietario del database:

su - postgres
psql -h localhost template1

CREATE USER "giannirigacci" PASSWORD '************';
CREATE DATABASE "giannirigacci" OWNER "giannirigacci";

Alla fine si mette al suo posto il file di configurazione e si protegge nuovamente la directory di configurazione:

cd wiki/config
chown root.www-data LocalSettings.php
chmod 640 LocalSettings.php
mv LocalSettings.php ..
cd ..
chmod 755 config/

ATTENZIONE: Le istruzioni che seguono sono valide fino a PostgreSQL 8.2. A partire dalla versione 8.3 l'estensione contrib/tsearch2 è diventata obsoleta [1] in quanto direttamente integrata nel db.

Per la compatibilità con postgres 8.3 è necessario MediaWiki successivo alla revisione 31083, ad esempio la versione 1.13.0. Con MediaWiki 1.13.0 non è necessario caricare il layer di compatibilità contrib/tsearch2 fornito con PostgreSQL 8.3.

Per la migrazione di un database contrib/tsearch2 alla versione 8.3 leggere i documenti 12.12. Migration from Pre-8.3 Text Search e F.31. tsearch2.

Dentro al database si deve creare il linguaggio PL/PgSQL e le funzioni tsearch2 (per la ricerca a testo libero). Queste sono operazioni che deve fare l'utente privilegiato postgres:

su - postgres
createlang plpgsql giannirigacci
psql -h localhost giannirigacci

\i /usr/share/postgresql/8.1/contrib/tsearch2.sql
ALTER TABLE pg_ts_cfg OWNER TO giannirigacci;
ALTER TABLE pg_ts_cfgmap OWNER TO giannirigacci;
ALTER TABLE pg_ts_dict OWNER TO giannirigacci;
ALTER TABLE pg_ts_parser OWNER TO giannirigacci;

Per impedire la registrazione di nuovi utenti e l'editing delle pagine da parte di utenti non registrati si aggiungono al file LocalSettings.php le direttive:

// Only SysOp (Admin) can create accounts -
$wgGroupPermissions['*']['createaccount'] = false;
// No anonymous editing allowed -
$wgGroupPermissions['*']['edit'] = false;

Una delle pagine fondamentali di documentazione è quella che spiega come si creano i link MediaWiki.

Normalmente le pagine MediaWiki vivono in un namespace piatto, senza alcuna struttura gerarchica. Se si desidera invece utilizzare una gerarchia ad albero si devono attivare le sottopagine. Le sottopagine in genere sono attive solo per le pagine utente, per le discussioni e per i progetti (?).

Per abilitare l'utilizzo delle sottopagine anche nel namespace principale si aggiunge a LocalSettings.php:

// Enable subpages in the main namespace
$wgNamespacesWithSubpages[NS_MAIN] = true;

Per consentire l'upload di documenti (immagini, pdf, …) in LocalSettings.php ci deve essere:

$wgEnableUploads     = true;    # Enable uploads
$wgUploadSizeWarning = 1048576; # 1 MiB

Ovviamente il warning sulla dimensione del file può essere impostato a piacere. Le impostazioni generali del PHP devono ovviamente consentire l'upload dei file nella dimensione richiesta.

Si impostano i permessi opportuni alla directory images contenuta in MediaWiki:

chown root:www-data images
chmod 775 images

Nella directory images vengono create delle sottodirectory per velocizzare l'accesso ai file, il valore predefinito dei permessi per queste directory è 0777, per mettere un più sensato 0755 aggiungere in LocalSettings.php (richiede MediaWiki 1.13.0 o successivo):

// Default value for chmoding of new directories.
$wgDirectoryMode = 0755;

L'upload di un file in MediaWiki nasce per poter includere immagini nel testo, l'upload di file di altra natura avviene comunque in maniera analoga. Semplicemente il link sarà di tipo [[Media:file.ogg]] invece che [[Immagine:file.jpg]].

Tuttavia la configurazione predefinita prevede l'upload solo di alcuni formati, per abilitarne di altri si deve ridefinire in LocalSettings.php il contenuto della variabile $wgFileExtensions (definita in includes/DefaultSettings.php)

/**
 * This is the list of preferred extensions for uploading files. Uploading files
 * with extensions not in this list will trigger a warning.
 */
$wgFileExtensions = array( 'png', 'gif', 'jpg', 'jpeg', 'pdf' );

Per poter scrivere un link del tipo [[:it:Frase]] che si trasforma automaticamente in un link http://it.wikipedia.org/wiki/Frase, si deve avere una riga opportuna nel database di MediaWiki, ad esempio:

INSERT INTO interwiki (iw_prefix,iw_url,iw_local) VALUES ('it','http://it.wikipedia.org/wiki/$1',1);

Nella versione di MediaWiki da noi installata la riga di cui sopra non c'è, la si inserisce a mano oppure si utilizza il file maintenance/wikipedia-interwiki.sql (che è in sintassi MySQL, adattare eventualmente a PostgreSQL).

L'estensione ParserFunctions consente di scrivere - tra le altre cose - dei template di questo tipo:

{{ #if: {{{popolazione|}}} | {{{popolazione}}} }}

In questo esempio il dato della popolazione vine stampato solo se presente.

Per arginare il problema dello spam si è installata l'estensione ConfirmEdit. L'utente - prima di salvare una pagina - deve inserire una risposta a una domanda matematica, del tipo scrivi il risultato di 15 + 3.

Si scarica il programma nella directory extensions/ConfirmEdit/ e si aggiunge una riga in fondo a LocalSettings.php:

# Installed also the ConfirmEdit captcha.
require_once( "$IP/extensions/ConfirmEdit/ConfirmEdit.php" );

È possibile configurare alcuni parametri del plugin, editando il file ConfirmEdit.php oppure aggiungendo le opzioni in LocalSettings.php.

Esempio: si vuole popolare automaticamente il wiki con diverse migliaia di pagine a partire da un database.

1. Creare un nuovo account con login/password. Abbiamo scelto il nome InsertBot.
2. Aggiungere l'account creato al gruppo bot: si deve accedere come WikiSysop e poi procedere da Pagine speciali, Gestione dei permessi relativi agli utenti. Questo serve a nascondere le modifiche fatte dal robot dall'elenco delle ultime pagine modificate.
3. Si preleva il software python wikipediabot, c'è ovviamente bisogno dell'interprete Python. Abbiamo provato con lo snapshot CVS del 2007-01-31 prelevato da Sourceforge.
4. Scompattare l'archvio e creare un file pywikipedia/families/geodati_family.py che descrive il wiki su cui il robot deve intervenire:

   # -*- coding: utf-8  -*-
   import family
   # geodati.gfoss.it Wiki
   class Family(family.Family):
       def __init__(self):
           family.Family.__init__(self)
           self.name = 'geodati'
           self.langs = {
               'it': 'geodati.gfoss.it',
              }
           self.namespaces[4] = {
               '_default': [u'Geodati', self.namespaces[4]['_default']],
           }
           self.namespaces[5] = {
               '_default': [u'Discussioni Geodati', self.namespaces[5]['_default']],
           }
       def path(self, code):
           return '/wiki/index.php'

5. Inserire le credenziali per accedere al wiki nel file pywikipedia/user-config.py:

   mylang = 'it'
   family = 'geodati'
   usernames['geodati']['it'] = u'InsertBot'
   # password = '******'
   console_encoding = 'utf-8'

6. Creare uno script che effettui le operazioni richieste utilizzando le varie componenti disponibili in pywikipedia:

   #!/bin/sh
   python login.py -log
   python pagefromfile.py -start:'page_start' -end:'page_end' -notitle -file:input_file.txt

Il robot di cui sopra prende in pasto l'input_file.txt con l'elenco delle pagine da aggiungere ed esegue l'operazione. Il file è qualcosa del tipo:

page_start
'''Ari 5911'''
{{Centro abitato |
  |toponimo = Ari
  |regione = Abruzzi
  |provincia = Chieti
  |latitudine = 42.29234
  |longitudine = 14.263011
  |popolazione = 1328
  |codIstat = 069003
  |capComune = 1
  |fonte = Istat
}}
page_end
...

Durante l'aggiornamento può essere utile impostare in LocalSettings.php le seguenti variabili:

$wgSiteNotice = 'Aggiornamento del database in corso!';
$wgReadOnly = 'Il wiki è in sola lettura a causa dell\'aggiornamento del database.';

La prima stringa viene mostrata all'inizio di ogni pagina, la seconda viene mostrata quando si tenta di modificare una pagina.

Appunti per una migrazione da versione 1.9.2 a versione 1.13.0.

1. Backup della vecchia directory e del database.
2. Spostata la vecchia directory in altro posto.
3. Prelevato il nuovo archivio mediawiki-1.13.0.tar.gz e scompattato nella directory.
4. Recuperati dalla vecchia installazione:
   • LocalSettings.php
   • AdminSettings.php (if present)
   • extensions/
   • images/
   • Any custom skins in skins/
   • $wgUploadDirectory (custom upload directory)
   • Deleted file archives (where?)
5. Verificare che AdminSettings.php contenga le credenziali per accedere al database con sufficienti permessi (dovrebbe bastare essere il proprietario del database mediawiki).
6. entrare nella directory maintenance/ ed eseguire php update.php, controllare che non dia errori.

Nel caso specifico la procedura update.php non ha fatto tutto il lavoro necessario (vedere il bug 15281), è stato necessario aggiungere manualmente una colonna al database:

ALTER TABLE revision ADD rev_parent_id INT DEFAULT NULL;

Dopo l'aggiornamento della versione di MediaWiki si è provveduto ad aggiornare il database da 8.2 a PostgreSQL 8.3. Il problema principale è costituito dall'estensione tsearch2 che è diventata obsoleta. Anche il layer di compatibilità contrib/tsearch2 fornito con PostgreSQL 8.3 non è necessario con MediaWiki versione 1.13.0.

Una procedura di migrazione può essere questa:

1. Fare il dump del database vecchio (Postgres 8.2)
2. Creare la lista degli oggetti presenti nel dump
3. Filtrare la lista togliendo tutti gli oggetti relativi a tsearch2 e alcune funzioni MediaWiki che devono essere aggiornate
4. Creare il nuovo database in Postgres 8.3
5. Creare il linguaggio plpgsql nel nuovo database
6. Aggiungere le funzioni MediaWiki
7. Fare il restore selettivo in Postgres 8.3 utilizzando la lista “filtrata”.
8. Eseguire maintenance/update.php

In dettaglio:

Il proprietario del data base effettua il dump e crea una lista degli oggetti di cui fare il restore con lo script mediawiki_upgrade_dblist_filter:

pg_dump --cluster 8.2/main -Fc -U dbuser -W -d dbname > dbname.dump
pg_restore --cluster 8.2/main --list dbname.dump > dbname.dump.list
cat dbname.dump.list | ./mediawiki_upgrade_dblist_filter > dbname.dump.list.filtered

L'amministratore di PostgreSQL crea il nuovo database:

psql --cluster 8.3/main

CREATE USER "dbuser" PASSWORD '******';
CREATE DATABASE "dbname" OWNER "dbuser";

L'amministratore PosgreSQL oppure

Il proprietario del database crea il linguaggio plpgsql nel database stesso. Se il proprietario del database non può creare il linguaggio (vedere le limitazioni sull'istruzione CREATE LANGUAGE), lo deve fare l'amministratore.

\connect dbname
CREATE LANGUAGE plpgsql

Il proprietario del database crea nuovamente le funzioni MediaWiki ed effettua il restore selettivo:

psql --cluster 8.3/main -U dbuser -W -d dbname -f maintenance/postgres/archives/patch-tsearch2funcs.sql
pg_restore --cluster 8.3/main -U dbuser -W -L dbname.dump.list.filtered -d dbname dbname.dump

Il webmaster esegute l'update di MediaWiki:

cd maintenance
php update.php

Il passaggio di database PostgreSQL da 8.3 a 8.4 pare che non crei problemi, è sufficiente un dump/restore.

Ci sono problemi con la versione 1.13 di MediaWiki, ad esempio a causa del bug 15854 con PHP 5.3. Questi i messaggi di errore:

PHP Warning:  Parameter 2 to Parser::parse() expected to be a reference, value given in
    /home/www/wiki/includes/StubObject.php on line 58
PHP Fatal error:  Call to a member function getText() on a non-object in
    /home/www/wiki/includes/OutputPage.php on line 530

• MediaWiki is Postgres 8.3 compatible
• MediaWiki revision 31083
• Upgrading PostgreSQL 8.2 to 8.3 (mediawiki)
• Upgrading MediaWiki from PostgreSQL 8.2 to 8.3
• MediaWiki: Upgrading Postgres
• PostgreSQL Feature Matrix
• Tsearch2 compatibility layer for Postgres 8.3
• Upgrading to 8.3 - MediaWiki lessons learned