I requisiti di MediaWiki sono soddisfatti dai pacchetti base Debian: apache2, php5 e postgresql-9.1. In particolare il database PostgreSQL include il supporto tsearch e plpgsql senza richiedere pacchetti aggiuntivi. Per la gestione delle miniature delle immagini installare anche imagemagick oppure php5-gd. Per migliorare le performance si può considerare l'installazione del pacchetto php-apc che provvede al caching del bytecode PHP.

CREATE USER "dbuser" PASSWORD 'MySecret';
CREATE DATABASE "dbname" OWNER "dbuser"
    LC_COLLATE = 'it_IT.UTF-8' LC_CTYPE = 'it_IT.UTF-8'
    TEMPLATE template0;

Per consentire l'upload di file:

chgrp www-data images/
chmod 775 images/

Qualche problema pare che esista nel supporto PostgreSQL. In alcune circostanze l'upload dei file fallisce con il messaggio di errore ERROR: column “us_props” of relation “uploadstash” does not exist. In effetti la colonna manca nella tabella. Vedere questo bug report. Si può aggiungere la colonna mancante nel database:

ALTER TABLE mediawiki.uploadstash ADD COLUMN us_props BYTEA NULL;

Il bug 52017 (risolto nella versione 1.22.5) impedisce di caricare file che abbiano un backslash nei metadati, mostrando l'errore invalid input syntax for type bytea.

Modificare il file includes/filerepo/file/LocalFile.php, sostituendo le occorrenze di

'img_metadata'   => $this->metadata,

con

'img_metadata'    => $dbw->encodeBlob($this->metadata),

Durante l'upload di file PDF si può ottenere l'errore: Errore nella creazione della miniatura: gs: error while loading shared libraries: librt.so.1: failed to map segment from shared object: Cannot allocate memory.

L'errore avviene durante l'esecuzione del comando gs per la conversione del PDF in immagine, è possibile abilitare il debug dei comandi eseguiti mettendo in LocalSettings.php qualcosa del tipo:

$wgDebugLogFile = "/tmp/mediawiki-debug.log";

Lo stesso comando gs genera correttamente la miniatura se eseguito da riga di comando, il problema sono i limiti di memoria e di dimensione file allocati, il default per entrambi di 100 Mb può essere aumentato con:

// Maximum amount of virtual memory available to shell processes under Linux, in KB.
$wgMaxShellMemory = '262144';
// Maximum file size created by shell processes under Linux, in KB.
$wgMaxShellFileSize = '102400';

Per rigenerare la miniatura basta chiamare la pagina File: aggiungendo il parametro ?action=purge.

L'estensione MobileFrontend consente di avere automaticamente un tema adeguato su dispositivi con piccolo schermo (tipicamente smartphone). Si è scaricata la versione apposita per l'attuale versione stabile di MediaWiki, l'archivio deve essere scompattato in una directory extension/MobileFrontend/.

Quindi in fondo al file LocalSettings.php si aggiunge:

require_once "$IP/extensions/MobileFrontend/MobileFrontend.php";
$wgMobileFrontendLogo = "$wgScriptPath/logo-mobile.png";
// Mobile/desktop autodetection is incompatible with front-end cache.
$wgMFAutodetectMobileView = true;
// Disable cache if $wgMFAutodetectMobileView is true.
$wgUseFileCache = false;

Della Pagina principale non viene mostrato nulla in versione mobile. La parte che si vuole mostrare (eventualmente tutta) deve essere esplicitamente racchiusa in uno specifico <div>:

<div id="mf-home">
</div>

Con questa estensione si possono passare alcuni parametri nell'URL:

Questa suluzione è poco performante, perché deve impostare $wgUseFileCache a false e quindi non sfrutta la cache.

ATTENZIONE: Questa ricetta va bene per MediaWiki 1.22, con MobileFrontend opportuno (aprile 2014). Nelle versioni più recenti (es. MediaWiki 1.30 e MobileFrontend di febbraio 2018) non esiste più la gestione dell'header speciale, tutto sembra più semplice e automatico.

