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

Che sabato scorso sia andato a sentirmi qualche speech al DrupalCamp l’ho già detto, ma voglio ancora appuntarmi un paio di cose interssanti che ho sentito a che mi piacerebbe approfondire.

Bello il talk di presentazione fatto da horncologne che mi ha dato una visione più completa sulle caratteristiche e funzionalità di Drupal (di cui spero di poter recuparere le slide) ed interessante l’approccio al salvataggio delle configurazione su file, ma quello che mi ha “illuminato” è stato il talk su Solr. (In verità il talk era sul modulo per drupal che ne permette l’interfacciamento questo è un dettaglio… )

Di Solr ne avevo solo sentito parlare ma a suo tempo non ne avevo capito le potenzionalità ed in quali contesti poterlo sfruttare.

Penso che il progetto Apache Solr possa essere definito come un “motore di ricerca” al quale dare in pasto dei dati e che dopo averlo messo nelle condizioni di indicizzarle è in grado di poter restituire i risultati con delle logiche complesse che nulla hanno a vedere con una serie di “select from where”.

Oggi, dopo aver letto qualche documento, ho le idee decisamente più chiare e spero a breve di poterlo utilizzare in un progetto che è in fase di definizione e che potrebbe essere un’ottima occasione per approfondere le problematiche relative alla sua installazione ed alla sua configurazione.

L’interfacciamento in questo caso andrebbe fatto con un applicazione custom che viene valorizzata tramite un plugin per WordPress presente lato amministrazione ma le logiche di hook per l’invio dei dati sarebbero simili a quelle presenti nel modulo Drupal.

Se qualcuno avesse avuto esperienze simili e volesse aiutarmi a fare un plugin “wp-solr” sappia che è il benvenuto…

A dirlo non sono io ma Jennifer Lea Lampton durante la DrupalCon di Copenaghen lo scorso 23 Agosto.

Ma andiamo con ordine:
Sabato scorso sono stato al DrupalCamp di Torino (spendida location) e durante il talk di Jeffrey McGuire è stato segnalato un intervento molto “provocatorio” preparato da questa Jennifer che come potete vedere dalle sue esperienze non credo possa considerarsi una “fanboy” di WordPress.

Qui sotto le slide che danno una chiara idea del suo talk:

Sono convito che il tutto vada letto con spirito critico e come diceva anche Mizi in un commento su FriendFeed sono prodotti diversi con target diversi.

WordPress è una piattaforma che ha sicuramente molti margini di miglioramento sopratutto nell’implementazione del suo core e nell’ottimizzazione delle performance ma penso che a questo punto non sia più giusto considerarlo come un giocattolo ad uso esclusivo dei webdesigner.

update:
per chi vuole partecipare è partita un’interessante discussione su FriendFeed

Con il tempo ho deciso di smettere di reinventare l’acqua calda e di riscrivere pezzi di codice che sicuramente altri hanno scritto meglio di me e dopo essermi guardato un po’ attorno sperimentando diverse soluzioni ho scelto di concentrarmi e di specializzarmi su WordPress

Questo cappello per dirvi che leggendo alcuni commenti a questo sondaggio mi sono un po’ “stupito”…

• Stupito di aver trovato web-designers che preferiscono scrivere codice “from scratch” piuttosto che usare framework sviluppati, debuggati e mantenuti da solide community
• Stupito di aver letto di gente che “a prescidere dal contesto” pensa che a far tutto da se ci sia più libertà di movimento
• Stupito di aver constatato l’esistenza di “sviluppatori” in grado di affermare che usare un CMS non basta per un sito professionale

Ora io sicuamente sarei di parte se vi elencassi una serie di siti che potrebbero essere presi come esempio e che usano WordPress, quindi vi lascerò analizzare questi dati senza commetarli.

Se poi vi state chiedendo come sia riuscito un semplice “blog engine” ad essere il primo in questo elenco potete dare un’occhiata a questa infografica sulla diffusione di WordPress.

Per quanto mi riguarda ci sono poi anche delle motivazioni che accrescono la stima che ho nelle persone che fanno parte di Automatic come ad esempio il fatto che abbiano trasferito il marchio “WordPress” alla fondazione no-profit, mentre altre mi riempiono di soddisfazione come quella in cui Microsoft decide di adottare WordPress come piattaforma di blog predefiniata per Windows Live

Chiudo con una cosa che ultimamente mi capita di dire pittosto spesso: “WordPress è uno strumento molto semplice da usare ma è altrettanto semplice usarlo male (plugin e template compresi).”
Questo per dire che sta al singolo webdesign e/o sviluppatore fare le cose al meglio.

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…

Il 17 Giugno è stata rilasciata ufficialmente questa nuova release di WordPress e se ancora non conoscete quali sono le novità introdotte fareste bene a documentarvi velocemente.

Per quanto mi riguarda in questi mesi ho avuto modo di usare sul campo molte di queste nuove caratteristiche ed in particolare i “tipi” mi hanno risolto parecchi problemi.

Partendo dalla presentazione che avevo fatto in occasione del WordCamp ed approfondendo ulteriormente l’argomento ho raccolto una serie di cosine utili che è bene che metta da parte per quando ne avrò nuovamente bisogno.

Partiamo da un breve elenco di plugin per chi non vuole sporcarsi le mani con il codice:

• Custom Post Type UI: Tramite un comoda interfaccia vi consente di creare rapidamente nuovi tipi, nuove tassonomie e sopratutto di gestirne l’associazione.
• Post Type Switcher: Aggiunge una voce al box “pubblica” nella pagina di edit che ci permette di selezionare e/o cambiare il tipo. Utilissimo se vogliamo riorganizzare contenuti già pubblicati
• Simple Custom Post Type Archives: Questo plugin sopperisce ad una “mancanza” del core di WordPress che non rendeva di facile gestione il listing dei singoli tipi. Una volta attivato sarà possibile avere un archivio diverso in base al tipo. (es. http://nomeblog.com/nometipo/ ). Inoltre aggiunge alla gerarchia delle pagine “type.php” per personalizzarne la presentazione
• Featured Post Type: Widget molto comodo per visualizzare nella sidebar gli ultimi post filtrandoli per tipo.
• Custom Field Template: Se creiamo tipo diversi probabilmente avremo bisongno anche “custom filed” diversi. Questo plugin ci permette di creare box personalizzati con campi varibili in base al tipo

A seguire invece qualche snippets preso dal codex:

• In questo modo è possibile associare le tassonomi “base” di wordpress (categorie e tag) al nostro nuovo tipo
  register_post_type(‘nome_tipo’, array(
  ‘taxonomies’ => array(‘category’, ‘post_tag’),
  ));
• Per aggiungere un metabox personalizzato ed associarlo ad un particolare tipo (se volessimo associarlo ad un tipo buildin ci basterebbe usare ‘post’ o ‘page’ al posto di ‘nome_tipo’)
  add_meta_box( ‘html_id’, ‘Titolo del box’, ‘callback_function’,
  ‘nome_tipo’, ‘{normal|side}’ );  
• Per capire il tipo di post del post corrente
  $tipo = get_post_type()
• Per capire il tipo di post del post corrente
  $tipo = get_post_type()
• Per avere un elenco di tutti i tipi (restituisce un array)
  $post_types= get_post_types()
• Per sapere se un tipo esiste (restituisce un boolean)
  post_type_exists( $nome_tipo );

Per il momento mi fermo ed anche se le cose da dire sui tipi e le tassonomie sarebbero ancora tante spero che quanto detto posso esservi utile.

Mi segno qui i link di due librerie JavaScript che permettono il caricamento a runtime di risorse tramite ajax.

Il loro utilizzo, in alcune situazioni, dovrebbe migliorare i tempi di risposta ed esecuzione delle pagine web sfuttando la velocità del caricamento parallelo offerta orma dalla maggiorparte dei browser.

Si tratta di  Labjs e Sexy.js che a dirla in breve permettono di effettuare caricameni asincroni e sequenziali con una sintassi molto molto pulita.

Qui qualche esempio che spero rendano il concetto…

Per chi sviluppa template e plugin per wordpress a volte mancano gli strumenti per capire dove sono i problemi o dove poter lavorare per miglioare le perfomace.

Io per risolvere questi dilemmi, con il tempo, ho trovato alcuni plugin che a seconda delle necesità mi hanno dato un mano.

Giusto per fare un esempio vi dico che ne potete trovare uno in grado di visualizzare le query eseguite dal front-end (solo se loggati come admin)  evidenziando query eccessivamente lente, oppure altri che danno un quadro delle informazioni della piattafoma.

Il mio consiglio è quello studiarli e di provarli un po’ tutti cercando di capire cosa potrebbe essere meglio usare a seconda della situzione.

1. http://wordpress.org/extend/plugins/debug-queries/
2. http://wordpress.org/extend/plugins/debug-objects/
3. http://wordpress.org/extend/plugins/core-control/
4. http://wordpress.org/extend/plugins/wp-dbmanager/
5. http://wordpress.org/extend/plugins/wp-developer-assistan/
6. http://wordpress.org/extend/plugins/wp-development-utilities/
7. http://wordpress.org/extend/plugins/wp-debug/
8. http://wordpress.org/extend/plugins/query-debug-info/
9. http://wordpress.org/extend/plugins/wordpress-hook-sniffe/
10. http://wordpress.org/extend/plugins/sqlmon/
11. http://wordpress.org/extend/plugins/wp-migrate-db/
12. http://wordpress.org/extend/plugins/wp-crontrol/

Ovviamente prima di andare in produzione ricordatevi di eliminarli…

Se ne avete altri da aggiungere alla lista ringrazio anticipatamente chi vorra segnalarlo nei commenti.

Per la validazione di alcuni form ho avuto la necessità di localizzare le stringhe di errore gestite all’interno di un file Javascript.
Volevo un sistema che non fosse eccessivamente invasivo, simile al gettext che uso con php ma che fosse indipendante da codice serverside e che mi permettesse di caricare e cambiare il file con le riserse localizzate anche a runtime.

Quello che ne è uscito mi piace molto e penso che sia anche sufficentemente scalabile pur avendo come limite il fatto di lavorare su array di stringhe un oggetto json piuttosto che su file compilati.

In pratica dopo aver dichiarato l’oggetto in cui “cercare” le traduzioni, ho preparato una funzione che verifica la presenza della stringa localizzata e nel caso non venga trovata mi restituisse quella “non localizzata”.

Usando questa funzione all’interno dei miei file js sono in grado di separare (ed eventualmente rimandare) le problematiche relatavie alla localizzazione rimanendo concentrato sul codice.
Nell’esempio qui sotto viene visualizzato un alert con un bel “ciao” sino a quando non viene caricata una risorsa in lingua

Per caricare il file con le risorse localizzate includo lo script a runtime con “getScript” (magari dopo aver letto un cookies…)

Questa la struttura del file di risorse (en_EN.js) che nel momento in cui viene richiamata ridefinisce completamente l’oggetto “Localization”

Uno dei vantaggi di questo sistema è che andrò a localizzare solo ciò che mi serve con un approccio non intrusivo.
In atre parole se la stringa o il file non vengono trovati viene restituita la stringa non localizzata.
Ancora una nota per chi volesse usarlo: dentro LoadLocale c’è una chiamata a jQuery che quindi va considerato tra i requisiti necessari.

Per migliore le performance, indipendentamente dalla dimensione del file della localizzazione, sarebbe consigliabile minimizzare i file javascript con strumenti tipo questo.

Questi alcuni link da cui ho preso ispirazione.

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.