Con la versione 5.0 di WordPress (ormai imminente) verrà probabilmente reso di default il nuovo editor Gutenberg. Personalmente, incuriosito, l’ho provato in anteprima, installando il relativo plugin, e devo dire che non sono rimasto affatto soddisfatto e prevedo notevoli problemi di adattamento per chi è abituato a utilizzare il comodo editor Tinymce.

In generale, confermo le critiche che sono state fatte nei vari blog che si occupano di WordPress. Il nuovo editor, basato sui blocchi, e dunque su un approccio completamente differente rispetto all’editor tradizionale, è caotico e scarsamente gestibile nelle dinamiche che gestiscono le sue funzionalità. Inoltre, non è ancora ben chiaro come dovranno essere gestiti i metabox, che seppure funzionano anche con il nuovo editor (non tutti a quanto pare), in alcuni casi creano effetti bizzarri nel layout.

A mio modesto avviso, il team di WordPress sta facendo un grossolano errore, nell’imporre Gutenberg come editor di default. Sarebbe stato più opportuno che il nuovo editor venisse proposto come un’alternativa all’editor tradizionale. La scelta avrebbe dovuto spettare all’utente finale: utilizzare Gutenberg oppure l’editor classico, supportandoli entrambi.

Ma il fatto stesso che WordPress 5.0 non sia ancora stato rilasciato, forse suggerisce che gli sviluppatori WordPress stiano prendendo tempo (in realtà già preso, visto che Gutenberg avrebbe dovuto essere rilasciato già da qualche mese) per cercare quanto meno di correggere i bug e le eventuali distorsioni e le scomodità legate al nuovo editor, anche se nelle discussioni relative al rilascio di WP 5, emerge inequivocabile la necessità di adattare WordPress all’imminente rilascio di PHP 7.3. Dunque è probabile che nell’immediatezza, verrà rilasciata una release intermedia (la 4.9.9), e forse a fine 2018 (tra novembre e dicembre) la major relase.

In ogni caso, da quanto emerge dalle discussioni negli ambienti di sviluppo WordPress, non sembra ci siano passi indietro rispetto all’implementazione di default di Gutenberg, anche perché esso rappresenterà un’occasione per fare nuovo business, attraverso i blocchi premium, implementabili per mezzo degli shortcode.

Comunque, non disperiamo. Per chi non volesse utilizzare il nuovo editor, c’è sempre la possibilità – tramite plugin – di utilizzare il vecchio e attuale editor TinyMCE. Il problema si pone alla fine solo per gli sviluppatori di temi e plugin, che dovranno fare i conti con la nuova architettura per sviluppare i loro script.

L’editor del tema in WordPress, per chi sviluppa, non è molto utile, seppure esistano diversi plugin che applicano un sistema IDE che permette l’evidenziazione della sintassi e dunque un facile intervento sul file relativo. Ma è chiaro, che inserire codice o correggerlo dall’editor, può creare qualche complicanza, qualora si facciano degli errori. E per chi non è esperto, l’uso errato dell’editor può bloccare il sito web.

Di più. E’ noto che l’editor del tema e dei plugin su WordPress può rappresentare un problema per la sicurezza. Infatti, lo scopo di un hacker è quello di usare gli editor per iniettare malaware o per fare blackhat SEO, ovvero per inserire link a risorse dannose per l’utente che le clicca. Questo avviene in un modo piuttosto semplice: il sito viene “bucato” con un attacco di forza bruta, e ottenuti i privilegi di amministratore, gli hacker iniettano – tramite l’editor del tema e dei plugin – i loro codici malevoli.

Questa è sicuramente una validissima ragione per disabilitarli. Dunque, non ci resta che procedere, e il lavoro è abbastanza semplice: questione di una manciata di secondi. Si apre il file wp-config.php, e si aggiunge questa linea di codice:

define( 'DISALLOW_FILE_EDIT', true );

A questo punto gli editor dovrebbero essere tutti disattivati. Nessuno potrà accedervi, nemmeno chi viola il vostro sito web. E in questo caso, per modificare i vostri temi e i vostri plugin, dovrete rivolgervi al buon vecchio FTP client, che è la cosa migliore da fare.

