Per parlare di qualità, tra le tante cose, si devono definire requisiti ed obiettivi e poi trovare degli indicatori per poterli misurare.
Io sto cercando di intrudurre una serie di linee quida nel mio modo di sviluppare ad una di queste si riferisce alla velocità ed al numero di query con cui vengono generate le pagine.

Gli indicatori che mi danno la misura e mi permettono di capire se sto rispettando i miei requisiti sono di tre tipi:

1. Lato browser: YSlow, Page Speed ma anche il pannello “Net ” di Firebug. Con questi verifico i tempi di caricamento dei singoli componenti della pagina ed eventuali colli di bottiglia nel caricamento di js.
2. Lato server: XHProf . Si tratta di un profiler gerarchico per verificare i tempi di esecuzione di ogni singola funzione.
3. Lato WordPress: Debug Query e Debug Object. Tramite questi plugin ho sotto controllo il numero di query ed un dettaglio dei singoli oggetti interni a WordPress.

E’ ovvio che uno dei primi livelli di ottimizzazione sia l’intruduzione dei sistemi di cache.
Un uso appropriato può farci risparmiare diverse query e parecchi ciclo di CPU ma dato che in molti hanno già parlato dei plugin che possono aiutarci nella gestione “semiautomatica” della cache vado oltre e vi segnalo solo un articolo fatto da qualcuno che si è anche preoccupato di andare un po’ più a fondo preparando qualche test.

Dalla versione 2.0 nel core di WordPress è presente un sistema di caching non permanente (nel senso che i dati sono residenti in memoria e solo per la durata della singola sessione).

Qui un breve esempio:

Io spesso lo uso anche per salvarmi anche pezzi di html

“;
endforeach;
wp_cache_set( ‘elenco_ultimi_5_post’, $last5 );
endif;
}

Usando un sistema di questo tipo se volessi visualizzare l’elenco degli ultimi 5 post pubblicati nella mia sidebar eviterei di chiedere al database la stessa informazione per ogni pagina visualizzata ma dopo la prima richiesta verrebbe messo in memoria il risultato e reso subito pronto e disponibile per la volte successive.

Dal rilascio della 2.8 le cose sono anche migliorate con l’introduzione delle Transients API che offrono sistema “standardizzato” per il salvataggio della cache su database.
Questo ci permette di salvare le informazioni “cross-sessione” rendendo riutilizzabile la cache anche per utenti diversi.

Questo è il codice con l’esempio di prima riadattato con le Transients API

“;
endforeach;
set_transient( ‘elenco_ultimi_5_post’, $last5,3600 );
endif;
}

Questo piccolo cambiamento rende persistente la mia cache per un ora (3600 secondi) ed accessibile per ogni visitatore.

Il sistema potrebbe però avere ancora un limite in quanto nel caso venisse modificato o pubblicato un nuovo post questo non verrebbe visualizzato nell’elenco sino al momento in cui la cache non risultasse invalidata e quindi ricreata.
Tramite un semplice hook possiamo pero risolvere il problema…

add_action(‘save_post’, ‘delete_last5_cache’);
function delete_last5_cache( $post_id ) {
global $post;
if ( $post->post_status == “publish”) {
// cancello la cache
delete_transient(‘elenco_ultimi_5_post’);
}
}

In alcune situazioni però questo non mi bastava ancora in quanto avrei voluto rendere persistente una porzione ancora più grossa (es. tutta la sidebar e/o tutto il footer). Quello che cercavo era qualcosa di simile a get_template_part ma con un salvataggio su cache.

Ho quindi scritto io una funzione che ho chiamato cache_template_part.
Questo il sorgente:

/*
* 2010 | maurizio | http:maurizio.mavida.com
* versione 1.2
* viene effettuata una cache su disco di una porzione di codice
* @param string $file – nome del template da caricare
* @param bool always – visualizza sempre la cache (anche all’amministratore)
* @param bool rewrite – ricrea sempre la cache anche se ancora valida
* @param int cachetime – numero di secondi dopo il quale viene invalidata
* @param string cachepath – percorso per il salvataggio della cache
*
* es. cache_template_parts(“sidebar.php”);
* es. cache_template_parts(“sidebar.php” , array( ‘cachetime ‘ => 14400 ) );
*/
function cache_template_part( $file , $args = null ) {

$defaults = array(
‘always’ => false,
‘rewrite’ => false,
‘cachetime’ => 3600,
‘cachepath’ => ‘wp-content/cache/’,

);

$args = wp_parse_args( $args, $defaults );
extract( $args, EXTR_SKIP );

$cachefile = $cachepath . str_replace( “/”, “-”, $file);
$cachefile_created = ((@file_exists($cachefile)) ) ? @filemtime($cachefile) : 0;

if ( !$rewrite and ( time() – $cachetime < $cachefile_created ) and ( $always || !is_user_logged_in()) ) {
echo file_get_contents( $cachefile );
} else {
//ob_start(ob_gzhandler);
ob_start();

include($file);

if ( $always || !is_user_logged_in() ) {
// in caso di utente loggato manda subito l’output
$b = ob_get_clean();
//$b = trim(preg_replace(‘/\s+/’, ‘ ‘, $b));
$b = preg_replace(‘/[ ]+/’, ‘ ‘, $b);
$b = str_replace( array(“\r\n”, “\r”, “\n”, “\t” ), ”, $b);

if ( strlen($b) > 1 ) {
// controllo che il buffer sia valorizzato
$b = “” . $b;
file_put_contents( $cachefile , $b);
}

echo $b;

}
ob_end_flush(); //
}
}

L’unico argomento obbligatorio è il nome della file da caricare con una serie di argomenti opzionali (che devono essere passati come array).

Al momento, a differenza delle Transients API, ho deciso di salvare la cache su disco sequendo l’appoccio suggerito anche da altri plugin che in caso di problemi permette un debug più semplice e veloce (una semplice eliminazione dei file forze la rigenerazione della cache )

Se qualcuno volesse usarla, debuggarla e/o suggerirmi come migliorarla la può scaricare da qui sotto.

Questo vuole essere un’esempio di quello che intendo per qualità che può essere riassunto in un uso consapevole delle funzionalità core di WordPress e la realizzazione di “utility” che possano aiutare al raggiungimento dei requisiti.

Ultima nota finale:
Il fatto di usare sistemi di cache manuale non vuol dire che si debbano usare solo quelli.
Un bella spinta la può dare l’utilizzo dell’APC Object Cache Backend (se il server lo supporta).
Se siete tra i fortunati ad avere nginx come web server vi suggerisco Nginx proxy cache integrator.
E poi per tutti il forse poco conosciuto Widget Cache

Lo so. Il titolo è un po’ criptico ma provo a descrivervi lo scenario:

Installazione di WordPress. Siamo in homepage. Durante il listing dei contenuti devo gestire, a seconda del tipo e della posizione, il modo con cui i posts vengono visualizzati (es. immagini, allineamento, tassonomie ).

Mi spiego meglio. Ho registrato due nuovi tipi (ex. video e libri) ai quali ho associato delle tassonomie personalizzate (es. i video hanno i registi mentre i libri gli autori).

Nel mio loop voglio visualizzare film e libri con uno stile che indichi chiarmanete di che tipo è questo contenuto ed inoltre voglio aggiungere le informazioni reletive alla tassonomie proprietarie.

La cosa si complica ancora perchè i primi n contenuti (nel nostro caso 3) sono considerati “featured” e vanno visualizzati con thumbnail ed excerpt mentre gli altri sono con il titolo.

Partiamo dall’inizio ed iniziamo ad aggiungere i “custom type” in home:
(io questo snippet l’ho aggiunto in functions.php ed è importante farlo in quanto di default vengono visualizzati solo i tipo “post”)

Ora vediamo il codice del loop nel quale ho usato get_template_part per la gestione in base al tipo.

In questo modo a seconda del “post type” viene cercato e poi incluso un file con questo nome “post-layout-tipo.php”.
Mi sono quindi creato tre file (post-layout-libri.php, post-layout-video.php, post-layout.php) nei quali sono andato a preparare del markup specifico.

Prendiamo adesso come esempio quello dei libri: (post-layout-libri.php)

La funzione principale che mi permette di gestire il layout a livello di css è post_class che aggiunge "dinamicamente" due classi le quali definiscono il "post type" e visualizzazione dei "featured"

Per la visualizzazione delle tassonomie personalizzate mi affido ad un semplice the_terms alla quale indico l'ID del post ed il nome della tassonomia.

Arrivati qui basta lavorare un po' con i fogli di stile per avere il pieno controllo di cosa e come visualizzare i nostri contenuti.

Il codice scritto è ovviamente perfettibile e la prima cosa da fare sarebbe quella di ridurre la ridondanza di codice e fare cache dei contentuti.

Se qualcosa non fosse chiaro.... chiedete.

Nota: Al momento in questo codice non viene gestita la paginazione. Forse, magari, può darsi che sia argomento di un futuro post.

