.:: Maurizio Pelizzone ::. » featured

WordPress e qualità: sistemi di cache manuali

Maurizio Pelizzone — Tue, 28 Dec 2010 14:50:39 +0000

Leggi l'orginale su http://maurizio.mavida.com

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:

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.
Lato server: XHProf . Si tratta di un profiler gerarchico per verificare i tempi di esecuzione di ogni singola funzione.
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:

1
2
3
4
5
6

$last5 = wp_cache_get( 'elenco_ultimi_5_post' );
if ( false == $last5 ) {
$sql_last5 = "select ID from $wpdb->posts where post_type = 'post' and post_status = 'publish' order by post_date desc limit 5";
$last5 = $wpdb->get_results( $sql_last5 );
wp_cache_set( 'elenco_ultimi_5_post', $last5 );
}

Io spesso lo uso anche per salvarmi anche pezzi di html

1
2
3
4
5
6
7

$last5 = wp_cache_get( 'elenco_ultimi_5_post' );
if ( false == $last5 ) {
$sql_last5 = "select ID, post_title from $wpdb->posts where post_type = 'post' and post_status = 'publish' order by post_date desc limit 5";
$last5_data = $wpdb->get_results( $sql_last5 );
if ($last5) :
foreach ($fivesdrafts as $post) :
$last5 .= "

ID) . "">” . $post->post_title. “

“;
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

1
2
3
4
5
6
7

$last5 = get_transient( 'elenco_ultimi_5_post' );
if ( !$last5 ) {
$sql_last5 = "select ID, post_title from $wpdb->posts where post_type = 'post' and post_status = 'publish' order by post_date desc limit 5";
$last5_data = $wpdb->get_results( $sql_last5 );
if ($last5) :
foreach ($fivesdrafts as $post) :
$last5 .= "

ID) . "">” . $post->post_title. “

“;
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

Leggi l'orginale su http://maurizio.mavida.com
WordPress e qualità: sistemi di cache manuali was first posted on dicembre 28, 2010 at 3:50 pm.

Usare trackPageview asicrono su due account

Maurizio Pelizzone — Sat, 13 Nov 2010 10:24:34 +0000

Leggi l'orginale su http://maurizio.mavida.com

Uno sei suggerimenti che mi sono portato a casa dal corso di Google Analytics Avanzato è relativo alla gestione del tracciamento delle pagine su account multipli.

Lo scenario in cui può servire una cosa del genere è quando risulta necessario rendere disponibile ad un account esterno i dati provenienti di un sottoinsieme di pagine senza gonfiare le statistiche dell’account principale con delle “pagine virtuali” (vedi _trackPageview)

Anche se sulla documentazione ufficiale c’è scritto tutto preferisco appuntarmelo su queste pagine…

Questo è il codice da usare per tracciare la stessa pagina su due account diversi:

1
2
3
4
5
6

_gaq.push(
['_setAccount', 'UA-XXXXX-1'],
['_trackPageview'],
['b._setAccount', 'UA-XXXXX-2'],
['b._trackPageview']
);

Se poi siamo in una situazione in cui su questi account vengono tracciati più domini di primo livello (['_setDomainName', 'none']) e magari ci sono di mezzo anche variabili custom lo script diventa una roba del genere:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-XXXXX-25']);
_gaq.push(['_setDomainName', 'none']);
_gaq.push(['_setAllowLinker', true]);
_gaq.push(['_setAllowHash', false]);
_gaq.push(['_setCustomVar',1,'customers', 'CustomerName',3]);
_gaq.push(['_trackPageview']);

/* inzio tracciamento su account cliente */
_gaq.push(['ca._setAccount', 'UA-XXXXX-34']);
_gaq.push(['ca._setDomainName', 'none']);
_gaq.push(['ca._setAllowLinker', true]);
_gaq.push(['ca._setAllowHash', false]);
_gaq.push(['ca._trackPageview']);

(function() {
var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
})();

In questo modo ottengo delle statistiche pulite sull’account principale e dove serve traccio la visite sulle pagine anche sul quello esterno.
Morale della storia: ogni account ha le sue statistiche e tutti vivono felici e contenti…

Leggi l'orginale su http://maurizio.mavida.com
Usare trackPageview asicrono su due account was first posted on novembre 13, 2010 at 11:24 am.

WordPress: Alterare il layout durante un loop

Maurizio Pelizzone — Fri, 22 Oct 2010 12:46:03 +0000

Leggi l'orginale su http://maurizio.mavida.com

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”)

1
2
3
4
5
6
7
8
9
10

add_filter( 'pre_get_posts', 'get_home_posts' );

function get_home_posts( $query ) {

if ( is_home() && !$query->query_vars['suppress_filters'] ){
$query->set( 'post_type', array( 'post', 'video', 'libri' ) );
}

return $query;
}

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

1
2
3
4
5
6
7
8
9
10
11

if (have_posts()) : while (have_posts()) : the_post();

$post_index ++;

// controllo se l'articolo è tra i primi 3 e dichiaro una classe "featured"
$post_class_position = "";
if ( $post_index < 3 ) $post_class_position = "featured";

get_template_part( 'post-layout', get_post_type( $post ) );

endwhile; endif;

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)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

the_ID(); ?>" post_class( "tipo_libro " . $post_class_position ); ?> >

the_permalink(); ?>" title=" the_title_attribute( ) ?>" rel="bookmark">
the_title(); ?>

custom_posted_on(); // meta information (post—date/time and author)
?>

//funzione custom per le gestione della thumbnails
if ( $post_class_position == "featured") {
$args = array("class" => "alignleft", "link" => get_the_permalink() );
the_thumb( $args );
}
?>

if (is_single() ) {
the_content(); // visualizzazione su pagina di dettaglio (single.php)
} else if ( $post_class_position == "featured") {
the_excerpt(); // visualizzo il riassunto solo se è presente la classe "featured"
}
?>

the_terms( $post->ID, 'autore', "Autore: " ); //tassonomia personalizzata
custom_posted_in(); //meta information (category, tags and permalink)
?>

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.

Leggi l'orginale su http://maurizio.mavida.com
WordPress: Alterare il layout durante un loop was first posted on ottobre 22, 2010 at 1:46 pm.

WordPress è meglio di Drupal

Maurizio Pelizzone — Mon, 04 Oct 2010 08:41:24 +0000

Leggi l'orginale su http://maurizio.mavida.com

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

Leggi l'orginale su http://maurizio.mavida.com
WordPress è meglio di Drupal was first posted on ottobre 4, 2010 at 9:41 am.

WordPress: XML Sitemap e Custom Post type

Maurizio Pelizzone — Wed, 29 Sep 2010 11:40:28 +0000

Leggi l'orginale su http://maurizio.mavida.com

Su quasi tutte le installazioni WordPress di cui seguo lo sviluppo è mia abitudine installare e configurare la generazione della sitemap attraverso questo plugin: Google XML Sitemaps.

Poi, come già vi dicevo quando parlavamo di checklist, vado a segnalare la presenza della sitemap sui webmaster tools.

Succede però che per un sito in cui i contenuti sono stati pensati facendo un largo uso dei Custom Post Type mi accorga che il crawler legga solo una piccola porzione delle pagine preparate.

Penso ad un errore nella configurazione dei permalink e cerco tra gli errori si scansione ma non trovo nulla. Poi leggo meglio il numero di “URL inviati” e trovo 4 (quattro).

