This is an old revision of the document!
Table of Contents
MediaWiki 1.21.3 su Debian Wheezy
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/
Bug PostgreSQL "uploadstash"
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;
Bug PostgreSQL metadata "type bytea"
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),
Problema thumbnail PDF
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
.
Estensione MobileFrontend
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"; $wgMFAutodetectMobileView = true; $wgUseFileCache = false; // otherwise autodetection won't be reliable
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:
useformat=mobile | Forza la richiesta della versione mobile. |
---|---|
mobileaction=toggle_view_mobile | Passa alla visualizzazione per dispositivo mobile. |
mobileaction=toggle_view_desktop | Passa alla visualizzazione normale. |
Questa suluzione è poco performante, perché deve impostare $wgUseFileCache a false e quindi non sfrutta la cache.
Configurazione di un dominio apposito per il mobile
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. L'header da aggiungere è X-Device
, che deve avere uno dei valori indicati in questo file (si consiglia il generico mobi
). Questi i passaggi per la configurazione:
- Aggiungere un nome al DNS, ad esempio per il dominio
www.mydomain.org
si può usarewww.m.mydomain.org
(dove m sta per mobile). - Definire in
LocalSettings.php
la variabile $wgMobileUrlTemplate:$wgMobileUrlTemplate = '%h0.m.%h1.%h2';
Attenzione al bug 58321! la variabile deve inizare con un segnaposto
%h
altrimenti non viene usata correttamente! - Configurare il
VirtualHost
in Apache per il dominio mobile, in esso impostare l'headerX-Device
. 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>
):<ifModule mod_headers.c> <VirtualHost *:80> ServerName www.m.mydomain.org RequestHeader set X-Device "mobi" ... </VirtualHost> </ifModule>
C'è un problema (versioni: MediaWiki 1.21.3, MobileFrontend 30dad7e). Avendo attivato il dominio specifico per il mobile (come descritto sopra), il link in basso per passare dalla versione normale a quella mobile non contiene il parametro
mobileaction
, ma si basa solo sulla richiesta del dominio mobile. Purtroppo il cookie stopMobileRedirect
inibisce il cambio e si ottiene la versione desktop anche sul dominio mobile. Un fix può essere quello di forzare l'aggiunta del parametro, modificando il file extensions/MobileFrontend/includes/MobileFrontend.hooks.php
:
115c115 < $queryString = strlen( $wgMobileUrlTemplate ) ? '' : 'mobileaction=toggle_view_mobile'; --- > $queryString = 'mobileaction=toggle_view_mobile';
Questa soluzione non è ancora compatibile con
$wgUseFileCache
. Alcune pagine mobile vengono generate con uno stile sbagliato (titoli non cliccabili e quindi sezione non espandibile), indagare se si tratta di un problema legato a $wgMFAutodetectMobileView
oppure al fatto che la cache non viene effettivamente popolata.
Attivazione cache
Vedere come si attiva e se è compatibile con tutte le altre estensioni, soprattutto con l'autodetect del dispositivo mobile/desktop.
Estensione Pdf Export
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 snapshow, 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 comandohtmldoc
. - 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.
Estensione PDF Writer
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";
Con la Collection installata si ha già la funzione Scarica come PDF, che però si appoggia per il rendering su un servizio gratuito di PediaPress.
Problemi:
- La larghezza delle celle di una tabella non viene onorata nel PDF prodotto.
Login con Facebook
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.
Rimozione utenti
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.
Permessi
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
Debug
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;
Estensione ConfirmAccount
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
Estensioni varie
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 />
MediaWiki installazione Debian
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:
Wiki name | GianniRigacci |
---|---|
Language | it |
You have selected the | Attribution 2.5 License |
Admin username | WikiSysop |
Password | *************** |
Database type | PostgreSQL |
Database name | giannirigacci |
DB username | giannirigacci |
DB password | *************** |
Schema for mediawiki | public |
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/
Ricerca a testo libero (tsearch2)
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.
PostgreSQL fino alla versione 8.2
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;
Editing solo per utenti registrati
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;
Abilitazione delle sottopagine
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;
Abilitazione upload
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;
Upload di file .pdf
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' );
Abilitare link interwiki
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).
Estensione ParserFunctions
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.
Estensione ConfirmEdit
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 = '*********************';
Creazione di un Wiki bot
Esempio: si vuole popolare automaticamente il wiki con diverse migliaia di pagine a partire da un database.
- Creare un nuovo account con login/password. Abbiamo scelto il nome InsertBot.
- 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.
- 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. - 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'
- 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'
- 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 ...
Aggiornamento versione
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:
- Fare un backup dei file e del database.
- Scompattare l'archivio in una nuova directory (es.
wiki.new
). - Preparare le directory copiandoci il vecchio
LocalSettings.php
, leextensions
, le eventuali skin. - Vedere le release notes se ci sono cambiamenti da fare al
LocalSettings.php
. - Mettere in read only aggiungendo in
LocalSettings.php
qualcosa del genere:
$wgReadOnly = 'Upgrading to MediaWiki 1.22.5';
. - eseguire da riga di comando nella nuova directory:
cd maintenance
php ./update.php
- Copiare la directory
images
dalla vecchia installazione. - Scambiare la vecchia con la nuova directory..
Da MediaWiki 1.9.2 a 1.13.0
Appunti per una migrazione da versione 1.9.2 a versione 1.13.0.
- Backup della vecchia directory e del database.
- Spostata la vecchia directory in altro posto.
- Prelevato il nuovo archivio mediawiki-1.13.0.tar.gz e scompattato nella directory.
- 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?)
- Verificare che
AdminSettings.php
contenga le credenziali per accedere al database con sufficienti permessi (dovrebbe bastare essere il proprietario del database mediawiki). - entrare nella directory
maintenance/
ed eseguirephp 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;
Da PostgreSQL 8.2 a 8.3
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:
- Fare il dump del database vecchio (Postgres 8.2)
- Creare la lista degli oggetti presenti nel dump
- Filtrare la lista togliendo tutti gli oggetti relativi a tsearch2 e alcune funzioni MediaWiki che devono essere aggiornate
- Creare il nuovo database in Postgres 8.3
- Creare il linguaggio plpgsql nel nuovo database
- Aggiungere le funzioni MediaWiki
- Fare il restore selettivo in Postgres 8.3 utilizzando la lista “filtrata”.
- 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
Da Debian Lenny a Debian Squeeze
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
Da 1.13 a 1.21.2
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.