Prima di andare “definitiviamente” online con un sito, indipendentemente dallo strumento usato (sia questo WordPress o codice “from scratch”),  è mia abitudine fare una serie di operazioni che in genere mi aiutano ad evitare problemi.

Con il tempo ho preparato questa Checklist in cui potrete trovare attività che vanno da quelle di competenze più  “seo” a quelle che sono operazioni puramente sistemistiche.

Come qualsiasi altra Checklist non va applicata “bovinamente”, ma adattata in base ella proprie competente ed agli accordi presi con il cliente.

1. Preparazione profilo Google Analytics e condivisione accesso con email cliente
2. Configurazione script tracciamento sul sito e configurazione custom_var (Google Analytics for WordPress)
3. Preparazione sitemap (Google XML Sitemaps)
4. Registrazione Google WebMaster Tools e segnalazione sitemap
5. Registrazione Bing WebMaster Tools e segnalazione sitemap
6. Verifica file Robots.txt con escusione aree riserate (iRobots.txt)
7. Configurazione servizio di monitoraggio con segnalazione mail in caso di down (es Monastic)
8. Configurazione backup file e database (WordPress Backup / WordPress database backup)
9. Controllo funzionamento Form contatti
10. Preparazione .htaccess per compressione gzip, configurazione cache ecc… (vedi High Performance Web Sites)

Qui sotto il download con il pdf della Checklist…

Se pensate ci siano altre cose da aggiungere fatemelo sapere…

Imap è una gran bella comodità e quando ti abitui finisci per non poterne fare più a meno.
Se poi sei anche il sysadmin del server che ospita la tua casella e per ovvie ragioni non hai problemi di spazio è come avere una “gmail” ancora più comoda.

L’unico problema è quando arriva il momento di cambiare server.
Ecco che allora ti fai una domanda: “ma io la posta come la sposto da un server all’altro?”

Inizialmente ho pensato di fare la migrazione passando attraverso un client (vedi thunderbird) ma la cosa, avendola sperimentata con alcuni clienti, sarebbe stata decisamente lunga….

La soluzione, fortunatamente, era dietro l’angolo: imapsync

L’installazione sulla mia fidata debian (lenny) è stata una passeggiata:

Il suo utilizzo è decisamente elementare: in pratica è necessario passargli i dati per collegarsi al server da cui copiare e poi quelli del server in cui vanno copiate le mail.
Questo un esempio di sintassi:

{NomeServerUno}: ip o dominio server di origine
{NomeUtenteUno}: Nome utente server di origine
{PasswordUno}: password server di origine
{NomeServerDue}: ip o dominio server di destinazione
{NomeUtenteDue}: Nome utente server di destinazione
{PasswordDue}: password server di destinazione

Tra le opzioni disponibili possiamo indicare se usare una connessione ssl, escudere messaggi troppo grossi o troppo vecchi e/o escudere intere directory.
La sincronizzazione è un’operazione relativamente lunga e nel mio caso dove avevo oltre un giga di posta è durata più di 20 minuti.

Ne hanno parlato anche qui, qui e qui.

Uno degli elementi tipici di un blog è il box per la ricerca e qualche giorno fa mi sono messo in mente di cambiare quello presente su questa pagine.

Ho quindi iniziato a guardarmi un giro cercando di trovare qualcosa che mi piacesse e dallo screening effettuato sono venute fuori diverse cose interessanti.

Quello che non ho trovato sono state le popolarissime “inspiration list” ed ho quindi deciso di presentarvene 10 che, secondo il mio gusto, ritengo siano decisamente “stilose“.

Sohtanaka: Web development & design

Michael Tyson: Life, tech, Cocoa development, Mac

Alex Buga: Webdesigner superstar

College Park Church

Janko at warp speed

WordPress theme: Review

WordPress theme: Personal

WordPress theme: Clearpress

WordPress theme: Industry

WordPress theme: Chrome

Finiti gli esempi affrontiamo adesso la realizzazione.
Dal punto di vista tecnico ho visto usare diversi approcci ma uno in particolare mi è piaciuto per la sua semplità.

Questa è la struttura semantica:

Il box è tenuto insieme da un div dalle dimensione fisse che si occuperà di gestire lo sfondo. Al form form vengono impostati margin e padding a zero, mentro sui tag input vanno eliminati i bordi e definito un posizionamento float.

L’elemento più “complicato” da gestire è il campo di ricerca “searchfield” al quale non daremo un altezza fissa ma utilizzeremo dimensione del font, padding e margin.
Infine il submit che va preparato in modo tale da far coincidere l’altezza con quella del div che lo contiene. In alcuni casi ho visto usare un segnaposto completamente trasparente in modo che sia l’immagine di sfondo a gestire tutto.