Essendo le pagine sul sito oltre 50 decido di dare un’occhiata alla sitemap (in genere http://nomesito.it/sitemap.xml) e mi accorgo che dentro questo file xml mancano tutti i riferimenti alla pagine di tipo Custom Post Type.

Dopo qualche tentativo tra cui, riconfigurazione del plugin e rigenerazione della sitemap, vedo che la situazione non cambia e decido di dare un’occhiata al codice: (file: sitemap-core.php, riga 1747)

(post_status=’publish’ AND (post_type=’post’ OR post_type=”))

Bene, per lo meno adesso sappiamo il perchè: i Custom Post Type non vengono neppure presi in considerazione.
La cosa più veloce che mi è venuta in mente per risolvere il problema è stata una piccola aggiunta a quel pezzo di codice:

(post_status=’publish’ AND (post_type=’post’ OR post_type=’xxx’ OR post_type=”))

(dove “xxx” è il nome del mio Custom Post Type)

Modifico, salvo, carico in in ftp, rigenero la sitemap e faccio un controllo: molto bene adesso le pagine ci sono tutte…

Mentre aspetto che il crawler ripassi ne approfitto e faccio un ricerca per capire se sono l’unico ad aver riscontrato questo “difetto” ed ovviamente ho trovato chi ha risolto meglio di me creando un plugin che estende l’originale di Arne Brachhold ed aggiunge automaticamente tutti i Custom Post Type pubblici. (escude quindi attachment, revision, ecc…).

Questo il link: GUAR Sitemap

Leggi l'orginale su http://maurizio.mavida.com
WordPress: XML Sitemap e Custom Post type was first posted on settembre 29, 2010 at 12:40 pm.

La mia Checklist prima di andare online

Maurizio Pelizzone — Mon, 20 Sep 2010 11:27:45 +0000

Leggi l'orginale su http://maurizio.mavida.com

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.

Preparazione profilo Google Analytics e condivisione accesso con email cliente
Configurazione script tracciamento sul sito e configurazione custom_var (Google Analytics for WordPress)
Preparazione sitemap (Google XML Sitemaps)
Registrazione Google WebMaster Tools e segnalazione sitemap
Registrazione Bing WebMaster Tools e segnalazione sitemap
Verifica file Robots.txt con escusione aree riserate (iRobots.txt)
Configurazione servizio di monitoraggio con segnalazione mail in caso di down (es Monastic)
Configurazione backup file e database (WordPress Backup / WordPress database backup)
Controllo funzionamento Form contatti
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…

Leggi l'orginale su http://maurizio.mavida.com
La mia Checklist prima di andare online was first posted on settembre 20, 2010 at 12:27 pm.

Strumenti e risorse per Google Analytics

Maurizio Pelizzone — Tue, 14 Sep 2010 17:19:06 +0000

Leggi l'orginale su http://maurizio.mavida.com

Dato che non si vive si solo WordPress per il sottoscritto è iniziato un periodo di studio e approfondimento su Google Analytics che con il tempo spero porterà alla certificazione.

Il motivo di questa decisione parte da questo assunto: “imparare a misurare ti porta a migliorare“. In pratica mi sono convinto che imparando a tracciare e poi a leggere il comportamento degli utenti è più facile migliorare le perfomance di un sito….

Nei prossimi giorni spero di riuscire a condividere i miei progressi ed i miei esperimenti; per il momento lascio una selezione di link presa dai miei segnalibri e che so già mi tornerà molto utile.

Sito ufficiale italiano: Punto di partenza per notizie, approfondimenti, video presentazioni, assistenza e formazione
Canale ufficiale su YouTube: Ci potete trovare molti video (in inglese) in cui vengono approfondite specifiche tematiche.
Blog ufficiale inglese: Io l’ho messo direttamente tra i miei feed. A volte pubblicato anche interessante howto
Documentazione per gli sviluppatori: Risorsa fondamentale ricca di esempi per capire il comportamento dello script di tracciamento e/o le api per l’esportazione dei dati.
Corso online per Individual Qualification (IQ): Materiale ed informazioni varie per prepararsi alla certificazione con “video – presentazioni” molto interessanti
Estensione Chrome: Utile per fare debug e capire cosa e come viene tracciata la pagina.
Plugin per WordPress: Potrei quasi dire “IL plugin per le statistiche”. Un Plugin veramente ben fatto che permette di usare le custom_variables per tracciare tag e categorie. Se poi ci server maggiore controllo mette a disposizione dei filtri per modificare al volo lo script
Snip-n-Tag – Plugin per Firefox: Un aiuto per creare url “corti” (vedi bit.ly e/o tinyurl) con il codice ga per tracciare le compagne
Goanalytics.info: il blog italiano verticale su Analitycs gestito da Marco Cilia
Web Analytics Experience: altra risorsa italiana che ho scoperto da poco ma che sembra interessante.

Leggi l'orginale su http://maurizio.mavida.com
Strumenti e risorse per Google Analytics was first posted on settembre 14, 2010 at 6:19 pm.

WordPress 3.0 @ Go!WebDesign Roma 2010

Maurizio Pelizzone — Mon, 14 Jun 2010 10:04:40 +0000

Leggi l'orginale su http://maurizio.mavida.com

Ecco che è passata più di una settimana ed io non ho neanche pubblicato le slide del mio speech.

Riassunto breve:

Sabato 5 Giugno ero a Roma a presentare le novità di WordPress 3.0 al Go!WebDesign, il workshop organizzato da Julius.

A parte il viaggio con un treno notturno che è stato un po’ devastante è stato tutto molto bello.

Roma alle 6.30 del mattino e Bellissima e fare colazione davanti all’altare della Patria illuminato dalle prime luci del sole è una cosa che penso mi ricorderò a lungo…

Tornando al workshop merita segnalazione il talk di Nicola (date un occhio almeno alle slide) e sicuramente di rilievo anche anche quelli di Federico e Robin

Per quanto mi riguarda, come vi dicevo, ho prepareto un intervendo su WordPress, facendo una panoramica delle sua prinicipali funzionalità (che ogni volta vedo che non tutti conoscono) e sulle nuovità della prossima 3.0.

E’ curioso vedere come ogni volta che si parla di oEmbed, Sticky Post (codex), Thumbnails image o Child Theme c’è chi mi chiede: “Ma queste cose sono delle novità della nuova versione?” (no, le abbiamo gratis da almeno 6 mesi…)

Poi si è parlato un po’ delle solite novità: il nuovo templare, il menu, custom post type, ecc…

Per il momento qui sotto trovate le mie slide (se avete domande usate i commenti) e forse nei prossimi giorni avremo anche il video….

Chiudo rigraziando Mirko per lo sbattone che si è fatto per intervistare un po’ tutti…

Leggi l'orginale su http://maurizio.mavida.com
WordPress 3.0 @ Go!WebDesign Roma 2010 was first posted on giugno 14, 2010 at 11:04 am.

12 Plugin per sviluppatori

Maurizio Pelizzone — Tue, 08 Jun 2010 21:22:51 +0000

Leggi l'orginale su http://maurizio.mavida.com

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.

Ovviamente prima di andare in produzione ricordatevi di eliminarli…

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

Leggi l'orginale su http://maurizio.mavida.com
12 Plugin per sviluppatori was first posted on giugno 8, 2010 at 10:22 pm.

imapsync: trasferire una casella imap

Maurizio Pelizzone — Sat, 01 May 2010 20:18:56 +0000

Leggi l'orginale su http://maurizio.mavida.com

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:

1	#apt-get install imapsync

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:

#imapsync –host1 {NomeServerUno} –user1 {NomeUtenteUno} –password1 {PasswordUno} –host2 {NomeServerDue} –user2 {NomeUtenteDue} –password {PasswordDue}

{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.

Leggi l'orginale su http://maurizio.mavida.com
imapsync: trasferire una casella imap was first posted on maggio 1, 2010 at 9:18 pm.

.:: Maurizio Pelizzone ::. » featured

WordPress e qualità: sistemi di cache manuali

Usare trackPageview asicrono su due account

WordPress: Alterare il layout durante un loop

the_permalink(); ?>" title=" the_title_attribute( ) ?>" rel="bookmark"> the_title(); ?>

WordPress è meglio di Drupal

WordPress: XML Sitemap e Custom Post type

La mia Checklist prima di andare online

Strumenti e risorse per Google Analytics

WordPress 3.0 @ Go!WebDesign Roma 2010

12 Plugin per sviluppatori

imapsync: trasferire una casella imap

the_permalink(); ?>" title=" the_title_attribute( ) ?>" rel="bookmark">
the_title(); ?>