Da Pelican a Nikola

Stefano Marinelli — Wed, 09 Sep 2015 09:18:41 GMT

Dopo tutto il bene che ho detto di Pelican, credo che qualcuno rimarrà sorpreso nel leggere un articolo del genere, così come sarà rimasto sorpreso chi ha visto cambiare motore del Blog, di nuovo e dopo pochi giorni. La domanda che potrebbe sorgere spontanea è: perché?

La mia risposta: perché si può, perché si vuole, perché si deve provare tutto. E, visti i risultati, ho deciso di tenere Nikola come motore di generazione del blog.

La scelta di Nikola come compilatore (mi piace pensarlo così) è dettata non da problemi con Pelican, ma da alcuni vantaggi che Nikola stesso mi ha mostrato.

Farò dunque un rapido e non esaustivo elenco delle ragioni che mi hanno spinto a usare Nikola:

Entrambi sono in Python - pari
Entrambi installabili via pip in un virtualenv - pari, anche se Pelican ha molte meno dipendenze
Pelican ricalcola ogni volta tutto, ricreando tutti i file. Ci sono delle opzioni di caching, ma non mi hanno dato risultati entusiasmanti. Nikola, al contrario, ricostruisce solo ciò che è stato modificato e le relative dipendenze, in maniera molto rapida. Essendo un generatore statico, anche se c'è da aspettare un minuto in più quella volta che viene fatta una modifica non è che sia la fine del mondo, ma le ottimizzazioni ci stanno sempre bene - Nikola
Pelican genera solo i file .html. Per sitemap e le versioni in gzip degli articoli (utile per minimizzare i tempi di trasferimento), c'è da installare qualche plugin. Non che sia un problema, ma è bello trovare tutto pronto e coerente. Inoltre è potenzialmente meno pericoloso in fase di aggiornamento. - Nikola
Nikola supporta Pandoc e moltissimi formati di input. Io utilizzo, al momento, il Markdown, ma non escludo di imparare altro. - Nikola
L'importazione da WordPress è più completa. Per importare da Pelican, infatti, ho utilizzato il dump che avevo effettuato e reinserito i nuovi articoli. Pur interpretando entrambi il Markdown, hanno un formato leggermente diverso. Mi è piaciuto il fatto che è andato a pescarsi le immagini dal sito originale e se le è copiate internamente. Ho dovuto comunque provvedere a fare alcune modifiche. - Nikola
Nikola supporta internamente le redirezioni, per cui mi ha creato autonomamente una mappa dal vecchio formato WordPress al nuovo. Gli articoli sono dunque automaticamente ancora raggiungibili senza fare alcuna modifica nel file .htaccess - Nikola
Supporta nativamente i pretty urls, ovvero la rimozione del .html dall'URL stesso. In teoria, a livello SEO, non dovrebbe fare alcuna differenza, e su Pelican è fattibile tramite .htaccess, ma è bello trovare tutto fatto in automatismo. In pratica, Nikola crea delle directory col nome (slug) dell'articolo e ci infila dentro un index.html. I browser, quindi, caricheranno automaticamente l'index quando verrà richiesta la directory. - Nikola
Sembra produrre, di base, un sito più SEO-friendly. - Nikola
La simpatia dello sviluppatore. Sarà per la sua radice latina, si ha sempre la percezione di leggere qualcosa scritta da una persona solare e simpatica. - Nikola

Ho dunque deciso di mettere online il sito prodotto da Nikola, addirittura col tema grafico di base (non mi dispiace).

Se continuerei a consigliare Pelican? Decisamente sì, non vedo ragioni per cui non debba essere utilizzato. Suggerisco quindi di provarli entrambi.

Da WordPress a Pelican

Stefano Marinelli — Tue, 01 Sep 2015 20:45:00 GMT

Premessa

Ebbene sì, torno a scrivere sul blog dopo molto tempo. Ci sono vari articoli iniziati e mai terminati, non ho più il tempo che avevo una volta di aggiornare molto spesso. Cercherò di rimediare. Non sono mai stato esageratamente costante nel seguire i siti, per cui chi mi conosce non resterà certamente meravigliato.

Sin dal lontano 2006 (più di nove anni fa...), ho iniziato ad usare Wordpress per il mio blog e, di conseguenza, per altri siti. Dopo una breve parentesi di Joomla, prevalentemente utilizzato per alcuni siti realizzati per dei clienti (non questo blog), sono tornato a Wordpress proprio perché la sua aggiornabilità e la sua espandibilità mi avevano sempre soddisfatto. Il blog è rimasto su Wordpress, appunto, per più di nove anni.

Fino a quando...

non è arrivata la Cookie Law (ne parlerò in uno dei prossimi articoli). Ho dovuto, rapidamente, fare una scansione di tutti i miei CMS per capire cosa andava disattivato e cosa sarebbe potuto restare. Ho scoperto - si fa per dire - che buona parte dei miei amati plugin di Wordpress avrebbero avuto bisogno di una bella informativa. Non ne ho mai installati troppi, ma quei pochi erano già sufficienti a causare potenziali problemi.

Ho disattivato ciò che ho potuto, mantenendo tutti i contenuti, le cache, ecc. mentre ho disattivato tutti i vari pulsanti sociali (davano dei numeri, quindi contattavano i social network in oggetto per avere le informazioni), il Jetpack con relative statistiche, e altre piccole cose meno importanti.

A quel punto mi sono posto una domanda: ma ho davvero bisogno di un CMS completo, mastodontico, con tanto di database MySQL, per gestire un blog e qualche commento?. Premesso che non ho interesse a mandare pubblicità, tantomeno a tracciare i visitatori, che alcuni dei miei plugin preferiti sono stati resi (quasi) inutilizzabili dalla legge di cui sopra, perché devo far eseguire un plugin che faccia cache html degli elaborati PHP quando basterebbero, effettivamente, dei buoni HTML? Non da trascurare, inoltre, che quasi ogni giorno escono patch di sicurezza di WordPress (o di suoi plugin), spesso vengono fuori vulnerabilità di PHP (che non ho mai amato, per me è la maggior fortuna e allo stesso tempo rovina del Web), e che MySQL è comunque "sprecato" per contenere qualche centinaio di articoli testuali.

La risposta che mi sono dato è stata: e poi, come li gestisci tutti quegli HTML statici?. Ho fatto una rapida ricerca e ho scoperto un mondo a me allora ignoto: quello dei generatori di siti statici.

Generatori di siti statici

I generatori di siti statici...generano siti statici! :-)

Scherzi a parte, sono degli strumenti che si occupano di prendere dei file di testo (o anche in Markdown, html puro, ecc.), elaborarli, inserire il tema, creare gli indici, ecc. Insomma, fanno tutto ciò che farebbe un CMS, ma lo fanno una volta e generano dei normalissimi HTML statici. Leggeri, pratici, portabili. Nessuna necessità di database, nessun bisogno di alcuno strumento sul server in cui il sito verrà pubblicato, il risultato dell'elaborazione di questi generatori sarà una directory popolata di file html, pronta per essere caricata in qualunque server, anche embedded (i primi test li ho fatti su Raspberry PI. Si possono generare i file sul proprio computer e caricare la directory contenente i file html, onde non dover tenere nulla sul server. I siti così generati possono essere messi in hosting praticamente ovunque, compresi github, Amazon S3, ecc.

Ho iniziato a guardarmi intorno. Ce ne sono moltissimi, molti sono dei fork del "capostipite" Jekyll, che ho provato e ritenuto ottimo. Ho però, già da qualche anno, un interesse verso il Python, di conseguenza mi sono orientato verso una risorsa scritta in questo linguaggio. Pelican è stata la mia scelta, e dopo qualche giorno di studio, sono riuscito ad iniziare a creare qualcosa di decente. Veloce, pulito, semplice. Non avrei potuto chiedere di meglio. L'alternativa, meno versatile e decisamente più limitata, sarebbe stata BashBlog, che non ha dipendenze a parte bash, appunto.

Importazione di un sito WordPress su Pelican

Fortunatamente, Pelican comprende anche un programma che si occupa di importare (quasi) del tutto autonomamente i precedenti contenuti di WordPress. Ho effettuato una esportazione e una importazione, con il risultato che buona parte degli articoli sono andati correttamente al loro posto e ben collegati. Categorie e tag compresi.

Ho però avuto due problemi, non banali:

* L'importazione dei commenti
* La conversione di due generazioni di URL verso una terza, nuova generazione

L'importazione dei comenti

Per quanto concerne il primo punto, avevo tre scelte. Buttare via i vecchi commenti, importarli in Disqus oppure provare ad importare e implementare in ISSO.

Le prime due opzioni avrebbero permesso l'approccio senza alcun componente dinamico, mantenendo l'idea di avere un server completamente statico. Però mi sarebbe dispiaciuto perdere i vecchi commenti, c'è della roba carina e ormai storicamente interessante, vista l'epoca in cui sono stati scritti. L'approccio esterno non mi entusiasmava. Non mi piace dipendere da aziende che potrebbero cessare il servizio, renderli a pagamento, cambiare le condizioni. Ho dunque deciso di gestire la cosa con ISSO, anche se ho dovuto fare qualche manovra per far riconoscere i vecchi commenti con i nuovi URL. Nessun problema, il database interno è Sqlite3, per cui è stato un gioco da ragazzi.

La conversione degli URL

Più complessa e meno banale è stata l'operazione di conversione degli URL. Il blog è spesso finito su siti di informazione generalista, su link di altri blog, su forum, tanto che vedo ancor oggi arrivare collegamenti da risorse che non sapevo neanche che ci fossero, considerata anche l'età media di molti di questi articoli.

I generatori statici creano file .html, quindi l'url sarà:

http://www.dragas.net/articolo.html

I miei articoli precedenti, invece, avevano una struttura di questo tipo, tra l'altro indicizzata da Google:

http://www.dragas.net/articolo/

I problema, appunto, è che i vecchi link arrivavano con i vecchissimi URL:

http://www.dragas.net/?p=11

e il caro WordPress, tramite un plugin, era in grado di redirezionare verso i permalink corretti. Ho dovuto quindi lavorare di .htaccess (il server su cui è al momento ospitato il Blog gira su Apache) e creare una serie di redirezioni manuali, sia per togliere lo slash finale e aggiungere .html, sia per fare un reindirizzamento corretto con i "?p=".

Il risultato finale sembra essere, almeno al momento, positivo. Il Blog è quasi completamente raggiungibile coi vecchi URL, i commenti sono al loro posto e correttamente legati ai singoli articoli, probabilmente è cosmeticamente meno affascinante (pur non avendo mai stupito con effetti speciali), ma decisamente più prestante e non devo più preoccuparmi degli aggiornamenti di sicurezza di Wordpress (che comunque avvenivano automaticamente) o di plugin non mantenuti o mal programmati che potrebbero diventare dei punti d'accesso discretamente pericolosi.

Considerazioni Finali

Dopo 9 anni di WordPress, posso ritenermi decisamente soddisfatto: personalmente non ho mai avuto un problema, mai un server bucato per colpa di WordPress (a differenza di Joomla, Magento, ecc.), ma non mi dispiace l'idea di avere un sito statico. Mi piace scrivere in Markdown, il fatto di non aver necessità di un Database, facilità di backup anche dei commenti, leggerezza generale dell'infrastruttura. Continuerò a suggerire WordPress a chi non è in grado di gestire una infrastruttura come quella di Pelican (semplicissima, ma di certo un attimo più complessa del classico editor WYSIWYG stile TinyMCE) o a chi ha esigenze particolari, diverse dalla semplice scrittura di un normale blog (es: autori multipli, ecc).

Finalmente posso tornare a concentrarmi sul testo e non sulla piattaforma. Tra ricerca di plugin, aggiornamenti, migrazioni, predisposizione di backup del database, cambiamento di temi, ecc, probabilmente ho speso molto più tempo sulla piattaforma che sulla scrittura di articoli. Ora, invece, posso usare il mio adorato vim, ovunque io sia, senza particolari problemi. La mia filosofia Informatica è sempre stata fedele alla teoria del rasoio di Occam: la soluzione più semplice, se sufficiente, è sempre la migliore.

Stefano Marinelli's Blog (Articoli su pelican)