Questa soluzione non rappresenta l’unico modo di affrontare il problema e nei 10 link presentati è possibile trovare altre tecniche altrettanto interessanti.

Concludo segnalandovi questo articolo che è l’unico che ho trovato sull’argomento.

Ubuntu e molte altre distribuzioni “desktop” ci hanno abituato a quella piccola magia chiamata automount che permette il colleganeti automatico al filesystem di periferiche USB come un dischi removibili o sempici chiavette.

In pratica ci evita la “noia” del mount.

Come dicevo qualche riga sopra questa funzionalità è presente in moltissime distrubuzioni dotate di Desktop environment ma nel caso volessimo usarla sulla nostra debian minimale dobbiamo installare un pacchetto aggiuntivo.

Fino a ieri avrei suggerito autofs il quale funziona egregiamente a patto di avere voglia di fare qualche piccola configurazione ma, oggi, dopo aver fatto una piccola ricerca per rispondere ad un mail ricevuta da un certo Riccardo sono venuto a conoscenda di USBmount.

The USBmount Debian package automatically mounts USB mass storage devices (typically USB pens) when they are plugged in, and unmounts them when they are removed. The mountpoints (/media/usb[0-7] by default), filesystem types to consider, and mount options are configurable.

Essendo presente nei reposity debian è sufficente il solito:

Come già scritto anche in queste pagine il mount di chiavette formattate con fat32 richiede una modifica al file di configurazione (“/etc/usbmount/usbmount.conf”) aggiungendo “vfat” all’elenco dei filesystem riconosciuti.

Infine per applicare i cambiamenti è necessario riavviare udev

A questo punto per poter poter accedere alla nostra chiavetta USB ci basterà spostarci sotto “/media/usb” (ovviamente dopo averla inserita)

Questa mattina controllando i report di alcuni server relativi al traffico generato ho visto qualcosa di alquanto anomalo.

Il grafico che vedete rappresente l’attivita del protocollo ssh e come potete osservare dalle 4.30 alla 6.30 qualche simpatico amico a tentato un brute force.

Da una prima analisi non sembra essere successo nulla di grave in quanto dai log si può vedere un banale tentativo di dictionary attacks.

Sotto potete vedere una parte del log restituito da questo comando:

Nello stesso modo ho poi verificato gli accessi “autorizzati” e fortunatamente non ne risultano altri oltre a quelli fatti dal sottoscritto:

E’ anche vero che nel caso in cui il nostro hackers fosse riuscito ad accedere avrebbe potuto eliminare una parte dei log ma voglio pensare che avrebbe eliminato tutti i riferimenti al suo ip.

Anche se considero l’attacco fallito ho cercato in rete come evitare questo tipo di attacchi e come in tante altre occasioni la ricerca è durata meno di un minuto: Preventing SSH Dictionary Attacks With DenyHosts

DenyHosts è un tool di sicurezza scritto in Python per server SSH. È pensato per prevenire attacchi brute force verso server SSH monitorando i tentativi di login invalidi nel log di autenticazione e bloccando gli indirizzi IP. (via wikipedia)

Dopo aver verificato se il pacchetto fosse già presente nei repository debian ho provveduto al solito:

Una veloce occhiata al file di configurazione per modificare la mail a cui inviare gli avvisi sui nuovi hosts bloccati ed un controllo lo script fosse in funzione come servizio sono al momento sufficenti per <s>farmi dormire tranquillo</s> rimandare di 24 ore le prossime analisi.

Seguendo alcuni suggerimenti di un essere illuminato, sto lentamente mettendo in pratica quanto ascoltato durante l’ iWordCamp.

Mi appunto quindi i comandi da lanciare in modo non dovermi ricordare la sintassi ed evitare refusi…

In alcune installazioni il nome delle vostra tabelle potrebbe essere diverso… verificate quindi prima se avete usato un prefisso.
(file wp-config var $table_prefix)

Mi verrebbe anche voglia di scrivere un piccolo plugin per rendere il lavoro ancora più veloce, ma mi sembra una roba troppo banale.

N.B.
L’applicazione di questi indici è applicabile solo nel caso abbiate una versione di wordpress 2.3 o superiore.

Già che si sono segnalo anche questo script che suggerisce ulteriori tuning per il vostro database server preferito (via giorgio)

Avete mai provato a cercare su un indice FullText con una stringa sotto i 4 caratteri ?

Bhe, io dopo essere diventato scemo, ho scoperto che per default la lunghezza minima è impostata a 4 caratteri.

