Stefano Marinelli's Blog (Articoli su cms)

Odio PHP. Punto.

Stefano Marinelli — Thu, 24 Sep 2015 21:18:14 GMT

Lo ammetto: non ho mai amato PHP. Anche recentemente ho spiegato perché ho preferito rendere il blog statico, evitando ulteriori "complicazioni" proprio col PHP. È sui server, funziona, ma se posso evito. L'ho utilizzato in molte occasioni, lo utilizzo in molte occasioni, scrivo anche qualcosina in questo linguaggio che, però, continua a restarmi sullo stomaco.

La ragione è semplice: secondo me è pericoloso per natura. Tra mille sforzi e con impegno, stanno tentando di renderlo migliore ma gli effetti, per ora, non sono eccelsi come si vorrebbe. Il problema è che PHP è nato come un piccolo linguaggio per fare piccole cose. Si è poi espanso in quanto semplice da impiegare (basta un web server con un interprete), meno semplice da apprendere come si deve, e induce, per natura, ad errori madornali di programmazione in quanto consente (o, a volte, richiede) di fare delle cose in un modo formalmente non propriamente corretto.

PHP ha permesso a molte persone di mettersi a fare programmazione web, pur non avendone le basi. E non le ha guidate verso una giusta direzione (le persone, pur senza basi, possono imparare e diventare brave) ma spinge a fare le cose in un modo insicuro. Il programmatore, a volte, deve risolvere dei problemi legati alle carenze del linguaggio stesso.

Alla gente PHP è piaciuto. Un commento su PHP che ho letto di recente diceva una cosa del tipo "people like php because php is cheap, and people like cheap things". Ecco, il punto è proprio questo: PHP è a buon mercato, non inteso come prezzo d'acquisto ma come prezzo da pagare per impararlo e utilizzarlo. Non è come il C, o come il Java. Purtroppo, allo stesso tempo, non è pulito come il Perl o il mio amato Python (recente passione). PHP fornisce tutti gli strumenti per fare qualunque cosa. Il problema è come questa cosa verrà realizzata.

È nato come un linguaggio per non-programmatori. Ricordiamolo. Ed è stato evoluto aggiungendo roba senza curarsi di rendere il tutto coerente con quello che c'era prima. Sembra quasi una corsa, e ora la rincorsa è a risolvere i problemi che, da sempre, lo affliggono.

Ovviamente c'è chi lo conosce bene, chi lo riesce a domare sul serio. In mano a queste persone, PHP è ottimo tanto quanto i più blasonati linguaggi di programmazione. Lavoro quotidianamente con degli ottimi sviluppatori PHP, e vedo quanta fatica fanno a tenere in piedi il tutto. Li ammiro, a me salterebbero i nervi molto prima di aprire l'editor di testo. Aggiungiamo, inoltre, che il guaio è che il 90% degli sviluppatori in questo linguaggio non sono particolarmente esperti né di PHP, né di programmazione, tantomeno di sicurezza informatica. Col risultato che quasi tutte le newsletter di sicurezza che mi arrivano quotidianamente parlano di PHP stesso o di software in PHP.

Parlandone in giro, mi sento rispondere che è normale che sia così in quanto è il più diffuso, quindi necessariamente il più bersagliato. In parte ciò è vero (nessuno noterebbe un bug di sicurezza di un linguaggio usato da piccole percentuali di sviluppatori), ma osservando attentamente la documentazione stessa di PHP si percepisce immediatamente l'idiosincrasia tra la buona programmazione e la programmazione "stile PHP".

Ho anche letto, recentemente, un interessante (e ormai famoso) articolo sui problemi di PHP. Ne consiglio la lettura, pur essendo un articolo molto lungo. A mio avviso spiega bene le cose.

Insomma, PHP c'è e ci sarà a lungo, ma a me è antipatico. Ci lavoro, ci lavorerò, lo userò quando necessario ma no, non mi piace e non credo potrà mai piacermi.

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.

Il SEO, questo sconosciuto. O forse no?

Stefano Marinelli — Tue, 17 Dec 2013 05:30:27 GMT

Negli ultimi anni si è potuto assistere alla nascita di una nuova figura professionale, ovvero il Consulente SEO. Professionisti e aziende si sono lanciati in questo interessante e utile settore, con la promessa di migliorare la posizione nei motori di ricerca grazie ad una approfondita analisi e a delle modifiche specifiche da applicare.

I motori di ricerca, infatti, utilizzano degli algoritmi decisionali molto complessi (e mai del tutto pubblicati). Alcune informazioni vengono fornite, altre no. In tutti i casi, i criteri principali sono: vengono premiati i siti rapidi, ben raggiungibili, che non abbiano castronerie formali nelle loro pagine (più nella parte "invisibile" all'utente normale che in quella visibile, ovviamente), che non cerchino di fare i furbetti taroccando le parole chiave o tentando la scalata in maniera poco pulita.

Ci sono poi mille sfaccettature e sfumature che sono più complesse, e qui ci vuole qualcuno che abbia una certa esperienza. O forse no? Dipende.

Nella mia carriera ho avuto a che fare con ogni tipo di figura professionale. Sistemisti, programmatori, grafici, consulenti SEO, consulenti a progetto che di fatto l'unica consulenza che fanno è decidere quali consulenti o aziende siano più adatte a fare determinati lavori (sì, avete letto bene: specialmente negli enti pubblici ci sono alcuni CONSULENTI INFORMATICI pagati per decidere a chi affidare le CONSULENZE INFORMATICHE nei vari settori. E quante arie si danno!). Alcuni competenti, altri meno, alcuni davvero da far saltare i nervi.

Nella media, posso dire che ho avuto buone e cattive esperienze con tutte queste figure, ma con un paio di consulenti SEO ho davvero faticato a mantenere calma e professionalità. Sia chiaro: ho lavorato con aziende e consulenti SEO di ottimo livello e di altissima professionalità, e non sto minimamente denigrando il settore. Ma il mondo è bello perché è vario. O avariato.

Le persone specifiche che mi hanno tanto irritato si presentano, di solito, senza un particolare o specifico titolo di studio o attestato. Sia chiaro, ho lavorato con bravissimi Diplomati in altre materie e pessimi Ingegneri o laureati in Informatica, quindi non è che la Laurea faccia sempre la differenza, però in questo caso manca spesso qualunque competenza informatica. La loro formazione è avvenuta attraverso blog o forum (o eventi sponsorizzati dai motori di ricerca, dietro lauto pagamento), e senza avere alcuna capacità o esperienza sistemistica. Eppure giudicano. Decidono che una certa scelta tecnica sia sbagliata, criticano le tue configurazioni, non comprendono il perché si è scelta una specifica piattaforma di virtualizzazione rispetto ad un'altra o uno specifico sistema operativo. Mediamente, proprio questo tipo di figure si pongono con aggressività (che di solito direttamente proporzionale all'incompetenza: solo chi sa di non sapere si mette in discussione, chi crede di essere onnisciente non accetta interferenze) e cercano di screditare tutti gli altri per darsi importanza.

Un vero professionista sa che le parole vendono, ma poi contano i fatti. E in questi casi, spesso, ho visto che il business è addossare la colpa a qualcun altro (sviluppatore, sistemista, utente) per giustificare determinate lacune o carenze oppure, ancora peggio, per dare al cliente l'impressione che la consulenza in oggetto sia stata utilissima, perché ha "dimostrato" le falle dell'intero processo gestionale.

Consulente SEO sconosciuto ai motori di ricerca...affidabile??

Poi magari fai una ricerca e scopri che il sito del tipo in oggetto (e/o la sua azienda) compaiono nella TERZA pagina dei motori di ricerca, pur non chiamandosi "Mario Rossi", perché prima ci sono altri risultati assolutamente non legati a lui/loro. Spesso utenti di forum di videogame o cose di questo genere. La domanda che ci si pone, dunque, è questa: se un Consulente (o una azienda) basa il suo business sul posizionamento nei motori di ricerca, come mai il motore di ricerca lo mette in una posizione bassa?

In alcuni casi, davvero non c'è soluzione. Il SEO non è una scienza esatta, e questo qualunque buon consulente SEO dovrebbe dirlo al primo contatto. I motori di ricerca, spesso, premiano la semplicità: più tenti di scavalcare, più ti fanno fuori.

In altri casi, però, c'è qualcosa che non va. Ovvero si è pieni di parole e di concetti teorici, ma di poca pratica sul campo. È come andare a comprare il vino da un grande intenditore, ma che produce un nettare pessimo. Sarà anche un intenditore, ma il suo prodotto non è sufficientemente qualitativo.

C'è dunque davvero bisogno di assumere un Consulente SEO? Secondo la mia opinione, dipende. Se si è realizzato un sito molto personalizzato, magari senza utilizzare CMS specifici o con un buon rispetto nei confronti dei motori di ricerca, indubbiamente l'assuzione di un buon consulente SEO può migliorare drasticamente il posizionamento.