I siti della WikiMedia Foundation (Wikipedia) utilizzano un trucco per fornire la versione desktop e mobile contemporaneamente: attivano un dominio apposito per il mobile (ad esempio it.m.wikipedia.org) e su quello forzano l'output per dispositivo mobile. Il trucco si basa su un header HTTP che viene aggiunto dal server web (in Apache occorre il modulo mod_headers) e che l'estensione MobileFrontend intercetta. Il cookie stopMobileRedirect dovrebbe garantire che il sito si presenta sempre nella veste preferita, dopo che l'utente ha cliccato sul link versione mobile o versione desktop.

L'header da aggiungere è X-WAP. Questi i passaggi per la configurazione:

1. Aggiungere un nome al DNS, ad esempio per il dominio www.mydomain.org si può usare www.m.mydomain.org (dove m sta per mobile).
2. Definire in LocalSettings.php la variabile $wgMobileUrlTemplate e disabilitare l'autodetect (sarà poi possibile abilitare la cache):

   $wgMobileUrlTemplate = '%h0.m.%h1.%h2';
   $wgMFAutodetectMobileView = false;

   Attenzione al bug 58321! la variabile deve inizare con un segnaposto %h altrimenti non viene usata correttamente!

3. Configurare il VirtualHost in Apache per il dominio mobile, in esso impostare l'header X-WAP. Apache aggiungerà l'header alla richiesta di una pagina dal dominio mobile e l'estensione di MediaWiki servirà la versione opportuna (con Apache 2.4 si potrebbe sfruttare la direttiva <If> invece di avere un VirtualHost dedicato):

   <ifModule mod_headers.c>
     <VirtualHost *:80>
       ServerName www.m.mydomain.org
       RequestHeader set X-WAP "no"
       ...
     </VirtualHost>
   </ifModule>

ATTENZIONE: L'utilizzo dell'header X-WAP può generare confusione, ma tant'è! Si sono verificati i sorgenti e si è verificato che funziona con la versione 2e0af84 REL1_22. In qualche vecchia documentazione è scritto di utilizzare l'header X-Device, ma questo non risulta dai sorgenti né funziona.

Questa soluzione dovrebbe essere compatibile con $wgUseFileCache.

Vedere come attivare la cache e se è compatibile con tutte le altre estensioni, soprattutto con l'autodetect del dispositivo mobile/desktop.

NOTA: Questa estensione è stata scartata in favore della Estensione PDF Writer.

NOTA: qualora si utilizzi il backend HTMLDoc questa soluzione è fortemente penalizzata dall'impossibilità di utilizzare gli stili. Installando altri backend (es. MWLib) si possono utilizzare altre estensioni, forse più flessibili.

Esistono alcune estensioni per esportare pagine di MediaWiki in PDF, per una breve panoramica vedere l'articolo PDF Export for MediaWiki. Noi abbiamo provato la Pdf Export che pare avere alcune caratteristiche buone:

• Consente di esportare facilmente un singolo articolo. Per contro la PdfBook è più complessa, ma consente di creare dei veri e propri libri con gli articoli che appartengono ad una stessa categoria.
• Effettua una conversione in HTML e poi chiama un backend a scelta tra HTMLDoc, DomPdf, MWlib, MPdf, e PrinceXML.

Anzitutto abbiamo avuto un problema con lo snapshot 13c60af scaricato dal download snapshot, perché in realtà quello non è compatibile con MediaWiki 1.21.3. Come si legge da questo post, si è dovuto sostituire tutte le occorrenze di wfLoadExtensionMessages() in PdfExport.php e PdfExport_body.php con

//wfLoadExtensionMessages('PdfPrint');
wfMessage('PdfPrint');

Per attivare l'estensione basta installare il pacchetto Debian htmldoc e aggiungere in LocalSettings.php:

// Enable PDF export using HTMLDoc backend.
require_once("$IP/extensions/PdfExport/PdfExport.php");
$wgPdfExportHtmlDocPath = '/usr/bin/htmldoc';

L'estensione risulta installata visitando la pagina Speciale:Versione e nel menu Strumenti compare il link Stampa in formato PDF.

Questi sono i problemi non risolti:

• Stampa dei caratteri multibyte, ad esempio il simobolo di euro. Non c'è il supporto UTF-8, ma dovrebbe essere possibile indicare il charset di origine, ad esempio passando il parametro --charset iso-8859-15 al comando htmldoc.
• Mancano gli stili (es. le tabelle sono senza bordo), formato pagina, margini, caratteri, intestazioni e piè di pagina. Non è possibile con il backend HTMLDoc, che non supporta i fogli di stile.

L'estensione PDF Writer utilizza come backend di rendering la libreria MWlib, espressamente scritta per il rendering in PDF di documenti MediaWiki. Il motore di rendering può essere anche remoto, il sito PediaPress che sponsorizza lo sviluppo dell'estensione fornisce un servizio demo di questo tipo.

Come prerequisito di deve installare l'estensione Collection e attivarla in LocalSettings.php:

// The Collection extension is required by PDF Writer extension.
require_once "$IP/extensions/Collection/Collection.php";

Nella sezione Stampa/esporta del menu a sinistra compare la voce Crea un libro e Scarica come PDF. Quest'ultima funzione è disponibile anche con la sola estensione Collection, ma in quel caso si appoggia per il rendering ad un servizio gratuito di PediaPress.

Problemi:

• La larghezza delle celle di una tabella non viene onorata nel PDF prodotto.

Si può utilizzare l'estensione Facebook che permette agli utenti di autenticarsi tramite account Facebook.

Si scompatta l'archivio in una directory extensions/Facebook/, accertarsi di aver installato il pacchetto Debian php5-curl, quindi aggiungere in fondo a LocalSettings.php:

// Facebook Connect
require_once("$IP/extensions/Facebook/Facebook.php");
$wgFbAppId     = '47406044892';
$wgFbSecret    = '04137a722facf86d075f737ab6e93818';
$wgFbNamespace = 'my_wiki';

è necessario creare un App su Facebook e ottenere la chiave: connettersi a https://developers.facebook.com/apps/?action=create e seguire la procedura. Bisogna anche registrarsi come sviluppatore, procedura che richiede una autenticazione almeno con SMS su cellulare.

Un utente che si collega usando Facebook potrà scegliere il proprio nome sul wiki e potrà anche ottenere una password sul wiki seguendo la procedura di password dimenticata. L'attivazione avviene tramite password temporanea inviata all'indirizzo email registrato su Facebook. In questo modo l'utente potrà collegarsi indifferentemente con Facebook o con la password del wiki.

Nonostante che il MediaWiki sia configurato con $wgLanguageCode = "it";, l'utente collegato con Facebook viene accolto con la lingua inglese se ha impostato tale lingua su Facebook. Anche se cambia tale impostazione nelle preferenze, al successivo login la lingua viene nuovamente reimpostata.

Nel database di MediaWiki si possono trovare le tabelle relative alla relazione tra utenti MediaWiki e utenti Facebook:

SELECT * FROM mediawiki.user_fbconnect ;
SELECT user_id,user_name FROM mediawiki.mwuser;

In teoria non esiste un sistema per rimuovere un utente registrato, esistono eventualmente alcune estensioni, ma bisogna verificarne la compatibilità e l'efficacia. Tuttavia per un utente creato per prova (via Facebook login) dovrebbe essere sufficiente eliminare due righe dal database. Sembra che il database abbia i vincoli di integrità apportuni, quindi dovrebbe essere impossibile eliminare record che sono collegati ad altre tabelle.

SELECT user_id, user_name, user_email FROM mediawiki.mwuser;
DELETE FROM mediawiki.user_fbconnect WHERE user_id = 5;
DELETE FROM mediawiki.mwuser WHERE user_id = 5;

Attenzione che alcune informazioni restano in altre tabelle e non sono collegate, ad esempio un eventuale blocco impostato su quell'utente resta ed è riferito al nome utente non all'ID.

Seza le opportune precauzioni è possibile ritrovarsi decine di migliaia di utenti registrati a causa di bot automatici. Alcuni addirittura dopo aver scavalcato le protezioni contro la registrazione automatica (es. ConfirmEdit con ReCaptcha) mandano anche la mail di conferma. In pratica sembra che l'unica politica efficace sia quella di confermare i nuovi in modo manuale, con l'estensione ConfirmAccount.

Nel caso in cui il danno sia già fatto è opportuno rimuovere gli account fake creati, che spesso restano dormienti fino al momento in cui verranno utilizzati. Sembra che lo strumento più efficace sia l'estensione UserMerge.

Con questa estensione si può fare il merge di un utente fasullo nell'account Anonymous, e quindi cancellarlo. Al termine di questa procedura è possibile eventualmente eliminare tutti i contributi fasulli con l'estensione built-in Nuke.

Ecco come avere l'elenco degli account non confermati via mail:

SELECT user_name FROM mwuser WHERE user_email_authenticated IS NOT NULL;

Se si tratta di migliaia di utenti sarebbe necessario un sistema per automatizzare la procedura di UserMerge.

Un normale utente non può gestire i permessi utente (assegnamento a gruppi, ecc.), bisogna che venga assegnato al gruppo burocrati. Lo fa l'amministratore del wiki accedendo alla pagina speciale Speciale:PermessiUtente.

Esempio: gli utenti normali possono creare/modificare solo le pagine Discussione:. Solo gli utenti certificati (un gruppo creato ad-hoc) possono creare/modificare le pagine nel namespace principale. Putroppo è necessario proteggere tutti i namespace, ad eccezione di NS_TALK. Ecco la ricetta:

// See http://www.mediawiki.org/wiki/Manual:Namespace_constants
// Protect almost all the namespaces.
foreach(array
    (
        NS_MAIN, NS_USER, NS_USER_TALK, NS_PROJECT, NS_PROJECT_TALK, NS_FILE,
        NS_FILE_TALK, NS_MEDIAWIKI, NS_MEDIAWIKI_TALK, NS_TEMPLATE, NS_TEMPLATE_TALK,
        NS_HELP, NS_HELP_TALK, NS_CATEGORY, NS_CATEGORY_TALK, NS_MEDIA
    ) as $ns) {
    $wgNamespaceProtection[$ns] = array('edit-namespaces');
}
// Grant edit permission for protected namespaces to some groups.
$wgGroupPermissions['certified' ] = $wgGroupPermissions['user'];
$wgGroupPermissions['certified' ]['edit-namespaces'] = true;
$wgGroupPermissions['sysop'     ]['edit-namespaces'] = true;
$wgGroupPermissions['bureaucrat']['edit-namespaces'] = true;

ATTENZIONE, il namespace NS_SPECIAL non deve essere protetto altrimenti non è possibile la registrazione dei nuovi utenti, ma si otterrebbe un errore del tipo:

[7d0dcce2] 2013-12-21 08:34:53: Fatal exception of type MWException

Nel caso si verifichi qualche errore in MediaWiki (MWException) è possibile avere qualche dettaglio in più e il calltrace mettendo questo in LocalSettings.php:

$wgShowExceptionDetails = true;

Il problema dello SPAM non si ferma: nonostante il plugin ConfirmEdit che richiede un utente registrato e confermato (con invio di mail) prima di editare una pagina e nonostante l'uso di ReCaptcha che vuole la lettura di due immagini prima di effettuare la registrazine di un utente, si contano decine e decine di registrazioni fasulle al giorno, alcune di queste vengono anche confermate con la mail e quindi possono vandalizzare o creare nuove pagine.

Si è deciso di attivare l'esetensione ConfirmAccount, ogni utente deve essere autorizzato da un burocrate prima di essere registrato.

Si scompatta l'archivio in extensions/ConfirmAccount, quindi si aggiunge in LocalSettings.php:

require_once( "$IP/extensions/ConfirmAccount/ConfirmAccount.php");

Infine si aggiorna il database:

cd maintenance
php update.php

Due impostazioni molto utili: aggiungere alcune funzioni al parser - come il costrutto #if - con l'estensione ParserFunctions e aggiungere la possibilità di caricare file .PDF:

require_once("$IP/extensions/ParserFunctions/ParserFunctions.php");
$wgFileExtensions[] = 'pdf';

L'estensione Cite

require_once("$IP/extensions/Cite/Cite.php");

consente di aggiungere le note a pié di pagina in questo modo:

According to scientists, the Sun is pretty big.<ref>E. Miller, The Sun,
(New York: Academic Press, 2005), 23-5.</ref> The Moon, however, is not
so big.<ref>R. Smith, "Size of the Moon", Scientific American, 46 (April
1978): 44-6.</ref>

==Notes==
<references />

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.

Per avere qualcosa di più robusto della domanda matematica di cui sopra (viene forzata meccanicamente da diversi bot) si può attivare il plugin reCAPTCHA. Basta registrarsi sul sito per ottenere la coppia di chiavi ed aggiungere in LocalSettings.php:

require_once( "$IP/extensions/ConfirmEdit/ConfirmEdit.php" );
require_once "$IP/extensions/ConfirmEdit/ReCaptcha.php";
$wgCaptchaClass = 'ReCaptcha';
$wgReCaptchaPublicKey = '*********************';
$wgReCaptchaPrivateKey = '*********************';

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 installa il softwaer Pywikibot facendo riferimento alla Quick Start Guide, c'è ovviamente bisogno dell'interprete Python. Si scarica la versione core usando il comando git clone (accedere al repository da Sourceforge) oppure si scarica l'archivio dal repository Pywikibot Nightlies.
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
...

ATTENZIONE: La procedura di aggiornamento del database può essere eseguita via web oppure da riga di comando, l'esperienza insegna che conviene farla da riga di comando, in modo da aver maggior controllo su eventuali messaggi di errore, ecc.

In generale l'aggiornamento può essere fatto con il sito on-line. Anche la procedura web di aggiornamento del database è protetta contro l'esecuzione accidentale perché richiede di inserire una chiave apposita $wgUpgradeKey in LocalSettings.php.

Ad ogni modo durante l'aggiornamento si può 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.

Questa la procedura generica di aggiornamento sicuro:

1. Fare un backup dei file e del database.
2. Scompattare l'archivio in una nuova directory (es. wiki.new).
3. Preparare le directory copiandoci il vecchio LocalSettings.php, le extensions, le eventuali skin.
4. Vedere le release notes se ci sono cambiamenti da fare al LocalSettings.php.
5. Mettere in read only aggiungendo in LocalSettings.php qualcosa del genere:
   $wgReadOnly = 'Upgrading to MediaWiki 1.22.5';.
6. eseguire da riga di comando nella nuova directory:
   cd maintenance
php ./update.php
7. Copiare la directory images dalla vecchia installazione.
8. Scambiare la vecchia con la nuova directory..

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

Ci sono stati degli intoppi seguendo la procedura di upgrade via web (/mw-config/index.php): in quel modo il messaggio di errore non è visibile, semplicemente uno dei passaggi si blocca e la pagina web resta appesa. Eseguendo la procedura da riga di comando (cd maintenance; php ./update.php) si è visto che il problema era tentare di aggiungere una chiave primaria in una tabella che conteneva chiavi duplicate:

The last attempted database query was:
"CREATE UNIQUE INDEX ipb_address_unique ON ipblocks (ipb_address,ipb_user,ipb_auto,ipb_anon_only)"
...
Database returned error "23505: ERROR:  could not create unique index "ipb_address_unique"
DETAIL:  Key (ipb_address, ipb_user, ipb_auto, ipb_anon_only)=(203.212.17.169, 0, 0, 1) is duplicated.

Dopo aver fatto il restore del database dall'ultimo dump si è provveduto a togliere il record incriminato:

DELETE FROM ipblocks WHERE ipb_id = 4;

a quel punto la procedura pare aver funzionato correttamente.

• 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