%%''**:
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 [[http://www.mediawiki.org/wiki/Manual:$wgUseFileCache|$wgUseFileCache]] a false e quindi non sfrutta la [[http://www.mediawiki.org/wiki/Manual:File_cache|cache]].
==== Configurazione di un dominio apposito per il mobile ====
**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:
- 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).
- Definire in **''LocalSettings.php''** la variabile [[http://www.mediawiki.org/wiki/Extension:MobileFrontend/Configuring_browser_auto-detection|$wgMobileUrlTemplate]] e disabilitare l'autodetect (sarà poi possibile abilitare la cache):
$wgMobileUrlTemplate = '%h0.m.%h1.%h2';
$wgMFAutodetectMobileView = false; **Attenzione al bug [[https://bugzilla.wikimedia.org/show_bug.cgi?id=58321|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'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 ''%%
%%'' invece di avere un VirtualHost dedicato):
ServerName www.m.mydomain.org
RequestHeader set X-WAP "no"
...
**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''.
===== Attivazione cache =====
FIXME Vedere come attivare la [[http://www.mediawiki.org/wiki/Manual:File_cache|cache]] e se è compatibile con tutte le altre estensioni, soprattutto con l'autodetect del dispositivo mobile/desktop.
===== Estensione Pdf Export =====
**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 [[http://blog.blue-spice.org/2012/11/07/pdf-export-for-mediawiki/|PDF Export for MediaWiki]]. Noi abbiamo provato la [[http://www.mediawiki.org/wiki/Extension:Pdf_Export|Pdf Export]] che pare avere alcune caratteristiche buone:
* Consente di esportare facilmente un singolo articolo. Per contro la [[http://www.mediawiki.org/wiki/Extension:PdfBook|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 **[[http://www.mediawiki.org/wiki/Special:ExtensionDistributor/PdfExport|download snapshot]]**, perché in realtà quello non è compatibile con MediaWiki 1.21.3. Come si legge da questo [[http://www.mediawiki.org/wiki/Extension_talk:Pdf_Export#MWlib_issues_28541|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**.
===== Estensione PDF Writer =====
L'estensione **[[http://www.mediawiki.org/wiki/Extension:PDF_Writer|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 [[http://pediapress.com/code/|PediaPress]] che sponsorizza lo sviluppo dell'estensione fornisce un servizio demo di questo tipo.
Come prerequisito di deve installare l'estensione **[[http://www.mediawiki.org/wiki/Extension:Collection|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.
===== Login con Facebook =====
Si può utilizzare l'estensione **[[http://www.mediawiki.org/wiki/Extension:Facebook|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**.
FIXME 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;
===== 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.
===== Combattere lo SPAM e rimuovere gli utenti =====
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 **[[http://www.mediawiki.org/wiki/Extension:UserMerge|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.
===== 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 [[http://www.mediawiki.org/wiki/Extension%3aConfirmAccount|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 **[[http://www.mediawiki.org/wiki/Extension:ParserFunctions|ParserFunctions]]** e aggiungere la possibilità di caricare file .PDF:
require_once("$IP/extensions/ParserFunctions/ParserFunctions.php");
$wgFileExtensions[] = 'pdf';
L'estensione **[[http://www.mediawiki.org/wiki/Extension:Cite|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.[E. Miller, The Sun,
(New York: Academic Press, 2005), 23-5.] The Moon, however, is not
so big.[R. Smith, "Size of the Moon", Scientific American, 46 (April
1978): 44-6.]
==Notes==
====== 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** [[http://www.postgresql.org/about/featurematrix|[1]]] in quanto direttamente integrata nel db.
Per la [[http://people.planetpostgresql.org/greg/index.php?/archives/123-MediaWiki-is-Postgres-8.3-compatible.html|compatibilità con postgres 8.3]] è necessario MediaWiki successivo alla [[http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=31083|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 **[[http://www.postgresql.org/docs/8.3/static/textsearch-migration.html|12.12. Migration from Pre-8.3 Text Search]]** e **[[http://www.postgresql.org/docs/8.3/static/tsearch2.html|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 [[http://meta.wikimedia.org/wiki/Help:Link|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 **[[http://meta.wikimedia.org/wiki/Help:Link#Subpage_feature|sottopagine]]**. Le sottopagine in genere sono attive solo per le [[http://meta.wikimedia.org/wiki/User_page|pagine utente]], per le [[http://meta.wikimedia.org/wiki/Talk_page|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 [[http://www.mediawiki.org/wiki/ParserFunctions|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 [[http://www.mediawiki.org/wiki/Extension:ConfirmEdit|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 **[[http://www.google.com/recaptcha/learnmore|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 [[http://www.mediawiki.org/wiki/Manual:Pywikibot/Quick_Start_Guide|Quick Start Guide]], c'è ovviamente bisogno dell'interprete Python. Si scarica la versione **core** usando il comando **''git clone''** (accedere al repository da [[http://sourceforge.net/projects/pywikipediabot/|Sourceforge]]) oppure si scarica l'archivio dal repository [[http://tools.wmflabs.org/pywikibot/|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'', le ''extensions'', 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 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 **[[https://bugzilla.wikimedia.org/show_bug.cgi?id=15281|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|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 **''[[http://www.postgresql.org/docs/8.3/static/sql-createlanguage.html|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 **[[https://bugzilla.wikimedia.org/show_bug.cgi?id=15854|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.
===== Link web =====
* [[http://people.planetpostgresql.org/greg/index.php?/archives/123-MediaWiki-is-Postgres-8.3-compatible.html|MediaWiki is Postgres 8.3 compatible]]
* [[http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=31083|MediaWiki revision 31083]]
* [[http://blog.gugl.org/archives/24|Upgrading PostgreSQL 8.2 to 8.3 (mediawiki)]]
* [[http://julien.danjou.info/blog/index.php/post/2008/05/19/Upgrading-mediawiki-from-PostgreSQL-82-to-83|Upgrading MediaWiki from PostgreSQL 8.2 to 8.3]]
* [[http://www.mediawiki.org/wiki/Manual:Upgrading_Postgres|MediaWiki: Upgrading Postgres]]
* [[http://www.postgresql.org/about/featurematrix|PostgreSQL Feature Matrix]]
* [[http://www.postgresql.org/docs/8.3/static/tsearch2.html|Tsearch2 compatibility layer for Postgres 8.3]]
* [[http://people.planetpostgresql.org/greg/index.php?/archives/136-Upgrading-to-8.3-MediaWiki-lessons-learned.html|Upgrading to 8.3 - MediaWiki lessons learned]]