WordPress e Lighttpd allo stato dell’arte

L’11 ottobre scorso ho iniziato a configurare un nuovo VPS scegliendo Lighttpd come web server. Era destino, visto che il mio primo tema WordPress era uguale al primo tema usato da Lighty. Oggi ho approfittato di una giornata tranquilla per poter correggere alcune pecche relative a WordPress, e a questo punto sono soddisfatto al 100%.

Il problema più spinoso riguarda la configurazione delle regole di rewrite. La logica delle regole di WordPress è molto semplice: se il file o la directoy non esistono, la richiesta va inoltrata all’index.php che si trova nella root del sito. Purtroppo in Lighttpd non c’era la possibilità di fare una regola condizionale, e quindi anche file e directory esistenti (come per esempio wp-admin, in cui risiede il pannello di gestione di WordPress) finivano nel tritacarne del rewrite.

Una delle soluzioni percorribili era di ragionare per negazione e di creare delle regole di redirect ridondanti (nel senso wp-content => wp-content) da far eseguire prima di quella jolly, ma si rischiava sempre di lasciare qualcosa per strada. Un’altra soluzione, che non ho nemmeno tentato, era ricompilare Lighttpd con il supporto a mod_magnet, un modulo che permette di inoltrare le richieste ad un file LUA, dove si potevano usare regole più flessibili e potenti. Al di là della necessità della ricompilazione, avevo forti dubbi sulle prestazioni.

Fortunatamente posso parlare al passato, perché ormai Lighty ha finalmente la possibilità di creare una regola condizionale, ed ecco che per la configurazione del rewrite per WordPress basta una semplice riga:

url.rewrite-if-not-file = ("^/(.*)$" => "/index.php/$1")

Per dirla tutta, non basta una semplice riga, perché come si può intuire viene eseguita la riscrittura solo se è il file a non esistere! Se richiediamo una directory, ecco che siamo di nuovo al punto di partenza. Ma arrivati a questo punto, la soluzione è facile; basta evitare di richiedere directory. Per esempio, per accedere alla bacheca basta essere un pelo più specifici: /wp-admin/index.php

Se si desidera accedere alle statistiche, che nel mio caso sono all’indirizzo /awstats/awstats.pl, basta creare la cartella awstats ed un file vuoto awstats.pl.

[Aggiornamento]: ecco la regola, riveduta e corretta, per escludere la directory wp-admin dal rewrite:

url.rewrite-if-not-file = ("^(/(?!(wp-admin/)).*)" => "/index.php/$1")

A proposito di statistiche, io preferisco usare il plugin ufficiale di WordPress.com, e per una regola di redirect troppo grossolana non riuscivo più a visualizzare i grafici, quelli prodotti tramite Flash. Infatti veniva eseguito il redirect di qualsiasi indirizzo contenente stats verso Awstats, appunto, e visto che la cartella del plugin si chiama stats… Per correggere questa situazione, ho aggiunto un cappelletto in modo che il redirect venga effettuato solo se la richiesta inizia con stats.

url.redirect   += ("^/stats/" => "http://quacos.com/awstats/awstats.pl")

Comunque grazie ad Awstats ho avuto la conferma che ancora parecchie persone richiedono degli articoli che ho trasferito su altri blog più pertinenti, e quindi ho ripreso in mano il file .htaccess e la lista di redirect che avevo compilato al tempo, per poi tradurre dallo stile Apache

Redirect 301 /pagina http://altrosito/pagina

…allo stile Lighttpd:

url.redirect += ("/pagina" => "http://altrosito/pagina")

Giusto per chiarire un concetto: Lighttpd non usa i file .htaccess, tutti questi elementi vanno inseriti nel file di configurazione dell’host.

Concludendo, la combinazione WordPress + Lighttpd + W3 Total Cache + APC mi ha pienamente soddisfatto, dimostrando massima rapidità, ma ancora non so fino a che punto può reggere sotto un boom di visite. Quello che so, è che non sarà Digg a portarle

2 thoughts on “WordPress e Lighttpd allo stato dell’arte

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

%d blogger hanno fatto clic su Mi Piace per questo: