Scopri il nuovo WordPress 5.1

Dopo il tanto atteso (da alcuni), temuto (da altri) aggiornamento di dicembre scorso alla major release 5.0 di WordPress, che ha portato con sé in dote il tanto discusso editor a blocchi Gutenberg, ecco un nuovo aggiornamento in casa WordPress.
La nuova release di WordPress, versione 5.1, come ormai da sempre prende il suo nome in codice dal mondo del jazz ed in questo caso “Betty”, da Betty Carter, cantante jazz per l’appunto.
- Leggi l'articolo, ti bastano solo 1 minuto, 18 secondi
Sei di fretta? Scarica il PDF e consultalo quando vuoi!
Sommario
Panoramica
Scopo dichiarato della nuova versione di WordPress è procedere nella direzione ormai ben delineata da Gutenberg: infatti, i principali miglioramenti riguardano le prestazioni dell’editor a blocchi, ma non solo. WordPress 5.1 introduce nuove interessanti funzioni per rendere il CMS più sicuro e più veloce, con particolare interesse all’usabilità di queste funzioni da parte di tutti.
Site Health: monitora la salute del tuo sito
Ne è una prova la prima nuova funzionalità introdotta da WordPress 5.1: Site Health.

Site Health non è altro che un sistema di monitoraggio che avvisa gli amministratori del sito in caso di utilizzo di versioni PHP obsolete (attualmente, vengono segnalate versioni precedenti alla 5.6), esortando ad aggiornare ad una release più recente, per prevenire malfunzionamenti, vulnerabilità, cattive performance ed incompatibilità.
Per chi necessita di maggiori informazioni, WordPress ha messo a disposizione una pagina dedicata che spiega i motivi per cui conviene aggiornare la propria versione di PHP e come prepararsi all’aggiornamento:
Ma non finisce di certo qui! Il controllo effettuato da Site Health è di fatto esteso anche ai plugins, colonna portante di WordPress: ad ogni installazione di un nuovo plugin, Site Health controllerà la versione PHP richiesta dal plugin ed in caso di incompatibilità, ne bloccherà l’installazione.
Non male direi, soprattutto per gli utenti finali che hanno meno dimestichezza con codici e programmazione.
Protezione dai Fatal error
Sei pronto a dire addio alla famigerata “Schermata bianca della morte” (WSOD) di WordPress? Si, tutti l’hanno vista almeno una volta, l’odiosa pagina bianca senza alcuna informazione, visualizzata quando si verifica un errore grave!
Con Site Health WordPress è in grado non solo di riconoscere un errore fatale, ma persino quale tema o plugin lo stanno causando. In questo modo, quando si accede al backend del sito, il tema o plugin che ha causato l’errore verrà “messo in pausa” permettendo all’amministratore di accedere e risolvere il problema.
C’è da sottolineare che la messa in pausa vale solamente per il backend, mentre nel frontend il tema o plugin che vanno in errore continueranno la loro esecuzione.
A mio parere, una funzione davvero molto molto interessante, una vera rivoluzione!
Editor a blocchi: migliori performance
Come già accennato, la direzione intrapresa dagli sviluppatori di WordPress è chiara: renderlo sempre più semplice da utilizzare. In tale senso, l’introduzione di Gutenberg, il nuovo editor a blocchi integrato, ne è la prova.
Ma è opinione abbastanza diffusa che Gutenberg sia ancora abbastanza acerbo, seppur un buon inizio. Ed è per questo che le intenzioni degli sviluppatori di WordPress sono di migliorare sempre di più usabilità e performance dell’editor a blocchi.
In questa release, sono state in particolare migliorate le performance di inizializzazione e di digitazione.
Se vuoi saperne di più su Gutenberg, leggi:
Per gli sviluppatori
Ma non è finita qui. Con la versione 5.1, WordPress introduce alcune nuove funzioni e miglioramenti anche per gli sviluppatori, eccone una panoramica:
Multisite Metadata
WordPress introduce una nuova tabella nel database “wp_blogmeta” in cui memorizza i metadata dei singoli siti in caso di Multisite.
Precisazione importante, che arriva direttamente dagli sviluppatori stessi di WordPress, è di non abusare di tale tabella. Infatti, i metadata sono un’alternativa più performante delle opzioni globali (da sempre memorizzate nella tabella “wp_options”) in caso sia necessario prelevare informazioni relative ad un altro sito del Network, senza dover necessariamente effettuare uno switch (con la funzione switch_to_blog()).
L’utilizzo delle opzioni resta comunque il metodo consigliato per memorizzare dati globali.
Ad accompagnare questa nuova funzione, non potevano mancare le Meta API dedicate per gestire i metadati:
- get_site_meta ($id, $meta_key, $single)
- update_site_meta ($id, $meta_key, $meta_value, $prev_value)
- add_site_meta ($id, $meta_key, $meta_value, $unique)
- delete_site_meta ($id, $meta_key, $meta_value)
ovviamente disponibili solo in installazioni Multisite.
Per approfondire l’argomento, leggi:
Cron API
Importanti miglioramenti di performance sono stati apportati anche alle Cron API, risolvendo alcuni bugs che restituivano valori ambigui o falsati.
Inoltre, sono state introdotte nuove funzioni:
- wp_get_ready_cron_jobs(): per recuperare i cron jobs pronti all’esecuzione
- wp_get_scheduled_event($hook, $args, $timestamp): per recuperare informazioni e dati di un evento schedulato
Infine, nuovi hooks per permetterti di modificare i Cron Jobs:
- pre_schedule_event: per eventi singoli e ricorrenti
- pre_reschedule_event: per riprogrammare un evento
- pre_unschedule_event: per annullare la pianificazione di un evento
- pre_clear_scheduled_hook: per annullare la pianificazione di tutti gli eventi associati a una combinazione hook/argomento
- pre_unschedule_hook: per annullare la pianificazione di tutti gli eventi relativi a un hook
- pre_get_scheduled_event: per la restituzione di un evento, specificando il relativo timestamp
- pre_get_ready_cron_jobs: per la restituzione di tutti gli eventi cron pronti per essere eseguiti
Per approfondire l’argomento, leggi:
Aggiornamenti minori per gli sviluppatori
- WP_DEBUG_LOG: la costante, di solito inserita nel file wp-config.php, oltre ai soliti valori true/false, può dalla versione 5.1 assumere anche un valore stringa che indica il percorso completo del file in cui memorizzare il log degli errori, al posto del file di default wp-content/debug.log.
- NUOVI HOOKS PER I PLUGINS: relativamente ai plugins sono stati introdotti tre nuovi hooks:
- plugin_loaded
- network_plugin_loaded
- mu_plugin_loaded
che vengono richiamati quando ogni plugin viene correttamente caricato, a differenza dei già esistenti:
- plugins_loaded
- network_plugins_loaded
- mu_plugins_loaded
(nota la “s” del plurale alla fine della parola plugin, rispetto ai nuovi hooks che invece sono al singolare) che vengono richiamati solamente quando tutti i plugins dello stesso tipo vengono caricati correttamente.
- WP_ERROR: la classe predefinita di WordPress che si preoccupa di gestire gli errori, ha adesso un nuovo metodo has_errors() che ritorna in forma boolean a se si sono verificati o meno errori.
Per approfondire l’argomento, leggi: