WordPress 4.3 beta1

Ieri è stata rilasciata la prima beta del nuovo ciclo di sviluppo relativo a WordPress 4.3

Come al solito parecchie le novità:

  1. I menu posso essere gestiti anche tramite il customizer (se il template lo supporta). Ormai la tendenza è qualla di rendere modificabile ogni aspetto direttamente dell’anteprima del template. Per chi non avesse ancora avuto modo di provarlo anche lato codice e di itegrarlo nel proprio template posso dire che è molto semplice.
  2. Gestione integrata da admin della favicon
    Dal menu “impostazioni” e poi “generale” dopo titolo e motto troviamo la “site icon“.
    Questi i 3 link attualmente gestiti di default dall’hook generato con wp_head

    <link rel="icon" href="favicon-32x32.jpg" sizes="32x32" />
    <link rel="apple-touch-icon-precomposed" href="favicon-180x180.jpg">
    <meta name="msapplication-TileImage" content="favicon-270x270.jpg">

    wordpress-favicon

  3. Un grosso miglioramento nella gestione e generazione delle password utente (che non verranno più inviate via mail).
    Per chi vorrà continuare ad usare delle non-password come giulia-82, matrix o 123password dovrà anche spuntare un checkbox prima di poter salvare.wordpress-password-generator
  4. Aggiunto supporto all’editor visuale per alcune sintassi tipiche del Markdown
    Tutte cose che si potevano fare anche attraverso i pulsanti presenti sopra l’editor ma per chi è abituato ad usare Markdown potrà beneficiarne sopratutto in termini di velocità.
    Le sintassi supportate sono:

    • “## nome titolo” per gli h2 (da h2 ad h6)
    • “> testo indentato” per generare un blockquote
    • “- elenco non numero” per generare un tag ul
    • “1) elenco ordinato” per generare un tag ol

    (provatelo che è più semplice a farlo che a spiegarlo)
    wordpress-tinymce-markdown

  5. Migliorato il comportamento responsivo nelle pagine di elenco post (tutte quelle gestite tramite la classe wp_list_table).
    Per chi usa tabblet, smartphone e/o device a bassa risoluzione sarà un miglioramento sicuramente molto comodo in termini di usabilità.wordpress-responsive-admin-table

Anche per gli sviluppatori ci sono un po’ di cose tra cui la suddivisione dei termini nel caso siano presenti in più tassonomie e l’introduzione di “singular.php” nella gestione della gerarchia delle pagine nel caso non siano preseti “post.php” e “page.php”

Se siete in zona ne parliamo dal vito il 14 luglio al WordPress Meetup Torino

 

 

 

 

Le performance di WordPress con PHP7

Lo scorso weekend ero a Verona per il PHPDay che come ogni anno si dimostra un evento di grandissimo interesse e con un’impeccabile organizzazione.

In uno dei primo talk Davey Shafik ha presentato le novità di PHP7 con “What to Expect When You’re Expecting: PHP 7” e tra le cose più importanti sì è perlato di performance.

“Performance, Performance, Performance” deve essere stato il mantra durante tutto il ciclo si sviluppo e dai benchmark sembra che i risultati siano notevoli.

performance-php7

Passiamo adesso al nostro caro WordPress:

wordpress-php7

Possiamo vedere chiaramente che dai questi test l’impatto prestazionale sia veramente incredibile. Stiamo parlando di un miglioramento con un fattore 2.4x che in percentuale diventa 59% (cinquantanovepercento).

Dopo aver visto questa slide io rimango folgorato quasi come S. Paolo sulla via di Damasco e continuo ad interrogarmi su quali siano gli elementi responsabili di questo grandissimo miglioramento.

La risposta arriva qualche talk dopo da Patric Allaert che con il suo “PHP Datastructures and the impact of PHP 7 on them” toglie i miei dubbi.

php7-perfomace-array

Facendo WordPress un grandissimo uso di array ecco che avendone ottimizzato la gestione sia nella creazione che nella lettura ne abbiamo un beneficio enorme.