Nello sviluppo di uno script in php, compresi i plugin e i temi WordPress, un aspetto importante e direi fondamentale è la sanitizzazione, la validazione e l’escaping del codice creato. Queste attività, piuttosto noiose, sono fondamentali per scrivere codice sicuro, e dunque evitare – per quanto possibile – iniezione di codice malevolo nei nostri script, finalizzato a violare i dati contenuti nel sito web.

Diverse sono le tecniche di cracking che possono essere utilizzate per “bucare” uno script in php. In primo luogo, abbiamo i cosiddetti attacchi XSS. Da Wikipedia:

Il Cross-site scripting (XSS) è una vulnerabilità che affligge siti web dinamici che impiegano un insufficiente controllo dell’input nei form. Un XSS permette ad un Cracker di inserire o eseguire codice lato client al fine di attuare un insieme variegato di attacchi quali ad esempio: raccolta, manipolazione e reindirizzamento di informazioni riservate, visualizzazione e modifica di dati presenti sui server, alterazione del comportamento dinamico delle pagine web ecc.

Un altro tipo di attacco, piuttosto pericoloso, è il cosiddetto “sql injection”. Sempre da Wikipedia:

SQL injection è una tecnica di code injection, usata per attaccare applicazioni di gestione dati, con la quale vengono inserite delle stringhe di codice SQL malevole all’interno di campi di input in modo che queste ultime vengano poi eseguite (ad esempio per fare inviare il contenuto del database all’attaccante).^[1] L’SQL injection sfrutta le vulnerabilità di sicurezza del codice di un’applicazione, ad esempio quando l’input dell’utente non è correttamente filtrato da ‘caratteri di escape’ contenuti nelle stringhe SQL oppure non è fortemente tipizzato e viene eseguito inaspettatamente. L’SQL injection è più conosciuto come attacco per i siti web, ma è anche usato per attaccare qualsiasi tipo di database SQL.

Questo genere di attacchi, possono creare notevoli danni ai siti web, ecco perché è necessario, operare tutte le cautele del caso, anche se poi – è chiaro – non sempre queste sono sufficienti. Ciò perché i cracker trovano sempre modi nuovi per attaccare un sito web, e poi perché nello sviluppo può sempre sfuggire qualcosa, anche se ciò non dovrebbe mai accadere.

PHP metta a disposizione diverse funzioni per fare la sanitizzazione, la validazione e l’escaping dei dati. In particolare, per quanto riguarda il pericolo di SQL injection, è buona norma, oggi, per quanto riguarda l’uso di database Mysql, utilizzare una connessione PDO. Questo tipo di connessione, riduce fortemente, fino a eliminare quasi del tutto, il pericolo di sql injection. Quasi del tutto, perché il sistema di connessione tramite PDO comunque potrebbe venire aggirato, come viene spiegato qui.

Ciò detto, per una questione di sicurezza, è sempre opportuno sanitizzare e validare i dati prima di inserirli nel database. Soprattutto quando questi dati vengono inseriti dagli utenti che navigano sul sito web. In particolare mi riferisco ai dati ottenuti tramite le variabili $_GET, $_POST, $_REQUEST. Bisogna sempre considerare i dati inviati tramite queste variabili, come unsafe, cioè come non sicuri.

PHP per la sanitizzazione e la validazione dei dati, ci viene in aiuto con le funzioni filter_input e filter_var, che dispongono di diversi flag, utili per filtrarli e validarli. Per un elenco esaustivo, consultare la pagina dei type of filters.

L’escaping dei dati, è altresì importante, e si fa sull’output, e cioè sui dati ottenuti attraverso una query e stampati a video. La funzione più utilizzata per fare l’escaping dell’output, sono htmlspecialchars e urlencode che codificano una serie di caratteri speciali, i quali possono essere sfruttati per le varie tecniche di cracking  dei siti web (e in particolare le azioni xss).

Validazione, sanitizzazione ed escaping su WordPress

WordPress, offre una serie di funzioni per le attività di validazione, sanitizzazione ed escaping dell’output. E’ inutile dire che gli sviluppatori WordPress consigliano altamente di utilizzarli quando si progettano temi e plugin. Qualora poi si volessero passare delle variabili tramite un form, WordPress mette a disposizione pure un sistema di validazione della pagina che limita (ma potrebbe non impedire) quelle tecniche malevoli che sfruttano i form per creare, per esempio, azioni xss.

Infine, al di là degli accorgimenti tecnici che possono essere utilizzati in fase di sviluppo di un codice php e che rispondono, notoriamente, alle regole di buona pratica, è necessario comunque ricordare che è sempre opportuno che il gestore del sito web provveda periodicamente a fare un backup completo del proprio sito, ciò per evitare le conseguenze immediate di un’eventuale violazione, quali ad esempio la perdita definitiva dei dati (articoli, pagine, utenti ecc.).

WordPress, per le proprie necessità, e per tutte le implementazioni e customizzazioni, utilizza delle potenti API. Tra queste spiccano in particolar modo, i filtri. I filtri ci permettono di fare numerose personalizzazioni del nostro tema e dei nostri plugin. Possiamo usare i filtri ufficiali, implementati nel core di WordPress, oppure, possiamo crearne di nuovi, quando questi si rendono necessari. Chiaramente, quest’ultima opzione è solitamente utilizzata dagli sviluppatori di plugin, che in questo modo permettono ad altri sviluppatori o ai semplici utenti che usano il plugin di estenderlo o modificarne alcune impostazioni, in ragione delle personali esigenze.

In un mio precedente articolo, ho spiegato come utilizzare i filtri ufficiali. Qui spiego brevemente come crearne uno. La funzione “magica” è apply_filters(), la quale ci permette di filtrare i dati che intendiamo poi visualizzare a video o inserire nel database. Ecco un semplice esempio:

function foo() {
      $foo = 'foo';
      $foo = apply_filters( 'mio-dato', $foo );
      return $foo;
}

// per filtrare foo e aggiungere il valore bar all'output, 
// non ci resta che filtrarlo:

function bar( $foo ) {
      $foo .= ' bar';
      return $foo;
}
add_filter( 'mio-dato', 'bar' );

// il risultato sarà
(string) "foo bar"

Chiaramente, qualora i valori da passare siano più di uno, dovete poi indicare il numero di valori che passate, così come viene illustrato nella pagina di sviluppo WordPress che si occupa di questa funzione.

I filtri dunque sono un potente strumento che potete utilizzare soprattutto quando sviluppate plugin e temi che volete si prestino a diverse personalizzazioni. Il difetto di questo sistema, è che si presta a pericolosi infiltrazioni di codice malevolo qualora i dati passati con i filtri non vengano correttamente sanitizzati e puliti.

Con l’aggiornamento all’ultime versioni del noto plugin Tinymce Advanced (che utilizzo sui miei blog), è scomparso il pulsante “cite”, da me molto usato quando devo riportare brevi citazioni. La differenza con il blockquote è evidente: con quest’ultimo si riportano brani più lunghi in un paragrafo a parte; con il <cite>, brani più brevi, nella stessa linea del testo.

Dunque dovevo trovare una soluzione che potesse colmare la lacuna (si spera temporanea). Quanto meno finché non troverò una soluzione più “pulita” o gli sviluppatori di Tinymce Advanced non decidano di reinserire nel plugin i pulsanti xhtml.

Ancora una volta, la soluzione è piuttosto semplice. Non si deve far altro che incollare il seguente codice nel file functions.php:

/* add custom cite button */
add_action('init', 'add_button');  
function add_button() {  
   if ( current_user_can('edit_posts') &&  current_user_can('edit_pages') )  
   {  
     add_filter('mce_external_plugins', 'add_plugin');  
     add_filter('mce_buttons_3', 'register_button');  
   }  
}  
function register_button($buttons) {  
   array_push($buttons, "cite");  
   return $buttons;  
}  
function add_plugin($plugin_array) {  
   $plugin_array['cite'] = get_template_directory_uri() .'/js/cite_tinymce.js';
   return $plugin_array;  
}

All’interno della cartella del tema dove avete i vostri file .js (file che contengono javascript), dovete poi inserire un nuovo file js, che io ho chiamato cite_tiny_mce.js, ma che ognuno può chiamare come meglio crede, anche perché la funzione può essere utilizzata per l’inserimento di qualsiasi pulsante all’interno dell’editor. Nel file .js, dovete inserire questo codice javascript:

(function() {
     /* Register the buttons */
     tinymce.create('tinymce.plugins.cite', {
          init : function(ed, url) {
               /**
               * Adds HTML tag to selected content
               */
               ed.addButton( 'cite', {
                    title : 'Add cite',
                    image : '../wp-content/themes/dmtheme/images/cite.png',
                    cmd: 'cite_cmd'
               });
               ed.addCommand( 'cite_cmd', function() {
                    var selected_text = ed.selection.getContent();
                    var return_text = '';
                    return_text = '<cite>' + selected_text + '</cite>';
                    ed.execCommand('mceInsertContent', 0, return_text);
               });
          }/*,
           createControl : function(n, cm) {
               return null;
          }, */
     });
     /* Start the buttons */
     tinymce.PluginManager.add( 'cite', tinymce.plugins.cite );
})();

Ovviamente, all’indirizzo relativo all’immagine, inserite un’immagine che possa meglio rappresentare il vostro pulsante. Nel caso di “cite” io ho creato un’immagine con i sergenti alti. Niente di trascendentale. L’importante è che faccia il suo sporco lavoro:

Quando condividiamo i nostri articoli su Facebook, lo script che si occupa della condivisione estrae dall’articolo l’incipit, e cioè la parte iniziale dell’articolo. Tuttavia, non sempre questo è utile per attirare lettori. Anzi, in un certo senso, dall’incipit non è molto agevole (a parte il titolo) capire esattamente quale sarà il tenore del contenuto. Ecco che allora abbiamo la necessità di “personalizzare” l’estratto che verrà pubblicato su Facebook.

Già il noto social network ci viene incontro, dandoci la possibilità di modificare il riassunto al momento della condivisione “diretta” sulla pagina o sul profilo. Tuttavia è chiaro che questo non è un sistema agevole né definitivo, perché coinvolge solo le condivisioni “figlie” e cioè quelle che discendono dalla nostra. Mentre gli utenti che condividono l’articolo cliccando sul pulsante “Mi Piace” o “Condividi” presenti sul sito, avranno come excerpt le prime parole del nostro contenuto o addirittura nulla.

Per ovviare, è necessario che l’autore possa personalizzare questo contenuto prima della pubblicazione (o anche dopo). Per questo, ci vengono in aiuto i meta valori dei campi “personalizzati” (per gli utenti più esperti, sarà invece possibile creare meta-box ad hoc).

Prima di tutto è necessario mettere mano al tema, nella sezione dedicata agli opengraph (solitamente posizionati nell’header). Se non avete gli opengraph, qui la documentazione. Quello che dovete sapere è che bisogna inserirli tra i tag head nell’header del vostro blog o sito. Dando per scontato che abbiate gli opengraph nel vostro template, dovete cercare questa riga:

<meta property="og:description" content="" />

Se questa riga è vuota, Facebook potrebbe valorizzare il campo con l’incipit del vostro articolo. Noi vogliamo fare in modo che utilizzi invece un contenuto personalizzato. Per farlo, sfrutteremo i campi personalizzati (attivabili da “Impostazioni Schermata”). Dovremo creare una chiave, che chiameremo “description”. Dopo di che alla chiave “description”, sul campo di destra, assegneremo un valore, che sarà il contenuto personalizzato. Esempio: “Ho scritto questo articolo per vedere se verrà condiviso su Facebook. Nel caso non lo fosse, allora vuol dire che ne scriverò uno nuovo“. Come da questo screenshot:

Ma non è finita qui. Una volta che clicchiamo sul pulsante “Aggiungi campo personalizzato” e salviamo l’articolo, dovremo fare in modo che il contenuto (il valore) venga stampato all’interno di <meta property=”og:description” content=”” />. Affinché ciò avvenga dobbiamo richiamare il meta-valore sul nostro tema, e qui ci viene in aiuto WordPress con la funzione get_post_meta. Ma questa funzione è stata studiata per funzionare all’interno di un loop WordPress. Per restituire un valore fuori dal loop, dobbiamo “intercettare” l’ID del post (richiesto), usando il valore globale $post. Ecco dunque il codice completo:

<?php global $post; 
$opengraph_content = get_post_meta($post->ID, 'description', true); ?>

A questo punto il nostro obiettivo è quasi raggiunto:

<meta property="og:description" content="<?php echo $opengraph_content; ?>" />

Naturalmente potete fare in modo che là dove non dovesse essere impostato alcun valore in “description”, venga restituito certamente l’incipit del post, magari con un’altra funzione WordPress che assolva questo compito. In tal caso è necessario creare una funzione php più complessa che venga richiamata in content.

In un altro articolo ho spiegato come creare delle tassonomie personalizzate. Ora è interessante spiegare come possiamo creare un custom post type, cioè una tipologia di post personalizzata, diversa da quella standard (post) e dalle pagine statiche (page).

Il tutto avviene con un semplice snippet da inserire nel file functions.php. Ecco:

add_action( 'init', 'custom_post_musica' );
function custom_post_musica() {
    register_post_type( 'musica',
        array(
            'labels' => array(
                'name' => __( 'Musica' ),
                'singular_name' => __( 'Musica' )
            ),
            'public' => true,
            'has_archive' => true,
            'supports' => array('title', 'editor', 'excerpt')
        )
    );
}

Abbiamo creato un custom post type chiamato “musica”. Nel menu della pagina amministrazione verrà visualizzato accanto a “Pagine”. Cliccandoci, avremo una sezione simile a quella dei post e delle pagine, dove possiamo creare articoli specifici dedicati – come nell’esempio – alla musica (ma potete sbizzarrirvi).

Per richiamare i custom post type nel tema, è necessaria un’altra funzione, molto simile a quella per richiamare i post e le pagine, con una differenza: in questo caso si utilizza la classe WP_Query:

<?php $args = array( 
    'post_type' => 'musica', 
    'posts_per_page' => 10 
);
    $loop = new WP_Query( $args );
    while ( $loop->have_posts() ) : $loop->the_post(); ?>
        <?php the_title(); ?>
        <div class="entry-content">
        <?php the_content();
        </div>
    <?php endwhile; wp_reset_postdata; ?>

Questo codice può essere inserito in qualsiasi punto del tema. Tuttavia, se volete creare dei template specifici per il custom post type “musica”, potete creare dei template pagina, assegnando il nome del custom post type: single-musica.php e archive-musica.php.

In WordPress, le tassonomie personalizzate sono estremamente utili quando dobbiamo fare delle particolari classificazioni, soprattutto se usiamo i custom post type, e cioè i tipi di post personalizzati.

La domanda a questo punto è: come posso creare delle tassonomie personalizzate per WordPress? Apparentemente l’idea di creare delle tassonomie personalizzate sembra qualcosa che va oltre le possibilità di uno sviluppatore alle prime armi. Ma la verità, fortunatamente, è un’altra. E’ sufficiente incollare nel file functions.php il seguente codice, ovviamente personalizzandolo a seconda delle proprie esigenze:

function create_my_taxonomy() {
                    
register_taxonomy('Genere', 'musica', array(
   'hierarchical' => true /*visualizza come le categorie*/, 'label' => 'Genere',
   'query_var' => true, 'rewrite' => true));

register_taxonomy('Artista', 'musica', array(
   'hierarchical' => false /*visualizza come i tag*/, 'label' => 'Artista',
   'query_var' => true, 'rewrite' => true));
}
add_action('init', 'create_my_taxonomy', 0);

La prima funzione crea una tassonomia simile a quella delle categorie e cioè gerarchizzata (categoria -> categoria figlia -> categoria figlia della categoria figlia ecc. ecc.). La seconda funzione invece crea una tassonomia simile a quella delle etichette (i tags). Entrambe possono essere utili soprattutto nelle recensioni di musica e libri (si usano le tassonomie gerarchizzate per i generi musicali, mentre per esempio le tassonomie non gerarchizzate per gli artisti).

Volevo segnalarvi un ottimo plugin jQuery che permette di implementare nel vostro sito web una slideshow con accordion. Si tratta di Slidorion.

Il plugin è facilmente installabile. Prima di tutto è necessario avere a disposizione le librerie jQuery. Successivamente, dovete richiamare nel vostro tema quelle specifiche di Slidorion (per WordPress, dovete usare l’estensione wp_enqueue_script):

<script src="URL-VOSTRO-TEMA/js/jquery.easing.js"></script>
<script src="URL-VOSTRO-TEMA/js/jquery.slidorion.min.js"></script>

