Le Novità di WordPress 5.5 – Analisi Approfondita di una (Epica) Release

WordPress 5.5 “Eckstine” è arrivato e per noi è giunto il momento di presentare le modifiche e le funzionalità più rilevanti che vengono aggiunte al Core con la seconda release di WordPress dell’anno.

Di questi tempi, siamo abituati a vedere molte novità nell’editor di blocchi ad ogni release di WordPress. WordPress 5.5 non fa eccezione!

Questa versione porta anche un sacco di modifiche non legate all’editor che dovrebbero avere un grande impatto sul modo in cui utilizziamo il CMS.

Anche se WordPress 5.5 apporta molte modifiche al Core, diverse funzionalità attese con la 5.5 sono state rinviate e rimosse da questa versione a causa di diverse anomalie non risolte. Quindi, full-site editing, navigation block, navigation screen e widget screen non fanno parte di WordPress 5.5.

Se volete saperne di più sul ciclo di sviluppo di WordPress 5.5, date un’occhiata ai link qui sotto:

• 7 luglio 2020: Beta 1
• 14 luglio 2020: Beta 2
• 21 luglio 2020: Beta 3
• 27 luglio 2020: Beta 4
• 28 luglio 2020: RC 1
• 4 agosto 2020: RC 2
• 10 agosto 2020: RC 3
• 10 agosto 2020: Prova generale per il rilascio di WordPress 5.5
• 11 agosto 2020: Release finale di WordPress 5.5 “Eckstine“

Allora, cosa c’è di nuovo in WordPress 5.5?

Cosa C’È di Nuovo nell’Editor di Blocchi

Con il rilascio di WordPress 5.5, sono state aggiunte al core ben dieci versioni del plugin Gutenberg, apportando un numero enorme di miglioramenti all’interfaccia utente, funzionalità, miglioramenti e correzioni di bug che influiranno su ogni aspetto dell’esperienza di editing, dall’usabilità alle funzionalità e alle prestazioni.

Sarebbe quasi impossibile menzionare tutte queste modifiche qui, quindi in questo articolo troverete solo una nostra selezione delle nuove funzionalità e miglioramenti preferiti.

Per un elenco più completo dei miglioramenti e delle funzionalità aggiunte all’editor di blocchi con WordPress 5.5, si vedano gli annunci ufficiali delle release del plugin: 7.5, 7.6, 7.7, 7.8, 7.9, 8.0, 8.1, 8.2, 8.3, 8.4, 8.5.

Detto questo, qui parleremo delle seguenti novità portate all’editor di blocchi con WordPress 5.5:

1. Nuovo design dell’Interfaccia Utente
2. Strumenti per la Progettazione dei Blocchi
3. Modifica delle Immagini in Linea
4. Categorie di Blocchi e Nuovo Pannello di Inserimento dei Blocchi
5. Directory dei Blocchi e Block Plugin
6. Block Pattern

Nuovo Design dell’Interfaccia Utente

Ogni versione del plugin Gutenberg apporta piccoli e non così piccoli miglioramenti che cambiano silenziosamente l’esperienza complessiva di editing. Molti di questi cambiamenti fanno ora parte del core di WordPress. Quindi, quando lanciate per la prima volta l’editor di blocchi in WordPress 5.5, un’interfaccia leggermente diversa dovrebbe catturare subito la vostra attenzione. Troverete:

• Una Block Toolbar semplificata
• Contrasti di colore più forti
• Nuove icone
• Block Mover
• Elementi circostanti
• Anteprima per dispositivo
• Miglioramento del drag and drop
• Stili di focus dei blocchi migliorati e uniformati in tutta l’interfaccia utente
• Possibilità di formattare più blocchi contemporaneamente
• Migliori prestazioni

Quelli menzionati sopra sono solo alcuni dei molti cambiamenti che influenzano l’esperienza di editing.

Tra le altre modifiche ricordiamo:

Opzioni Pedice e Apice

Le opzioni di formattazione dei testi per pedice e apice sono ora disponibili attraverso i controlli Rich Text (Gutenberg 8.0).

Selezione del Blocco Genitore

Un nuovissimo pulsante della barra degli strumenti appare ora quando ci si posiziona sul lato sinistro della barra degli strumenti del blocco. Il nuovo pulsante consente di selezionare i blocchi genitori in contesti nidificati (Gutenberg 8.3).

Strumenti per la Progettazione dei Blocchi

Diversi strumenti di progettazione sono stati aggiunti al plugin Gutenberg negli ultimi mesi e ora saranno inclusi nel core con WordPress 5.5.

Controllo dell’Altezza e Sfondo a Gradienti

Una prima serie di strumenti fornisce il controllo delle dimensioni e del colore di sfondo per diversi blocchi (Gutenberg 7.9).

Controlli del Padding e Colore dei Link

Due funzionalità aggiuntive sono entrate nel core (Gutenberg 8.3), ma al momento in cui scriviamo sono ancora contrassegnate come sperimentali:

• Controllo del padding per il blocco Cover.
• Controllo del colore dei link per i blocchi Paragraph, Heading, Group, Columns and Media & Text.

Il controllo del padding e il controllo del colore dei link di default sono disattivati e gli sviluppatori devono dichiararne esplicitamente il supporto, come spiegato nel Block Editor Handbook.

Se volete aggiungere ai vostri temi i controlli del padding per il blocco Cover, aggiungete semplicemente la seguente riga al file functions.php del vostro tema:

add_theme_support( 'experimental-custom-spacing' );

Se volete abilitare il controllo del colore dei link per Paragraph, Heading, Group, Columns and Media & Text, è sufficiente aggiungere la seguente riga al file delle funzioni del tema:

add_theme_support( 'experimental-link-color' );

Unità di Misura e Altezza di Linea Personalizzate

Questa nuova funzionalità permette di impostare i valori dell’altezza in px, em, rem, vw e vh per il blocco Cover (Gutenberg 7.9). % è anch’esso supportato ma viene omesso a causa della resa imprevedibile delle altezze percentuali.

Con il controllo dell’altezza potenziato, è possibile saltare i valori di 10 in 10 tenendo premuto Maiusc mentre si preme freccia su o freccia giù.

Gli sviluppatori possono aggiungere il supporto per unità personalizzate definendo il flag di supporto custom-units:

add_theme_support( 'custom-units' );

È anche possibile impostare specifiche unità personalizzate:

add_theme_support( 'custom-units', 'rem', 'em' );

Gli sviluppatori possono anche aggiungere Altezze di Linea Personalizzate per le intestazioni e i paragrafi definendo il flag di supporto custom-line-height:

add_theme_support( 'custom-line-height' );

Modifica delle Immagini in Linea

Una nuova funzione di editing è stata aggiunta all’editor dei blocchi con Gutenberg 8.4 che permette agli utenti di modificare le immagini direttamente dal blocco Image.

Ora è stato inserito nel core e, a partire da WordPress 5.5, è possibile ritagliare, ruotare, zoomare e regolare le posizioni delle immagini senza la necessità di aprire la Media Library, con il risultato di un’esperienza di editing più veloce.

Se siete soliti pubblicare un sacco di foto, senza dubbio questa funzione vi piacerà.

Basta cliccare sul pulsante Ritaglia nella barra degli strumenti dell’immagine e si avrà accesso alle nuove funzionalità di editing. Quando siete soddisfatti delle vostre personalizzazioni, applicate le modifiche e il gioco è fatto.

WordPress salverà una nuova immagine come allegato nella Libreria Media e copierà i dati dell’immagine originale (titolo, descrizione, didascalia, testo alternativo e dati EXIF). In questo modo si ha il controllo completo sulle nuove versioni delle immagini.

Categorie di Blocchi e Nuovo Pannello di Inserimento dei Blocchi

Un pannello di inserimento blocchi riprogettato mostra i blocchi e i pattern organizzati per categorie, migliorando significativamente l’esperienza di editing e rendendo i blocchi e i pattern più facili da trovare (Gutenberg 8.3).

Directory dei Blocchi e Block Plugin

Con l’implementazione della directory dei blocchi, potete trovare, installare e aggiungere blocchi di terze parti direttamente dall’block inserter.

Quando cercate un blocco, se non è già installato, viene presentato un elenco di plugin disponibili nella directory dei plugin. Questi plugin si chiamano “block plugin” ed è possibile aggiungerli al proprio editor con un solo clic.

Grazie a questa nuova fantastica funzionalità, ora è possibile costruire i propri blocchi e pubblicarli nella Plugin Directory rendendo le proprie creazioni disponibili a tutta la community di WordPress.

La buona notizia è che, per creare i vostri blocchi personalizzati, non è necessario essere un guru di PHP. Avrete solo bisogno di qualche conoscenza pratica di JavaScript.

Non sapete come iniziare a sviluppare i vostri blocchi? La fantastica comunità di WordPress vi supporta con un semplice tutorial passo passo.

La prima versione del tutorial sui blocchi è già disponibile nel manuale ufficiale del Block Editor, in cui potrete apprendere le basi dello sviluppo dei blocchi. Potete leggere di più sulla directory dei blocchi e sullo sviluppo dei block plugin sul blog di Make WordPress Plugins.

Block Pattern

Già nel marzo 2020, Gutenberg 7.7 e Gutenberg 7.8 hanno introdotto i block pattern e le Block Patterns API per temi e plugin.

I Block pattern sono layout di blocchi predefiniti che consentono agli utenti di aggiungere rapidamente strutture complesse di blocchi annidati alle loro pagine. Il loro intento è quello di aiutare gli autori di contenuti e gli amministratori del sito a superare la “sindrome della pagina bianca” e a costruire con facilità layout professionali e viste avanzate.

Dovremmo vedere i block pattern al loro meglio con il full-site editing.

Una chiara spiegazione di quale sia la finalità dei block pattern viene da Mathias Ventura, Lead architect del progetto Gutenberg:

Un chiarimento – l’impostazione dei “block patterns” non riguarda tanto le template part (che sono strutturalmente significative) quanto piuttosto elementi generali di design fatti di blocchi più piccoli. Una volta inseriti, non vengono archiviati separatamente. Ad esempio, un’immagine “Cover” che combina alcuni blocchi per ottenere un aspetto specifico che altrimenti richiederebbe agli utenti un certo lavoro. Pensateli più come una collezione di disegni che possono essere aggiunti ovunque senza necessariamente rappresentare una parte riutilizzabile del template di un tema.

A differenza dei template part, i block pattern sono elementi di design che dovrebbero aiutare gli amministratori dei siti e i creatori di contenuti a velocizzare e migliorare la loro esperienza di editing.

Lanciati con Gutenberg 7.7, all’inizio i Block Pattern apparivano in un plugin della barra laterale. Successivamente, con il rilascio di Gutenberg 8.0, sono stati spostati in un pannello di inserimento blocchi rinnovato che adesso appare come un pannello posto sul lato sinistro dell’editor, come mostrato nell’immagine qui sotto:

Nella loro fase iniziale, i block pattern sono molto limitati. In ogni caso, i pattern apporteranno un enorme miglioramento all’esperienza di editing e, si spera, ne verranno aggiunti altri nel prossimo futuro.

Come i blocchi regolari, i pattern possono essere ricercati e sono organizzati nelle seguenti categorie:

• Text
• Hero
• Columns
• Buttons
• Gallery
• Features
• Testimonials
• Uncategorized

Oltre ai block pattern nativi, gli sviluppatori WordPress possono fornire ai loro temi e plugin pattern personalizzati grazie ad una nuovissima API.

Potete registrare i pattern personalizzati utilizzando la funzione register_block_pattern e register_block_pattern_category per le categorie.

register_block_pattern accetta due argomenti:

1. Il nome del pattern.
2. Una serie di proprietà per il pattern.

Le proprietà possono essere le seguenti:

• title
• content
• description
• categories
• keywords
• viewportWidth

register_block_pattern_category prende anche due argomenti:

1. Il nome della categoria del pattern.
2. Una serie di proprietà.

L’API fornisce anche due funzioni per la cancellazione di pattern e categorie: unregister_block_pattern e unregister_block_pattern_category.

Il modo in cui potete costruire i vostri block pattern è piuttosto semplice. Ad esempio, copiate e incollate il codice seguente in un plugin personalizzato o nel file delle funzioni di un child theme, poi cambiate il nome del pattern secondo le vostre preferenze.

add_action( 'init', function(){

	register_block_pattern_category( 
		'kinsta', 
		array( 'label' => __( 'Kinsta stuff', 'kinsta-pattern' ) ) );

	register_block_pattern(
	'kinsta-pattern/my-custom-pattern',
	array(
		'title'			=> __( 'Two Kinsta buttons', 'kinsta-pattern' ),
		'description'	=> _x( 'Two nice buttons.', 'Kinsta Buttons', 'kinsta-pattern' ),
		'content'		=> "<!-- wp:buttons {\"align\":\"center\"} -->\n<div class=\"wp-block-buttons aligncenter\"><!-- wp:button {\"backgroundColor\":\"very-dark-gray\",\"borderRadius\":0} -->\n<div class=\"wp-block-button\"><a class=\"wp-block-button__link has-background has-very-dark-gray-background-color no-border-radius\">" . esc_html__( 'Button One', 'kinsta-pattern' ) . "</a></div>\n<!-- /wp:button -->\n\n<!-- wp:button {\"textColor\":\"very-dark-gray\",\"borderRadius\":0,\"className\":\"is-style-outline\"} -->\n<div class=\"wp-block-button is-style-outline\"><a class=\"wp-block-button__link has-text-color has-very-dark-gray-color no-border-radius\">" . esc_html__( 'Button Two', 'kinsta-pattern' ) . "</a></div>\n<!-- /wp:button --></div>\n<!-- /wp:buttons -->",
		'categories'	=> array( 'kinsta' ),
	)
	);
});

Il codice qui sopra è una semplice personalizzazione dello snippet originale della Block API Reference. Come potete vedere, non è richiesto alcun codice JavaScript.

Si legga anche Block Patterns in WordPress 5.5.

Lazy Loading Nativo per le Immagini nel Core di WordPress

Il lazy loading è una tecnica di ottimizzazione che differisce il caricamento di risorse non critiche. Ciò significa che il browser viene istruito in modo che carichi il contenuto visibile al caricamento della pagina e a rimandare il download e il rendering delle immagini poste sotto la piega (“below the fold”) fino a quando queste non sono effettivamente necessarie.

Prima del lazy loading nativo, gli sviluppatori web potevano caricare in lazy load gli asset tramite JavaScript, utilizzando la IntersectionObserver API o utilizzando gli event handler scroll, resize e orientationchange.

Ma da quando il lazy loading è diventato uno standard, non abbiamo più bisogno di scrivere codice personalizzato o di utilizzare librerie JavaScript e le immagini in lazyload possono essere implementate utilizzando il nuovo attributo loading nei tag img e iframe.

L’attributo loading determina se il browser deve caricare una risorsa immediatamente o aspettare che siano soddisfatte alcune condizioni. Attualmente supporta i seguenti valori:

• lazy: attende che alcune condizioni siano soddisfatte
• eager: carica la risorsa immediatamente

Al momento in cui scriviamo questo articolo, il lazy loading nativo è supportato da Microsoft Edge, Firefox, Google Chrome, Opera browser, Android browser e Chrome per Android.

Prima di WordPress 5.5, il lazy loading in WordPress era possibile solo con un plugin di ottimizzazione come Autoptimize, BJ Lazy Load o altri. Ora fa parte del core di WordPress e non richiede l’installazione di plugin aggiuntivi!

Lazy Loading Nativo in WordPress

Come affermato da Felix Arntz in un vecchio post del blog di Make WordPress Core, un’implementazione JavaScript di lazy loading in WordPress è stata inizialmente proposta un paio di anni fa, ma non è mai entrata a far parte del Core. La nuova implementazione del lazy loading nativo delle immagini elimina ogni preoccupazione sulla compatibilità e ora la nuova funzionalità può essere tranquillamente inclusa nel Core con WordPress 5.5.

Secondo Felix, il lazy loading nativo delle immagini in WordPress avrebbe un impatto positivo sulle prestazioni dei siti e sull’esperienza degli utente per un numero enorme di siti WordPress che non fanno uso di plugin che implementano il lazy loading:

… senza richiedere alcuna conoscenza tecnica e nemmeno di avere conoscenza del lazy loading. L’adozione del nuovo attributo loading è una grande opportunità per WordPress per aprire la strada ad un web più veloce.

Per evitare il layout shifting, loading="lazy" verrà automaticamente aggiunto ai tag img con gli attributi width e height e ciò è possibile solo se l’immagine è disponibile per WordPress come allegato e include la classe wp-image-$id.

Il lazy loading è un’ottimizzazione indispensabile per ogni installazione di WordPress e per ogni sito web con una notevole quantità di immagini. Felix osserva:

In questo modo si risparmia drasticamente larghezza di banda sia su server che user agent per i siti dove le immagini poste più in basso nella pagina venivano caricate subito, anche nel caso in cui l’utente non fosse mai arrivato a scorrere verso il basso.

Il lazy loading nativo in WordPress funziona con le seguenti immagini:

• Immagini nel contenuto dei post (the_content).
• Immagini nei riassunti dei post (the_excerpt).
• Immagini nei widget di testo (widget_text_content).
• Immagini dell’avatar rese tramite get_avatar().
• Immagini di template che utilizzano wp_get_attachment_image

Nella prima implementazione, il lazy loading supporta solo le immagini, ma ci si può aspettare una futura estensione del lazy load ai tag iframe.

Lazy Loading per gli Sviluppatori di WordPress

Gli sviluppatori possono sovrascrivere il comportamento predefinito usando diversi nuovi filtri. Tra questi filtri, wp_lazy_loading_enabled e wp_img_tag_add_loading_attr sono i più utili per gli sviluppatori:

• wp_lazy_loading_enabled attiva e disattiva l’attributo loading. Questo filtro può essere applicato globalmente o per tag.
• wp_img_tag_add_loading_attr filtra il valore dell’attributo loading e offre un modo per controllare il lazy loading per singola immagine.

L’esempio che segue mostra come disabilitare globalmente il lazy loading:

add_filter( 'wp_lazy_loading_enabled', '__return_false' );

Possiamo anche disabilitare il lazy loading per un tag specifico. Nell’esempio qui sotto, il lazy loading è disattivato sulle immagini nel contesto the_content (per saperne di più, si legga l’articolo su Make WordPress Core):

add_filter(
	'wp_lazy_loading_enabled',
	function( $default, $tag_name, $context ){
		if ( 'img' === $tag_name && 'the_content' === $context ){
			return false;
		}
		return $default;
	},
	10,
	3
);

• $default: il valore booleano di default (true).
• $tag_name: il nome del tag degli elementi da caricare in lazy loading.
• $context: un parametro opzionale che specifica il contesto dell’immagine (si veda la lista sopra).

Si noti che, al momento in cui si scrive, il parametro $tag_name supporta solo il tag img. In ogni caso, come detto sopra, dovrebbero essere aggiunti altri tag nelle future implementazioni.

Se si desidera un controllo più granulare sul lazy loading delle immagini in WordPress, è possibile seguire due approcci diversi a seconda del contesto.

Se si sta lavorando sul contenuto (cioè the_content, the_excerpt, widget_text_content), si potrebbe utilizzare il filtro wp_img_tag_add_loading_attr. L’esempio che segue mostra come disabilitare il lazy loading su una specifica immagine:

add_filter(
	'wp_img_tag_add_loading_attr',
	function( $value, $image, $context ){
		if ( 'the_content' === $context ){
			$image_url = wp_get_attachment_image_url( 67, 'medium' );
			if ( false !== strpos( $image, ' src="' . $image_url . '"' ) ) {
				return false;
			}
		}
		return $value;
	},
	10,
	3
);

Gli sviluppatori di temi possono controllare le immagini anche tramite wp_get_attachment_image. In questo scenario, si può semplicemente impostare il valore dell’attributo loading dell’immagine su false:

echo wp_get_attachment_image(
	67,
	'medium',
	false,
	array( 'loading' => false ),
);

Se volete provare il lazy loading delle immagini prima del rilascio finale di WordPress 5.5, potete installare il plugin ufficiale Lazy Loading Feature Plugin, o dare un’occhiata al codice sorgente su Github.

Native lazy-loading images is coming to #WordPress 5.5, for faster sites and less waste of network resources! And it's accompanied by further image improvements which reduce those annoying layout shifts that make you accidentally click on the wrong things. https://t.co/e7g2s9uSPk

— Felix Arntz (@felixarntz) July 14, 2020

Troverete altre informazioni sul lazy loading delle immagini in WordPress 5.5 sul blog di Make WordPress Core.

Aggiornamenti Automatici per Temi e Plugin

Una delle maggiori preoccupazioni dei proprietari di siti è la sicurezza del sito e mantenere aggiornato il software è una raccomandazione comune che ogni proprietario di sito dovrebbe tenere in debita in considerazione.

Gli aggiornamenti automatici di WordPress sono una funzionalità disponibile sin da WordPress 3.7. Ora, il problema qui è che mentre gli aggiornamenti automatici sono abilitati di default per le release di manutenzione e sicurezza del core, prima di WordPress 5.5, molti proprietari di siti non hanno approfittato degli aggiornamenti automatici per i plugin e i temi.

Il motivo è che questa funzionalità richiedeva una conoscenza di base dello sviluppo di WordPress. Infatti, gli sviluppatori potevano mettere a punto le loro preferenze di aggiornamento definendo una o più costanti in wp-config.php o utilizzando un filtro in un plugin.

Ora, con WordPress 5.5, gli amministratori dei siti possono attivare e disattivare gli aggiornamenti automatici di temi e plugin con un solo clic, direttamente nella loro dashboard di WordPress.

Gli aggiornamenti automatici dei plugin possono essere abilitati e disabilitati cliccando sul link che appare nella colonna Aggiornamenti automatici ora disponibile nella schermata Plugin.

Se volete abilitare gli aggiornamenti automatici per il vostro tema, andate su Aspetto > Temi, poi passate il mouse sul vostro tema e cliccate su Dettagli del tema. Poi, cliccate sul nuovo link Abilita aggiornamenti automatici e il gioco è fatto.

La nuova interfaccia utente degli aggiornamenti automatici dei temi e dei plugin si combina con diverse funzioni e hook che gli sviluppatori possono utilizzare per personalizzare l’esperienza dell’utente nell’aggiornamento automatico.

Funzioni e Filtri per l’Aggiornamento Automatico Disponibili per gli Sviluppatori di Temi e Plugin

Una nuova funzione e diversi filtri permettono agli sviluppatori di WordPress di personalizzare molti aspetti degli aggiornamenti automatici di temi e plugin.

Controllare l’Interfaccia Utente degli Aggiornamenti Automatici

La nuova funzione wp_is_auto_update_enabled_for_type() di WordPress verifica se la UI degli aggiornamenti automatici è abilitata per un dato tipo. La nuova funzione prende un solo argomento ($type) che determina il tipo di aggiornamento da verificare ("theme" o "plugin") e restituisce true o false di conseguenza.

La nuova interfaccia utente degli aggiornamenti automatici dei temi e dei plugin può essere disabilitata grazie a due nuovi filtri: plugins_auto_update_enabled e themes_auto_update_enabled. Si veda l’esempio qui sotto:

// Disable plugins auto-update UI elements.
add_filter( 'plugins_auto_update_enabled', '__return_false' );

// Disable themes auto-update UI elements.
add_filter( 'themes_auto_update_enabled', '__return_false' );

I filtri qui sopra sono documentati in wp-admin/includes/update.php.

Personalizzare i Link degli Aggiornamenti Automatici

Gli sviluppatori di temi e plugin possono personalizzare l’output HTML dei link degli aggiornamenti.

Il filtro plugin_auto_update_setting_html permette di personalizzare i link e il tempo di attesa tra due tentativi di aggiornamento.

La funzione di callback accetta tre argomenti:

• $html: il codice HTML del contenuto della colonna Aggiornamenti automatici del plugin, inclusi i link per l’azione di aggiornamento automatico e l’intervallo di tempo fino al successivo aggiornamento.
• $plugin_file: percorso del file del plugin relativo alla directory dei plugin.
• $plugin_data: un array di dati del plugin.

Ora, se volete personalizzare l’etichetta del testo del link dell’aggiornamento automatico, potete utilizzare il filtro, come mostrato nel seguente snippet.

add_filter( 'plugin_auto_update_setting_html', function( $html, $plugin_file, $plugin_data ){
	if ( 'kinsta-plugin/kinsta-plugin.php' === $plugin_file ) {
		$html = __( 'Custom HTML', 'kinsta-plugin' );
	}
	return $html;	
	}, 
	10, 
	3 
);

L’immagine sottostante mostra il risultato sullo schermo.

Questo filtro è documentato in wp-admin/includes/class-wp-plugins-list-table.php.

Su singoli siti, potete personalizzare il template JS del link di aggiornamento automatico tramite il filtro theme_auto_update_setting_template. Per questo filtro, il post che introduce gli aggiornamenti automatici di temi e plugin fornisce il seguente esempio:

function myplugin_auto_update_setting_template( $template ) {
    $text = __( 'Auto-updates are not available for this theme.', 'my-plugin' );
 
    return "<# if ( [ 'my-theme', 'twentytwenty' ].includes( data.id ) ) { #>
        <p>$text</p>
        <# } else { #>
        $template
        <# } #>";
}
add_filter( 'theme_auto_update_setting_template', 'myplugin_auto_update_setting_template' );

Si raccomanda di controllare il tema target utilizzando il parametro data.id.

Se state lavorando su un’installazione di WordPress Multisite, allora è necessario il filtro theme_auto_update_setting_html, che consente di personalizzare i link degli aggiornamenti automatici della schermata Temi, nello stesso modo della schermata Plugin.

Infine, due filtri aggiuntivi controllano tutti gli aggiornamenti automatici per ogni tema e plugin, inclusi temi e plugin che dovessero essere installati in futuro.

Questi filtri, disponibili a partire da WordPress 3.7, sovrascrivono tutte le impostazioni di aggiornamento automatico nel cruscotto di WordPress. Potete saperne di più nel nostro articolo Analisi Approfondita degli Aggiornamenti Automatici di WordPress. Per una visione più approfondita degli Aggiornamenti Automatici per i temi e i plugin, si legga questo articolo.

Notifiche Email degli Aggiornamenti Automatici e Informazioni di Salute del Sito

A partire da WordPress 5.5, dopo ogni tentativo di aggiornamento automatico viene inviata una notifica via email.

Il filtro auto_plugin_theme_update_email filtra le email inviate dopo un aggiornamento automatico in background. Si legga il post delle dev-notes per un esempio di utilizzo.

Le notifiche email di aggiornamento automatico possono anche essere disattivate utilizzando due nuovi filtri:

// Disable auto-update email notifications for plugins.
add_filter( 'auto_plugin_update_send_email', '__return_false' );

// Disable auto-update email notifications for themes.
add_filter( 'auto_theme_update_send_email', '__return_false' );

Le informazioni di aggiornamento automatico dei plugin e dei temi vengono visualizzate anche nella scheda Informazioni in Salute del Sito (Site Health).

Gli sviluppatori possono personalizzare il testo che appare in questa schermata utilizzando i filtri plugin_auto_update_debug_string e theme_auto_update_debug_debug_string. Ulteriori informazioni e diversi esempi sono disponibili qui.

Core Sitemap Estendibili

Una sitemap è semplicemente un elenco di URL che permette ai motori di ricerca di eseguire rapidamente la scansione del vostro sito web.

Le sitemap sono abbastanza simili ai robots.txt, con la differenza che un file robots.txt esclude il contenuto dall’indicizzazione, mentre una sitemap fornisce un elenco di URL da indicizzare da parte dei motori di ricerca.

Prima di WordPress 5.5, le sitemap potevano essere aggiunte ai siti WordPress solo tramite un plugin o altri strumenti.

Ora WordPress 5.5 porta una nuovissima funzionalità di sitemap XML nel Core di WordPress.

La nuova funzionalità aggiunge funzioni di base, ma viene fornita con un buon numero di hook e di filtri che permettono agli sviluppatori di plugin di estendere le funzioni incorporate.

Le sitemap XML sono abilitate di default (a meno che non si scoraggi l’indicizzazione del sito web da parte dei motori di ricerca) e forniscono i seguenti tipi di oggetti:

• Homepage
• Pagina dei post
• Post type del Core (pagine e articoli)
• Tipi di post personalizzati
• Tassonomie del Core (tag e categorie)
• Tassonomie personalizzate
• Archivi autori

L’indice della sitemap è disponibile all’indirizzo /wp-sitemap.xml e contiene un massimo di 2.000 URL. Quando viene raggiunto il limite massimo, viene aggiunto un nuovo file di sitemap.

Come detto prima, gli sviluppatori di plugin possono personalizzare le loro sitemap utilizzando una o più delle tante azioni e filtri disponibili. Per un elenco completo degli hook relativi alle sitemap, si veda la documentazione del feature plugin e il post introduttivo.

Ad esempio, è possibile disattivare programmaticamente le sitemap del core utilizzando il filtro wp_sitemaps_enabled:

add_filter( 'wp_sitemaps_enabled', '__return_false' );

Le sitemap core non dovrebbero entrare in conflitto con i plugin delle sitemap che avete probabilmente installato sul vostro sito web. Secondo quanto afferma Pascal Birchler su Make WordPress Core:

La funzionalità delle core sitemap è stata sviluppata in modo robusto e facilmente estendibile. Se per qualche ragione due sitemap sono esposte su uno stesso sito web (una dal core, una da un plugin), questo non ha conseguenze negative per la individuabilità del sito.

Come parte della funzione XML Sitemaps, la nuova funzione esc_xml() filtra le stringhe per i blocchi XML. La funzione e il corrispondente filtro sono documentati in wp-includes/formatting.php.

Al momento della stesura di questo articolo, la nuova funzionalità delle sitemap non supporta le immagini, i video e le notizie e probabilmente questo non cambierà in futuro. In ogni caso, nelle versioni future potrebbero essere aggiunti nuovi filtri e hook che permettano agli sviluppatori di aggiungere anche questa funzione.

Per maggiori informazioni sulle sitemap estendibili, si legga l’introduzione alle sitemap per sviluppatori, che descrive nuove classi, funzioni, hook e filtri.

Passaggio di Argomenti ai Template File

Prima di WordPress 5.5, passare dati ai template file era possibile solo tramite variabili globali, query var e poche altre opzioni non ottimali. Ora, a partire da WordPress 5.5, è stato aggiunto un parametro $args alle funzioni di caricamento dei template (gli hook corrispondenti sono stati aggiornati di conseguenza):

• get_header()
• get_footer()
• get_sidebar()
• get_template_part()
• locate_template()
• load_template()

Gli sviluppatori di temi possono ora impostare una variabile in un template file e renderla accessibile in qualsiasi template parziale incorporato, semplicemente passando un array di argomenti.

Ora, mentre questa funzione apre nuove ampie opportunità per gli sviluppatori di temi, Justin Tadlock di WP Tavern pone una buona domanda:

Rimane una domanda: l’arrivo di questa funzionalità è tardivo? Dato che WordPress sta per rinnovare l’intero sistema dei temi in modo che questo si integri con l’imminente funzionalità di editing full-site, questa funzionalità sarà utile solo per i prossimi mesi?

Un buono spunto viene da John Blackbourne:

Anche in un futuro con l’editing full-site, ci sarà ancora molto bisogno di di template part. I tipi di blocco resi dinamicamente possono fare e fanno buon uso di parti di template strutturati, ad esempio. Non si escludono a vicenda, e ci saranno sempre temi ostinati che non faranno ampio uso dei blocchi per il layout.

Abbiamo infine raggiunto Enrico Sorcinelli, WP Core Contributor, che ha condiviso con noi le sue considerazioni:

Se mi stai chiedendo se ci siamo arrivati troppo tardi, dal mio punto di vista non è mai troppo tardi! Credo che in futuro gli sviluppatori di temi potranno beneficiare di questa opportunità, il che non esclude che possa essere utilizzato in simbiosi con l’emergente approccio dell’editing full-site (ad esempio per i blocchi con rendering dinamico).

Forse è troppo presto per dire come questa funzionalità si andrà ad abbinare esattamente con l’editing full-site, ma una cosa sembra certa: lo sviluppo futuro porterà grandi opportunità per costruire siti web migliori sia per gli utenti che per gli sviluppatori.

Aggiornamento di plugin e temi da un file . zip

So cosa state pensando: può sembrare piuttosto “inaspettato” vedere questa funzionalità apparire in concomitanza con gli aggiornamenti automatici. Tuttavia, ha un senso.

Prima di WordPress 5.5, quando mancava una funzionalità di aggiornamento ad un solo clic, gli amministratori di siti potevano caricare gli aggiornamenti di plugin/temi solo tramite FTP/SFTP o file manager (scopri la differenza tra FTP e SFTP per capire perché). Questo era vero soprattutto con plugin/temi personalizzati o con estensioni distribuite su market di terze parti.

A partire da WordPress 5.5, è possibile aggiornare i plugin e i temi caricando un pacchetto . zip dal computer all’interno del cruscotto di WordPress.

Se volete aggiornare un plugin, andate alla schermata Plugin > Aggiungi nuovo e fate clic sul pulsante Carica plugin. Poi, se il plugin è già installato sul vostro sito web, una nuova schermata vi fa sapere che “Questo plugin è già installato” e mostra i dettagli della versione corrente e della versione caricata.

La procedura è abbastanza simile a quella degli aggiornamenti dei temi.

Andate alla schermata Aspetto > Temi, poi fate clic su Aggiungi nuovo e poi su Carica tema. Se il tema è già installato sul vostro sito WordPress, una nuova schermata vi fa sapere che “Questo tema è già installato” e mostra i dettagli della versione corrente e della versione caricata.

Altri Miglioramenti per Sviluppatori in Arrivo con WordPress 5.5

Oltre a quanto abbiamo trattato finora, un paio di aggiunte meritano l’attenzione degli sviluppatori.

Nuova Funzione wp_get_environment_type()

La nuova funzione wp_get_environment_type() permette di rilevare il tipo di ambiente corrente di un sito web, permettendo agli sviluppatori di adattare le funzionalità dei plugin e dei temi all’ambiente su cui lavorano.

Di default, wp_get_environment_type() restituisce production. Altri valori supportati sono development e staging. In ogni caso, gli sviluppatori possono definire ulteriori tipi di ambiente, se necessario.

Ci sono tre metodi a disposizione per impostare il tipo di ambiente di un sito web. In ordine di priorità, è possibile utilizzare:

• La variabile d’ambiente PHP WP_ENVIRONMENT_TYPE.
• La costante WP_ENVIRONMENT_TYPE.
• Il filtro wp_get_environment_type.

Come esempio, se volete impostare il vostro proprioambiente su staging, potete definire la costante WP_ENVIRONMENT_TYPE nel file wp-config.php, come mostrato di seguito:

define( 'WP_ENVIRONMENT_TYPE', 'staging' );

Se il tipo di ambiente è development, WP_DEBUG sarà automaticamente impostato a true, anche se non è stato definito esplicitamente.

Modifiche alla REST API in WordPress 5.5

WordPress 5.5 apporta anche molte modifiche alle REST API. Vedremo diversi nuovi endpoint, nuovi parametri e modifiche allo schema JSON, nuove funzioni e ulteriori miglioramenti.

Ecco un breve elenco dei nuovi endpoint:

Tipi di blocco

Un nuovo endpoint permette di ottenere tutti i tipi di blocco registrati:

• GET /wp/v2/block-types restituirà tutti i tipi di blocco registrati.
• GET /wp/v2/block-types/core restituirà tutti i blocchi all’interno dello spazio dei nomi del core.
• GET /wp/v2/block-types/core/quote restituirà la definizione del blocco quote del core.

Plugin

Un nuovo endpoint permette di gestire i plugin:

• GET /wp/v2/plugins restituirà un elenco di tutti i plugin installati.
• GET /wp/v2/plugins/plugin-name/plugin-name restituirà le informazioni sul plugin specificato.
• POST /wp/v2/plugins { slug: "plugin-name" } installa il plugin specificato dalla directory dei plugin
• PUT /wp/v2/plugins/plugin-name/plugin-name { status: "active" } attiva il plugin specificato
• DELETE /wp/v2/plugins/plugin-name/plugin-name cancella un plugin inattivo.

Elenco dei Blocchi

Un nuovo endpoint permette di cercare nella directory dei blocchi:

• GET /wp/v2/block-directory/search?term=block-name cerca block-name nella directory dei blocchi

Modifica delle Immagini

In coppia con la nuova funzionalità di editing delle immagini in linea, un nuovo endpoint permette di modificare gli allegati delle immagini nella Media Library:

POST /wp/v2/media/5/edit modifica l’immagine con ID 5

Si leggano le dev notes di WordPress Core per un’analisi più dettagliata di tutte le modifiche alle REST API in arrivo con WordPress 5.5.

Riepilogo

Siamo entusiasti di tutte queste nuove funzionalità e miglioramenti che WordPress 5.5 ci porta in un’unica release.

Questo dimostra l’enorme mole di lavoro che si svolge dietro le quinte e apprezziamo enormemente gli sforzi e l’impegno di ogni singolo contributor allo sviluppo del core.

Se le modifiche sopra elencate non vi bastano, ecco altri miglioramenti in arrivo con WordPress 5.5:

• Aggiunte 65 nuove icone al font Dashicons nel Core di WordPress
• Miglioramenti all’accessibilità degli elenchi di link nei widget
• Nuovi stili CSS per i pulsanti disabilitati
• Invalidazione della Opcode Cache
• Migliore controllo di redirect_guess_404_permalink()
• Miglioramenti relativi a PHP
• Modifiche al codebase
• Modifiche alle funzioni e al filtro del logo personalizzato
• Aggiornamenti alle Block API
• Filtri per le intestazioni delle pagine di archivio
• Aggiunta di icone in Twenty Twenty
• E molto altro

Non perdetevi il nostro webinar gratuito completamente dedicato a WordPress 5.5!

Ora tocca a voi. Quali sono le funzionalità e/o i miglioramenti che vi piacciono di più in WordPress 5.5? E quali funzionalità vorreste aggiungere a WordPress 5.6? Condividete le vostre considerazioni nella sezione dei commenti qui sotto!