Teoricamente il rilascio è previsto per Ottobre 2015 e quindi entro la fine di questo anno potremmo valutare un upgrade dei nostri server e/o chiedere ai nostri provider come poter beneficiare di questa nuova versione.

Per chi non l’avesse ancora vista qui l’infografica preparata da Zend: https://pages.zend.com/ty-infographic.html

Cose da approfondire per il 2013

 

 

Buon 2013 a tutti…

Sulla traccia di questo post faccio anche io una piccola (e velocissima) lista delle cose che in questo 2012 ho iniziato ad usare (alcune in maniera molto superficiale) ma che mi piacerebbe approfondire nei prossimi mesi ed usare nel maggior numero di progetti.

  1. Symfony
    Di questo framework se ne è parlato tanto ed anche se ne sono nati altri forse altrattando validi per quello che mi riguarda è il punto di riferimento. Con alcune delle sue librerie ho già avuto modo di approfondire ma non ho ancora affrontato progetti complessi.
  2. Composer e GitHub
    In questo caso il proposto e di rilasciare alcuni progettini relativi a WordPress su GitHub usando Composer per le dipendenze aggiungendo un po’ di documentazione per renderli usabili anche da altri.
  3. Bootstap
    Tra i framework responsivi ho scelto questo. Usato già per qualche sito vorrei renderlo uno standard in tutti i futuri progetti.
  4. NodeJs
    Questa invece è una di quelle cose che vorrei provare ad usare ma non è ancora capitato il progetto giusto.

Oltre a questi grossi nomi ci sono anche alune librerie Javascipt di cui da tempo ho salvato il link tra i miei segnalibri (e di cui in parte vi avevo già scritto) ma  che sono rimaste tra l’elenco delle “cose interessanti da vedere”

  1. Backbonejs Una sorta di MVC per Js
  2. Underscorejs Una libreria di supporto a Backbone e Jquery
  3. Chosen un piccola libreiria per rednere le select più carine (di cui vi lascio anche il link per un’utile implementazione con l’admin di WordPress)
  4. D3 Un strumento per generare grafici (anche se detto in questo modo è quasi riduttivo)
  5. Ace Editor si tratta dell’editor usato da Github per le gist. Fa Syntax highlighting, indentazione automatica del codice, gestisce il drag and drop ed un sacco di altre cose.
  6. jQuery Gantt questo invece vi può servire se avete bisogno di generare dei Gantt.

Come sempre se avete progetti interessanti da suggerire e segnarare siete i benvenuti.

WordPress Hardening [wordcamp bologna 2012]

E per chi se lo è perso ecco le slide di sabato scorso al WordCamp Bologa dove si è parlato di WordPress e sicurezza.

In breve si tratta di qualche semplice spunto per rendere più difficile l’utilizzo di un qualsiasi exploit che è possibile mettere in pratica senza l’installazione di plugins.
Questa è una versione aggiornata e migliorata rispetto a quella presentata il giugno scorso.

… e se le slide non vi bastano prossimamente saranno anche pubblicati i video dei singoli interventi.

update: qui il link per scaricare il file .htaccess di cui parlo nelle slide

 

 

CloudFlare: una CDN facile (e gratis)

Argomento un po’ complesso per cui preferisco partire con la definizione di CDN:

Le Content Delivery Network (CDN, Rete per la consegna di contenuti) … sono un sistema di computer collegati in rete attraverso Internet che collaborano in maniera trasparente, sotto forma di sistema distribuito, per distribuire contenuti agli utenti finali.

L’obiettivo di una CDN è di instradare una richiesta di contenuto sul nodo che viene individuato come ottimale. Se ottimizzate per le prestazioni, il nodo ottimale è quello che può soddisfare la richiesta nel minor tempo possibile: si può determinare per esempio scegliendo quello geograficamente o topograficamente (nel contesto di rete, minor numero di hops o minor ping) più vicino alla locazione del richiedente, oppure quello con un minor carico di lavoro (in inglese, load average).

Detto in modo più concreto si tratta di un sistema per ottimizzare e risparmiare carico server facendo in modo che alcuni contenuti (es. le immagini e/o i file statici come js e css) vengano erogati da server differenti ottimizzando la distribuzione a livello geografico in modo che sia il server più vicino a noi ad occuparsi del trasferimento.

Mi sono chiesto più volte in quale modo la nostra infrastuttura potesse beneficiare di questo tecnologia ma guardando le specifiche di Akamai e/o Amazon (che sono forse tra le più importanti realtà in questo settore) mi sono reso conto che i prezzi per la gestione di piccoli siti sono abbastanza proibitivi.

Poi, come sempre succede in queste cose, “la figlia del contadino” mi ha parlato di CloudFlare e del suo piano gratuito.

Ho deciso quindi di provare l’integrazione su questa pagine limitando però l’uso alle immagini e ai file javascript e css.
Questo, in breve, quello che ho fatto.

  1. Comprato un nuovo dominio “mavidacdn.in” su whois.com (in offerti in questi giorni a 3.88 dollari).
  2. Ho girato i name server sui server di Cloudflare
  3. Impostato un nuovo sottominio maurizio.mavida.com in modo che punti sul mio ip
  4. Configurato Apache per indirizzare correttamente. (sia maurizio.mavida.com che static puntano adesso allo stesso sito)
  5. Scritto un microplugin per fare in modo che l’indirizzo delle immagini pubblicare su queste pagine punti sul sottodominio CDN.
  6. Modificato nella pagina nelle impostazioni dei media il “Percorso URL completa ai file” con il sottodominio configurato su CloudFlare (http://maurizio.mavida.com/wp-content/uploads)

In questo modo CloudFlare oltre a fare da CDN svolge anche un lavoro come Reverse Proxy facendo cache dei contenuti. Quando viene chiesta un’immagine, o un file javascript/css CloudFlare verifica se è già nella sua cache e solo nel caso non lo sia la chiede al mio server. I benefici nel mio caso sono molto limitati in quanto il traffico generato è relativamente piccolo ma in situazioni più complesse una soluzione come questa potrebbe ridurre notevolemente il traffico.

Questo è il risparmio di banda (e di richieste) ottenuto in 5 giorni di utilizzo:

Adesso qualche dettaglio tecnico:
Qui sotto potete vedere il modo in cui vado ad effettuare la sostituzione dei link alle immagini che viene usata su filtri: ‘the_content’, ‘post_thumbnail_html’ e ‘widget_text’.


function CloudFlareImageReplace ( $content ) {

$pattern="/(" .$this->blog_url . ")(\/wp-content\/)(.*)(png|gif|jpg)/";
$replacement = $this->cf_cdnurl. "$2$3$4";

return preg_replace($pattern, $replacement,$content );

}

Mentre questa quella per js e css che viene attiva dal filtro su “script_loader_src”.

function CloudFlareScriptReplace ( $src ) {

$pattern="/(" . $this->blog_url . ")(\/wp-content\/)(.*)(js|css)/";
$replacement = $this->CloudFlareUrl . "$2$3$4";

// remove Query Strings From Static Resources
$src_parts = explode('?', $src);
return preg_replace($pattern, $replacement, $src_parts[0] );

}

Su GitHub potete trovare il sorgente versione completa (ancora in versione beta) ma se volte installarlo potete usare quella che ho pubblicato sul codex: http://wordpress.org/extend/plugins/cloudflare-url-replacement/.

Anche in quato caso sono graditi consigli e suggerimenti.


image credits: Derek Heisler

Estendere il server XML-RPC di WordPress

Leggere, scrivere e/o modificare i contenuti su WordPress non sempre può essere fatto da un’interfaccia di amministrazione (sia questa web, mobile o app). Ci possono essere esigenze in cui è necessario automatizzare alcuni processi appoggiandosi a strumenti esterni.

WordPress ci viene incontro con “una cosa” nota come XML-RPC.

 

In pratica si tratta di un componente che ci permette di dialogare secondo un protocollo standard attraverso internet. In questo modo un sito e/o applicazione esterna potrebbe pilotare la nostra installazione facendogli fare qualsiasi cosa.

In realtà “qualsiasi cosa” non è ancora prevista ma dalla nuova versione 3.4 ne saranno aggiunte parecchie. Ricordatevi solo di abilitarlo che di default è disattivato.

Il titolo di questo articolo però è “Estendere il server XML-RPC” non “Usare il server XML-RPC” quindi iniziamo a vedere cosa ci dice il codex: XML-RPC Extending

Like the rest of WordPress, the XML-RPC API contains numerous hooks to customize or extend its behavior.

Nel caso volessimo estendere il servizio XML-RPC attraverso un plugin in grado di restituire gli ultimi post non dovremo quindi fare altro che aggiugnere una roba come questa:

// aggiungo il fitro
add_filter( 'xmlrpc_methods', 'mycustom_methods');

// dichiaro i nuovi metodi
function mycustom_methods( $methods ) {
    $methods['getlastposts'] = 'get_LastPosts';
    return $methods;   
}

/*
 * restisuisco gli ultimi n. post in formato serializzato
 */
function get_LastPosts( $params ) {

  $args =  $params[0]
  $defaults = array(
	'numberposts' => 5, 
	'post_type' => 'post', 	
        'post_status'     => 'publish' 		
	);

  $args = wp_parse_args( $args, $defaults );			
  $posts = get_posts( $args );

  // restituisco l'oggetto serializzato
  return serialize($posts); 
}

Questo invece un esempio di come poter usare il vostro “nuovo” metodo usando il client offerto dalla libreria Zend

 $client = new Zend_XmlRpc_Client('http://tuosito.com/xmlrpc.php');
 $response = $client->call('getlastposts');
 $posts = deserialize($response)

 //con passaggio di parametri
 $client = new Zend_XmlRpc_Client('http://tuosito.com/xmlrpc.php');

 $args = array(
	'numberposts' => 3, 
	'post_type' => 'page'
	);

 $response = $client->call('getlastposts' , array( $args));
 $posts = deserialize($response)

Le cose nella pratica non sono così semplici e potrebbe servire un sistema di autenticazione.
Poi dato che spesso parlo di performance male non farebbe un piccolo sistema di cache.

Ecco quindi una nuova versione di “get_LastPosts” che accetta come parametri $blog_id, $username, $password e poi array con gli argomenti necessari a getposts.

function get_LastPosts( $params ) {

  $blog_id  =  $params[0]
  $username =  $params[1]
  $password =  $params[2]

  $args     =  $params[3]

  $defaults = array(
	'numberposts' => 5, 
	'post_type' => 'post', 	
        'post_status'     => 'publish' 		
	);

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

  if ( !$user = $this->login($username, $password) ) {
     // user o password non validi 
     return false;

  } else {

  // creo una chiave univoca per la cache
  $cache_key = "_xmlrpc_" . $username. md5( $numberposts . $post_type);

  $posts = get_transient( $cache_key );

  if (false === $posts) {
     $posts = get_posts( $args );
     set_transient( $cache_key , $posts, 60*60*4 );
  }

  // restituisco l'oggetto serializzato, compresso, ed in base64
  // per ripristinarlo: unserialize(gzuncompress(base64_decode($posts))); 
  return base64_encode(gzcompress(serialize($posts))); 
 }

}

Bene, adesso potete fare un po’ di prove e se nel fare copia e incolla ho sbagliato qualche cosa ditemlo che lo correggo.

WordPress e qualità: sistemi di cache manuali

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.

Continue reading “WordPress e qualità: sistemi di cache manuali”

Usare trackPageview asicrono su due account

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:


_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:

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…

WordPress: Alterare il layout durante un loop

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.

Continue reading “WordPress: Alterare il layout durante un loop”

WordPress è meglio di Drupal

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

WordPress: XML Sitemap e Custom Post type

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

La mia Checklist prima di andare online

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

Checklist: cosa fare prima della pubblicazione di un sito

Se pensate ci siano altre cose da aggiungere fatemelo sapere…