Vincere lo spam

Naturalmente non mi aspettavo che WikiTrek fosse esente da spam. Fin dal primo momento ero ragionevolmente certo che, più prima che poi, il sito avrebbe ricevuto della immondizia da parte di qualche farabutto.

In effetti, fin dalle prime settimane di esistenza del sito, ogni qualche giorno mi capitava di vedere comparire un utente evidentemente fasullo con il suo bel bagaglio di paginette piene di testo poco sensato e link fraudolenti.

Da bravo admin, bloccavo gli utenti, cancellavo le pagine e tornavo a lavorare sul serio.
Poi un bel giorno scopro che la situazione peggiora drasticamente: colpevole forse il miglioramento di WikiTrek nelle statistiche dei siti wiki, in poche ore erano stati creati decine di account fasulli, ognuno portando con sé due o tre pagine piene di spam.

Come ho già scritto, avevamo perso la prima battaglia e bisognava attrezzarsi per vincere la guerra.
Adesso fa meno paura scriverlo, ma in quei giorni pensavo seriamente che la wiki avrebbe potuto cedere sotto il peso dello spam e che il contenuto sensato del sito sarebbe andato in minoranza in pochi giorni.

Sulla mia pelle avevo imparato di aver sottovalutato il problema e di non essermi documentato a sufficienza in anticipo. Correvo quindi ai ripari con colpevole ritardo.
A memoria di quanto fatto e nella sperazna di aiutare qualche altro novello amministratore di un sito MediaWiki, qui di seguito riassumo brevemente il bagaglio di strumenti che bisognerebbe mettere in campo fin da subito.

Il lettore interessato è caldamente invitato a leggere la documentazione linkata prima di mettere in atto le contromisure, perché potrebbero risultare dannose anche per gli utenti leciti.

  • ConfirmEdit
    impedisce agli spambot di effettuare modifiche fraudolente e aggiungere link a siti usando teniche CAPTCHA.
    Riduce purtroppo l’accessibilità, ma con l’impostazione No CAPTCHA reCAPTCHA consente di raggiungere un buon bilanciamento fra semplicità d’uso ed efficacia contro gli attacchi.
  • SpamBlacklist
    nega la possibilità di fare modifiche a utenti che fanno parte di una blacklist. Per questa estensione esistono già grandi blacklist pronte all’uso in quanto utilizzate anche dalla Wikipedia
  • StopForumSpam
    Fa sì che lìinstallazione di Mediawiki possa contribuire al dataabase di stopforumspam.com

Aggiungo inoltre, per chi è già stato tempestato di spam, l’utile estensione Nuke che permette una comoda cancellazione massiva delle pagine, anche se purtroppo ha il grande difetto di non permettere una selezione granulare, oltre a non aiutare a bloccare gli utenti dannosi.

Due licenze sono peggio di una

Questo articolo è work in progress e soggetto ad aggiornamento al progredire della discussione nella mailing list del progetto

Free e open source sono parole ormai diventate ubique nel mondo dell’IT. Parlare ormai di informazione libera è un argomento di discussione comune.
Come spesso accade le cose non sono semplici come potrebbero sembrare.

Prima di tutto una premessa: HyperTrek e tutti i suoi predecessori sono sempre state piattaforme studiate por essere prima di tutto a disposizione di tutti e poi anche collaborative.

HyperTrek rilascia i propri testi con la licenza GNU Free Documentation License .
WikiTrek rilascia i testi originali tramite licenza Creative Commons Attribution-ShareAlike 4.0.
Le ragioni per preferire la CC SA-BY rispetto alla GFDL sono squisitamente pratiche (la prima è una Free Cultural License a tutti gli effetti) e si possono leggere, tra gli altri luoghi,  sul sito di Creative Commons e in questo essay su Wikipedia in questo essay su Wikipedia.