Se quindi state cercando stringhe come “php“,”htm” o “css“, e nonostante siate sicuri che ci siano riscontri, la ricerca non vi restituisce nessun record, non è dovuto ad una tabella corrotta, ma molto più semplicemente perché l’indice in condizioni normali non gestisce ricerche di questo tipo.

La soluzione, se siete nelle condizioni di modificare il file di configurazione, fortunatamente c’è, e prevede 3 operazioni

1. E’ necessario definire il valore della variabile ft_min_word_len all’interno del file my.cfg
   ft_min_word_len=3
2. Riavviare il server in modo che valorizzi in modo corretto la nuova impostazione
3. Per finire, è necessario fare il rebuild degli indici, in modo che vengano ricostruiti con tutte le informazioni corrette
   REPAIR TABLE nometabella QUICK;

Facile come bere un chupito… basta saperlo.

Per la documentazione ufficiale basta guardare qui

Ci sono delle volte nella vita di un sistemista dove dopo aver allestito un nuovo Windows Server 2003, aver installato tutto il necessario compresi antivirus e backup giunge il momento di configurare IIS.

Nel caso il server sia adibito ad ospitare nuovi siti, non ci sono altre alternative che la configurazione attraverso l’interfaccia di amministrazione, ma nel caso di un migrazione da un altro server, dove magari sono presenti decine e decine di siti configurati la strada “facciamolo a mano” diventa lunga ma sopratutto la probabilità di fare qualche errore aumenta in modo direttamente proporzionale al numero di siti da configurare.

Diventa quindi lecito domandarsi come importare sulla nuova macchina la configurazione presente sul vecchio server.

Purtroppo dall’interfaccia di amministrazione le uniche operazioni che riguardano la gestione del metabase di IIS sono relative al backup ed relativo ripristino, ma fortunatamente Microsoft non ci lascia completamente a mano vuota, rendendo possibile l’operazione di esportazione e importazione tramite uno script vbs utilizzabile via shell.

Dal titolo del post, avrete capito che sto parlando di iiscnfg

Dopo aver letto un po’ di documentazione ed avendo come obbiettivo l’esportazione completa del metabase del vecchio server e la sua importazione sulla nuova macchina sono stati sufficienti 2 comandi …

Questo è il comando per l’esportazione, che ovviamente va eseguito sul server in cui c’è la configurazione da copiare.

Vediamo insieme i parametri:

• /f indica che l’esportazione deve avvenire su file ( nel mio caso nomefile è c:iisconfig_backup.xml )
• /sp indica il ramo del metabase, che nel mio caso è un semplice slash che indica tutto ma potrebbe anche indicare un singolo sito
• /children consente semplicemente di esportare in maniera ricorsiva tutte le sottochiavi

Se tutto è andato bene dovremmo ritrovaci sotto c un file xml che dobbiamo far arrivare sul nuovo server per poterlo importare.

Prima di procedere all’importazione, nel caso abbiate già modificato qualcosa suggerisco un backup, che potete effettuare o tramite l’interfaccia di amministrazione o via shell con iisback.

Arrivato a questo punto vediamo il comando per l’importazione che è leggermente più complicato …

In questo caso ci sono due parametri in più:

• /dp specifica il percorso della metabase in cui vengono memorizzate le chiavi, discorso simile a quello per /sp e nel mio caso dove voglio importare tutto indico solo lo slash
• /merge consente di combinare le chiavi nel file XML con le chiavi esistenti della metabase. Forse questo parametro nel caso di una configurazione da zero è inutile, ma nel caso abbiate già fatto modificato la configurazione di IIS questo vi permettera di importare solo le chiavi nuove

Questo funziona a patto che i percorsi rimangano gli stessi, ovvero se i siti prima erano sul disco e: dovranno essere su e: anche adesso.

Nel caso non sia possibile ricreare la stessa configurazione, suggerisco la modifica del file xml con il metabase prima dell’importazione, altrimenti vi tocca modificare a mano tramite l’interfaccia di amministrazione sito per sito.

Un ultima cosa; se durante la migrazione i due server si possono “parlare” potrebbe essere più comodo copiare direttamente la configurazione tra un server e l’altro, ma nel mio caso, essendo i due server in due posti fisicamente diversi, ed essendo sotto firewall non è stato possibile praticarlo.

Sperando di non aver dimenticato nulla, e di non aver scritto caz**te, questo è quanto …

Link di riferimento: Gestione di configurazioni di IIS tramite script

[tags]IIS, metabase, iiscnfg, iisback [/tags]