Fatto questo dovete richiamare il css necessario per la visualizzazione corretta del plugin (per WordPress idem come sopra). Naturalmente potete modificarlo per armonizzarlo con lo stile del vostro blog:

<link href="URL-VOSTRO-TEMA/slidorion.css" rel="stylesheet" />

A questo punto, la struttura html che dovrà riprodurre lo slide:

<div id="slidorion">
	<div id="slider">
		<div></div>
		<div></div>
		<div></div>
	</div>

	<div id="accordion">
		<div>New Features</div>
		<div>
			<!-- content -->
		</div>
		<div>A Simple Image</div>
		<div>
			<!-- content -->
		</div>
		<div>Background Image</div>
		<div>
			<!-- content -->
		</div>
	</div>
</div>

Infine la funzione base dello script, da inserire appena sotto il richiamo delle librerie di slidorion:

$(document).ready(function(){
	$('#slidorion').slidorion();
});

Naturalmente il plugin prevede una serie di funzionalità che potete implementare con estrema facilità, tra cui la velocità dello slide, lo stop con il passaggio del mouse e altre interessanti features che potete sperimentare sul sito del plugin o nella demo.

Download | Demo | Autore

Le dimensioni nei fogli di stile normalmente si misurano in px, em o percentuale. Tra le tre la più utilizzata è indubbiamente l’unità di misura in px. Tuttavia, onde creare layout elastici, è interessante l’utilizzo delle percentuali e degli em. Si parla in questo caso di unità di misure relative, perché le unità anzidette sono calcolate in base alla dimensione del testo dell’elemento genitore.  Faccio un esempio: se ho un font base di 12px nel body, questo font viene ereditato così com’è dal contenitore “figlio” e dal contenitore “nipote”:

<html>
<body style="font-size:12px">
    Questo testo avrà la dimensione di 12px;
    <div class="figlio">
       Questo testo avrà la dimensione di 12px
       <div class="nipote">
          Questo testo avrà la dimensione di 12px
       </div>
    </div>
</body>
</html>

Supponiamo però che per un motivo o per l’altro nel contenitore figlio io voglia fissare una dimensione maggiore. Supponiamo dunque di volere un font pari a 18px, espresso però in em (in tal caso pari a 1.5em):

<html>
<body style="font-size:12px">
    Questo testo avrà la dimensione di 12px;
    <div class="figlio" style="font-size: 1.5em;">
       Questo testo avrà la dimensione di 12px * 1.5em = 18px
       <div class="nipote">
         Questo test avrà la dimensione di 1.5em = 18px;
       </div>
    </div>
</body>
</html>

In questo caso, notate che, rispetto all’esempio in px, il contenitore “nipote” eredita la dimensione del font del contenitore “figlio” e non del body. Ora supponiamo io voglia che il contenitore nipote abbia una dimensione di 10px. In tal caso, il punto di partenza non saranno più i 12px del body, bensì i 18px del contenitore “figlio”.

<html>
<body style="font-size:12px">
    Questo testo avrà la dimensione di 12px;
    <div class="figlio" style="font-size: 1.5em;">
       Questo testo avrà la dimensione di 12px * 1.5em = 18px
       <div class="nipote" style="font-size: .55em">
         Questo test avrà la dimensione di 10px / (12px * 1.5em) = .55em = 10px
       </div>
    </div>
</body>
<html>

Con le unità di misura in rem (root em), l’ereditarietà del contenitore padre viene meno e i contenitori figli calcolano le dimensioni relative sulla base della misura determinata nel contenitore di root (html). Conseguentemente:

<html style="font-size:12px;">
<body>
    Questo testo avrà la dimensione di 12px;
    <div class="figlio" style="font-size: 1.5rem;">
       Questo testo avrà la dimensione di 12px * 1.5rem = 18px
       <div class="nipote" style="font-size: .83rem;">
         Questo test avrà la dimensione di 10px / 12px = .83rem = 10px
       </div>
    </div>
</body>
<html>

Il che evita tutta una serie di problemi nello sviluppo dei layout con le dimensioni relative. In particolar modo con Internet Explorer 9.

La compatibilità dell’unità di misura in rem, introdotta recentemente, con i CSS3, è abbastanza buona. In particolare è presente in tutti i browser moderni.