Le licenze vengono mostrate visualmente con due icone (estendere il post discutendo di https://www.mediawiki.org/wiki/Manual:$wgFooterIcons) visualizzate qui sotto

Capture.PNG

con relativo link che punta a https://www.lucamauri.net/wikitrek/index.php?title=WikiTrek:Informazioni.

Gettiamo la “anchor”

I cosiddetti anchors sono link che indirizzano a parti diverse di una singola pagina, non a una pagina diversa.
Facciamo un esmpio pratico partendo dalla pagina di analisi dei teaser di TNG su HyperTrek: https://hypertrek.info/index.php/tngteaser
Prendiamo il link

1
<a href="/index.php/terminologia#teaser" target="_top">teaser</a>

Questo punta alla pagina Terminologia direttamente alla posizione identificata da

1
<a name="teaser"></a>Parte

Come vedete la proprietà href punta all’ancora con il simbolo # mentre la definizione è fatta nel tag  tramite la proprietà name.

Purtroppo questo metodo non può essere usato in MediaWiki, come spiegato dettagliatamente qui.
Lo stesso meccanismo però può essere applicato tramite la proprietà id che può essere applicata a una grande varietà di tag. In questo caso particolare, usiamo un tag inline, ovvero l’utilissimo .

Ecco quindi che alla pagina https://wikitrek.org/index.php/Teaser troviamo un link molto simile a quello originale di HT

1
<a title="Terminologia" href="/index.php/Terminologia#teaser">teaser</a>

Mentre la ancora nella pagina di destinazione è molto diversa:

1
<span id="teaser">Parte</span>

Ma il risultato è il medesimo.

Sotto il cofano questa modifica è effettuata usando una combinazione di regular expressions insieme allo HTML Agility Pack.

Astronavi regolari

Nella migrazione delle schede delle Astronavi da HyperTrek una delle sfide è stata esportare la maggior parte delle informazioni da poter categorizzare in forma breve nel relativo infobox.

Molti dei dati possono essere estratti dalle sezioni come potete vedere dallo screenshot qui sotto

sezioniastro.PNG

altre invece devono essere estratte in qualche modo dai dati esistenti.

Oggi mi sono dedicato a uno di queste estrazioni perchè volevo poter categorizzare la nave per il suo tiponumero di registro: nell’esempio della USS Odyssey qui sopra, volevo essere in grado di determinare che il suo registro di flotta fosse lo NCC (il registro standard delle navi di serie della Flotta Stellare) e che il relativo numero di registro fosse 71832.

Per estrarre queste informazioni ho usato le regular expression – già trattate in altra sede – per risparmiare codice e tempo nella scrittura.

Il pattern sottostante la RegEx è il seguente:

1
/(ncc|nx)\D?(\d*) /gi

la cui spiegazione è semplice:

  • (ncc|nx)
    trova il gruppo di testo che inizia per NCC o NX
  • \D?
    trova un singolo carattere non numerico, di conseguenza identifica un eventuale spazio o trattino che separi la sigla dal numero
  • (\d*)
    trova una stringa di cifre di lunghezza arbitraria
  • /gi
    il modificatore Global restituisce tutti i matches senza fermarsi al primo
    il modificatore Insensitive ignora maiuscole e minuscole

Con poche righe di codice questa regex permette di estrarre le sigle NX o NCC e il relativo numero per l’inserimento nell’InfoBox:

sezioniastrowiki.PNG

Un esempio funzionante è disponibile su RegEx101 all’indirizzo https://regex101.com/r/2omAw3

Elenchi puntati in WordPress

Il tema di WordPress standard TwentySeventeen è molto semplice e facilmente leggibile.
L’ho scelto per questo blog in attesa di qualcosa di meglio, se e quando verrà in futuro.

Una cosa però con non mi piace di questo tema è che i punti degli elenchi vengono visualizzati al di fuori del blocco di testo.
Non mi piace questa caratteristica perché a mio avviso rende meno leggibile gli elenchi puntati che invece dovrebbero semplificare il flusso del testo.

Una soluzione facile a questo problema è aggiungere un piccolo frammento di codice nel CSS personalizzato

1
2
3
.entry-content li {
    list-style-position: inside;
}

Questo allinea il punto al blocco di testo e indenta il contenuto.

Tuttavia si presenta un secondo problema: dalla seconda riga di testo in poi, in ogni punto, il testo è allineato al punto non alla prima riga.
Di nuovo, rende meno leggibile il testo ed è anche brutto a vedersi.
La soluzione definitiva è riportare tutti punti all’esterno, in modo che tutte le righe del testo di ogni singolo punto siano allineate, e poi spostare l’intero elenco puntato a destra.

1
2
3
4
5
.entry-content li {
    list-style-position: outside;
    padding-left: 10px;
    margin-left:20px;
}

Immagini, ci siamo

Dopo mesi a spaccarmi la testa e infinite discussioni con il creatore della libreria che JARVIS usa per manipolare la Wiki, ho trovato il problema che impediva il caricamento delle immagini.

Inutile dire che era di una stupidità estrema e che si risolveva meno di 5 secondi, capendo dove bisognava guardare.

Ad ogni modo, negli scorsi giorni ho importato tutte le immagini da HT e ci ho giocato un po’.
Come prima cosa le ho importate brutalmente lasciando fare tutto alla wiki. Il risultato era funzionale, ma molte informazioni andavano perse. Sono quindi passato a scrivere dinamicamente anche la pagina che MediaWiki mostra quando si accede all’immagine.

Vedete per esempio sul sito di test il file File:Specie!vulcan-deserto.jpg
Qualche annotazione:

  • ignorate il fatto che ci siano molte versioni identiche della stessa immagine.
    Deriva dal fatto che ho fatto prove su prove senza curarmi di cancellare perché in questa fase non ha senso.
    Sul sito definitivo ovviamente questo non accadrà.
  • Il nome dell’immagine in WikiTrek è generata concatenando in nome della sottocartella di HT con il nome dell’immagine, sostituendo la barra dritta con un punto esclamativo.
    Nella sezione “Dettagli” ci sono indicati il nome nuovo e quello vecchio.
  • La parte di Licenza è ancora tutta da scrivere.
    Demanderei la cosa a un template, ma vorrei sentire i vostri suggerimenti.
  • La sezione HyperTrek riporta la data di scaricamento e lo URI originale.
    Poi in due sottocapitoli ho copiato la Descrizione e lo ImageTag.
  • Le immagini non sono visibili in tutte le relative pagine perché devo rielaborarle, potete vedere qualche esempio, sempre sul sito di test, nelle pagine T’Pol e The Naked Now.

Playing Side

La Sidebar di un sito basato su MediaWiki è un luogo interessante dove aggiungere informazioni importanti.
Nel mio caso, l’idea era di aggiungere qualche link a risorse esterne relative a Wikitrek ma che non fossero incorporate nella wiki vera e propria.
Mi sembrava quindi una buona idea aggiungere una sezione apposita nella sidebar.

Una breve ricerca su internet mi ha portato alla pagina dove trovare tutte le informazioni per personalizzarla.
È bastato quindi aggiungere poche righe di testo a https://wikitrek.org/index.php/MediaWiki:Sidebar per ottenere il risultato voluto. In particolare, si tratta di aggiungere elementi a un elenco puntato facendo precedere il sito al nome:

1
2
3
4
5
* Link Esterni
** https://blog.wikitrek.org | Blog di WikiTrek
** https://wikitrek.slack.com | Gruppo di collaborazione WikiTrek su Slack
** https://www.facebook.com/wikitrek | Pagina Facebook
** https://twitter.com/wikitrekorg | Account Twitter

Il risultato era pratico, ma a mio avviso poco gradevole esteticamente.
Mi sarebbe piaciuto per esempio aggiungere le icone dei relativi siti a sinistra del collegamento, non solo per rendere la barra più bella ma anche per facilitare la navigazione potendo identificare la destinazione del link con un colpo d’occhio.

Qualche tentativo di inserire le immagini direttamente nel testo della pagina ha dato esito negativo. Ho pensato quindi di effettuare una modifica nel CSS per ottenere il risultato.
Di nuovo, una breve ricerca in internet mi ha indicato la strada: per ogni elemento della Sidebar, il motore di MediaWiki genera un ID univoco basato sul testo della etichetta, quindi è stato facile effettuare una modifica come questa:

1
2
3
4
5
6
7
8
9
li#n-Account-Twitter {
background-image: url(//abs.twimg.com/favicons/favicon.ico);
background-size: 16px;
background-position: top left; background-repeat: no-repeat;
}

li#n-Account-Twitter a {
padding-left: 20px;
}