In molti altri casi, invece, l'utilizzo di un CMS adeguato e magari l'aggiunta di qualche specifico plugin può fare miracoli. Tanto per dovere di cronaca, cito la mia ultima esperienza. Ho installato, per conto di un cliente, un CMS Wordpress, usando temi gratuitamente disponibili e qualche plugin di caching e SEO. Il dominio in oggetto è stato registrato ex novo ed è una frase abbastanza comune, il sito è partito da zero e non c'è stata alcuna pubblicizzazione (solo l'invio del sitemap ai vari motori di ricerca, peraltro operazione fatta automaticamente dal plugin SEO). Risultato: in una settimana, cercando la perifrasi o qualche parola chiave assimilabile, il sito è nella prima pagina di Google e nella seconda di Yahoo.

Non sono un consulente SEO, non ho seguito corsi, non ho studiato nello specifico ma sono riuscito ad ottenere lo scopo.

Just my 2 cents.

CMS: da Wordpress a Joomla...e ritorno!

Stefano Marinelli — Sun, 15 Dec 2013 07:00:56 GMT

La scelta di un CMS dovrebbe essere oculata, basata sulle proprie necessità e sulle proprie competenze. Nel corso degli anni, ho avuto modo di valutare molti sistemi e trarre alcune conclusioni. Quelle che seguono, dunque, sono le mie valutazioni personali.

Utilizzo con piacere Wordpress sin dal 2006, e ho sempre apprezzato la semplicità, la facilità con cui applicare gli aggiornamenti e il fatto che non si è mai comportato in maniera sbagliata, neanche aggiornando (come questo blog) per anni e anni, e senza interventi manuali particolari.

Alcuni anni fa, allo scopo di realizzare dei siti web per conto terzi (alias: clienti), mi sono avvicinato a Joomla. All'inizio sono rimasto abbastanza spaesato a causa del diverso approccio ma ho avuto la sensazione di avere tra le mani uno strumento più malleabile e più adattabile alle necessita del cliente. Pensavo di essere davanti ad una scatola completamente customizzabile, riuscendo dunque a fare ciò che con Wordpress non sarei riuscito a fare. Ho chiesto anche degli aiuti, visto che avevo i tempi un po' stretti, e ho ottenuto dei risultati davvero notevoli, grazie al lavoro svolto dai miei consulenti. Sono rimasto molto soddisfatto e sono riuscito ad apportare molte modifiche successive, convincendomi della bontà del prodotto.

Esce una nuova major release di Joomla. Decido di aggiornare: un disastro. Metà dei plugin installati non vanno più, l'altra metà si comporta in maniera sbagliata. Alcune funzioni fanno cose diverse da prima, rovinando completamente l'esperienza di utilizzo. Decido dunque, in mancanza di grosse advisory di sicurezza, di restare sulla versione precedente. Mi preoccupo, però: come ogni buon informatico sa, nessun software è perfetto, per cui prima o poi accadrà qualcosa che mi farà pentire della scelta. Neanche una settimana e cominciano a vandalizzare le pagine. Scopro che c'è una serie di falle, ovviamente tappate con la versione successiva. Che non riesco ad installare.

Mi partono un po' di imprecazioni. Mi parte l'angoscia. Comincio a fare delle manovre d'emergenza: cambio i permessi dei file, cambio alcune configurazioni di PHP, sposto il sito su un altro server (più controllato e sicuro), di fatto non risolvo il problema ma ci giro intorno. Nel frattempo, mi rendo conto che aggiornare è praticamente impossibile: dopo meno di un anno, ci sarebbe bisogno di rifare (quasi) tutto da zero. Assurdo.

Non finisce qui: gestisco molti server per conto di alcune aziende specializzate e noto quasi quotidianamente che gli unici CMS che vengono bucati come il formaggio sono proprio i Joomla non aggiornati, anche di poco. Ok, tutto andrebbe aggiornato, ma qui sembra quasi una rincorsa. Più del solito.

Decido di riprendere in mano i miei Wordpress, ancora attivi dopo anni e senza problemi. Sempre aggiornati cliccando un pulsante e basta, senza alcuna operazione complicata. Vedo che la piattaforma si è evoluta, vedo che ci sono nuovi plugin che vanno a riempire i vuoti lasciati volontariamente aperti dagli sviluppatori, insomma una piattaforma completa.