Per ottenere un risultato non solo funzionale, ma anche più bello da vedere.

esterni

Giochiamo con gli UL

Da pochi giorni, i campi e i valori relativi agli episodi sono tutti inseriti in parametri singoli del Template:BoxEpisodio : questo è semanticamente più corretto rispetto alla versione originale dove tutto era elencato in elenchi puntati.

MediaWiki però non ammette campi multipli nello stesso template, di conseguenza si verificava un problema nel caso, per esempio, di due sceneggiatori nello stesso episodio.
La soluzione è stata usare un elenco puntato all’interno dello stesso campo: in questa maniera con un campo solo è possibile visualizzare più di un dato in maniera strutturata.

L’estetica però lasciva a desiderare, guardate questo esempio tratto da Shadows of P’Jem

Avendo però usato un UL è stato possibile facilmente creare una presentazione più gradevole tramite CSS.
Ecco come abbiamo fatto.

Per prima cosa tutto il Template:BoxEpisodio è stato racchiuso in un div con uno specifico ID, dopodiché tutti i campi sono stati inseriti in un ulteriore DIV con una classe specifica.
Il relativo CSS è stato modificato così:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
.campi ul {
list-style-type: none;
margin: 0;
padding: 0;
display: inline;
}

.campi li{
display: inline;
}

.campi li + li:before {
content: " · ";
font-weight: bold;
}

Le proprietà list-style-type: none; e display: inline; fanno sì che le voci dell’elenco siano tutte sulla stessa riga e senza segno grafico.
Invece content: " · "; aggiunge un punto di separazione tra le voci dell’elenco.
Il risultato è un più gradevole

Aggiunta estensione CodeColorer

Questo blog permette ora la formattazione del codice usando l’estensione CodeColorer.

Per inserire un codice, usare la sintassi

[cc lang="linguaggio"]
codice
[/cc]

Per il codice inline usare invece

[cci lang="linguaggio"]codice[/cci]

La pagina principale del progetto è qui https://wordpress.org/plugins/codecolorer mentre i dettagli e gli esempio di uso sono visibili alla pagina https://kpumuk.info/projects/wordpress-plugins/codecolorer/