Ho ricominciato a lavorare con soddisfazione su Wordpress, e vorrei migrare tutti gli attuali Joomla su di esso. Riusciranno i nostri eroi a portare a termine l'operazione?

Ai posteri l'ardua sentenza. Ma ci sono dei plugin anche per questo :)

Wordpress su iPhone

Stefano Marinelli — Thu, 30 Sep 2010 07:04:33 GMT

Non scrivo da molto. Mancanza di idee? No. Mancanza di tempo. Adesso ho installato l'applicazione di Wordpress su iPhone. Speriamo aiuti, e ho un buon articolo in preparazione. Stay tuned!

Blog aggiornato a Wordpress 2.5

Stefano Marinelli — Tue, 01 Apr 2008 13:50:43 GMT

Dopo pochi giorni dalla sua uscita, ho deciso di aggiornare a Wordpress 2.5. Nessuno dei plugin dovrebbe avere problemi e tutto dovrebbe funzionare, per gli utenti, esattamente come prima.

Per vedere le modifiche e le ultimissime novita' inserite in questa versione, consiglio la visione del video esplicativo (4 minuti).

Vi prego comunque di segnalarmi qualunque malfunzionamento. Grazie!

Problemi con alcuni plugin su Wordpress "debianizzato"

Stefano Marinelli — Fri, 14 Dec 2007 12:41:41 GMT

[italian]Debian, da brava distribuzione GNU/Linux orientata ad amministratori accorti ed impegnati, fornisce un pacchetto "Wordpress" aggiornato nei suoi repository ufficiali. Mentre e' quasi improponibile utilizzare la versione della "stable", in quanto molto vecchia, essa puo' essere una scelta interessante in "unstable". Come spesso accade con pacchetti del genere (si veda squirrelmail, phpmyadmin, ecc.) il programma si installa nella /usr/share/wordpress e fornisce uno script (/usr/share/doc/wordpress/examples/setup-mysql) che permette di automatizzare la creazione di un nuovo blog. Basta infatti specificare l'indirizzo web del sito che si vuole creare e il gioco e' fatto. A questo punto sara' sufficiente istruire il proprio http server (Apache, lighttpd, nginx, ecc.) affinche' mappi nella directory locale /usr/share/wordpress tutte le connessioni in entrata relative al nuovo blog.

Approccio interessante. Vantaggi:

gestione centralizzata e automatizzata degli aggiornamenti
gestione centralizzata dei temi e dei plugin
un unica copia di wordpress in giro per il server

Uno dei principali benefici e' quello di "alleviare" il carico di ram e di cpu a xcache: i vari blog faranno sempre riferimento agli stessi file in php e xcache ne dovra' tenere semplicemente UNA copia, ricompilandola solo quando davvero ce ne e' bisogno.

Dopo alcuni mesi di utilizzo, pero', sono venuti alla luce alcuni problemi:

alcuni temi, come "Giraffe", richiedono alcune impostazioni specifiche e le memorizzano su file. Esse saranno comuni a tutti i blog utilizzanti il suddetto tema
alcuni plugin (come wp-supercache, wp-sitemap e cosi' via) si basano sul concetto che ogni blog ha una sua root e una sua specifica installazione nel sistema. Scrivono quindi dei file partendo dal presupposto che essi sono effettivamente parte di un singolo blog, creando risultati imprevedibili (es: www.blog1.net e www.blog2.net rischiano di avere una sitemap comune relativa al primo dei due che l'ha generata)
un aggiornamento "fasullo" potrebbe di compromettere tutti i blog presenti nel sistema

Possono esserci varie soluzioni. Coloro che creano questi plugin (o temi) dovrebbero utilizzare di piu' i database e meno i file ma in alcuni casi questo e' virtualmente impossibile.

Un'alternativa che devo ancora provare e' Wordpress-MU che dovrebbe avere tutto un sistema di isolamento dei singoli blog.

[/italian]

Wordpress

Stefano Marinelli — Wed, 24 May 2006 09:23:48 GMT

Bene...ho deciso di installare wordpress su questo sito per un paio di motivi:

Mi serve per lavoro :-)
Volevo provarlo, tutti ne parlano, tutti lo usano...volevo vedere cosa significava

Per il momento, dunque, su questo sito ho tolto l'ottimo Flatnuke ma non per mancanze o altro, solo per provare.

Un saluto quindi a tutti i visitatori! Non esitate, come al solito, a farmi notare problemi o altro.