Le Novità di WordPress 5.7 (Lazy-Loading, HTTPS, Aggiornamenti UI, Nuove API e Molto Altro)

Siamo abituati a vedere piccoli e meno piccoli cambiamenti e nuove funzionalità aggiungersi al Core di WordPress ogni volta che viene rilasciata una nuova versione. WordPress 5.7 non fa eccezione, ed è bello vedere come ogni nuova release ci avvicina un po’ di più alla Big Picture.

Con diverse versioni del Block Editor che entrano a far parte del Core, la nuova release migliora l’esperienza complessiva di editing e consente agli sviluppatori di costruire blocchi più avanzati e aggiungere personalizzazioni più spinte all’editor di blocchi.

A parte l’editor, WordPress 5.7 introduce anche moltissime modifiche e funzionalità, tra cui iframe lazy-loading, aggiornamenti dell’interfaccia di login e registrazione, link per resettare la password, un gran numero di correzioni di bug e molto altro.

Abbiamo eseguito i nostri test su DevKinsta e vogliamo condividere con voi le nostre funzionalità preferite e le modifiche in arrivo con WordPress 5.7, con un sacco di screenshot e esempi di codice.

Se volete immergervi più a fondo nella prima major release del 2021, date un’occhiata a Development Cycle, Planning Roundup e Field Guide di WordPress 5.7.

Quindi, mentre continuiamo ad aspettare il rilascio del Full Site Editing (nel Core da WordPress 5.8), mettiamoci comodi e godiamoci le novità di WordPress 5.7!

Cosa c’è di Nuovo nell’Editor di Blocchi

WordPress 5.7 porta nel Core molte versioni del plugin Gutenberg. Sarebbe impossibile menzionare qui tutte queste novità, oltre a tutte le modifiche e correzioni di bug aggiunti all’editor, ma potete visitare i seguenti link per approfondire le caratteristiche di ogni versione: 9.3, 9.4, 9.5, 9.6, 9.7, 9.8, 9.9.

Sono anche parte di WordPress 5.7 le correzioni dei bug e i miglioramenti delle prestazioni di Gutenberg 10.0 e 10.1.

Detto questo, passiamo al nostro elenco scelto delle funzionalità più interessanti e delle modifiche apportate all’editor di blocchi con WordPress 5.7:

Funzionalità, Miglioramenti e API delle Variazioni di Blocco

Introdotte con WordPress 5.4, le Block Variation offrono all’utente la possibilità di selezionare un’istanza diversa dello stesso blocco.

Questa funzionalità va in coppia con la Block Variation API, un potente strumento che permette agli sviluppatori di aggiungere, gestire o rimuovere variazioni di blocco.

WordPress 5.7 introduce diversi miglioramenti, funzionalità e nuove API per le variazioni di blocco, fornendo una migliore interfaccia utente e strumenti più potenti per gli sviluppatori. Scopriamoli più da vicino.

Trasformazioni delle Variazioni dei Blocchi

Introdotto per la prima volta con Gutenberg 9.4 e ora aggiunto a WordPress 5.7, uno switcher Trasforma in variazione appare sotto la scheda del blocco per i blocchi che supportano questa funzionalità.

Quando si registra una nuova variazione di blocco, gli sviluppatori di blocchi possono aggiungere lo switcher di variazione al block inspector inserendo la nuova opzione transform al campo scope della variazione di blocco, come mostrato nel seguente esempio (solo codice JS):

wp.blocks.registerBlockVariation( 'core/heading', { 
	name: 'green-text',
	title: 'Green Text',
	description: 'This block has green text. It overrides the default description.',  
	attributes: { 
		content: 'Green Text', 
		textColor: 'vivid-green-cyan' 
	}, 
	icon: 'palmtree', 
	scope: [ 'inserter', 'transform' ] 
} );

In questo esempio, una variazione di blocco appare in due aree della UI dell’editor: il block inserter e il block inspector.

Per un’analisi più approfondita sulle Trasformazioni in Variazione dei Blocchi, si legga anche la PR #26687.

Le Informazioni sui Blocchi ora Corrispondono alle Variazioni di Blocco

A partire da WordPress 5.7 (e Gutenberg 9.7), la UI mostra informazioni più specifiche sulle variazioni dei blocchi, mentre prima mostrava solo informazioni generiche.

I blocchi Embed e le Social Icons sono generati come variazioni di blocco; questi forniscono buoni esempi di abbinamento delle informazioni di blocco con le variazioni di blocco.

Questi cambiamenti riguardano il block inspector, la barra di navigazione dei blocchi e i breadcrumb. A partire da Gutenberg 9.8, questo miglioramento dell’UI si applica anche allo switcher dei blocchi.

Nuove API per le Variazioni di Blocco

WordPress 5.7 introduce anche nuove API che gli sviluppatori possono utilizzare nella registrazione delle variazioni di blocco per mostrare le informazioni corrette di una variazione di blocco (Gutenberg 9.7).

La nuova proprietà isActive è una funzione che accetta gli attributi di un blocco. Potete utilizzare gli attributi della variazione per stabilire se una variazione è attiva (vedi anche Block API Reference).

Gli sviluppatori di blocchi possono usare questa funzione per mostrare informazioni sulla variazione invece che sul blocco. Un esempio potrebbe essere il blocco embed, dove possiamo cambiare il valore dell’attributo providerNameSlug (esempio tratto dalla nota di sviluppo):

const variations = [
{
	name: 'wordpress',
	title: 'WordPress',
	keywords: [ __( 'post' ), __( 'blog' ) ],
	description: __( 'Embed a WordPress post.' ),
	attributes: { providerNameSlug: 'wordpress' },
	isActive: ( blockAttributes, variationAttributes ) =>
		blockAttributes.providerNameSlug === variationAttributes.providerNameSlug,
},
];

Nell’esempio che segue, la proprietà isActive è utilizzata per cambiare il valore dell’attributo color:

variations: [
{
	name: 'blue',
	title: __( 'Blue Quote' ),
	isDefault: true,
	attributes: { color: 'blue', className: 'is-style-blue-quote' },
	icon: 'format-quote',
	isActive: ( blockAttributes, variationAttributes ) =>
		blockAttributes.color === variationAttributes.color
},
],

Il nuovo hook useBlockDisplayInformation restituisce informazioni su un dato blocco. Il nuovo hook tiene conto della proprietà isActive di una variazione di blocco e restituisce title, icon e description del blocco.

Queste modifiche interessano Block Card (Inspector Tools), Navigation List View (barra superiore) e le Breadcrumbs (vedi anche PR #27469).

Nuove Funzionalità del Blocco Buttons

Un paio di nuove caratteristiche migliorano la funzionalità e l’interfaccia del blocco Buttons.

Dimensioni dei Pulsanti

Un nuovo controllo disponibile nelle impostazioni ci permette ora di impostare una larghezza percentuale per i pulsanti inseriti nei blocchi Buttons (Gutenberg 9.4).

Basta selezionare un pulsante e scegliere 25%, 50%, 75% o 100%. Le percentuali si riferiscono al container superiore. L’immagine qui sotto mostra diverse combinazioni nelle dimensioni dei pulsanti.

Per approfondimenti tecnici, si fa rinvio alle pull request #25999 e #26781.

Layout Verticale

Questa nuova funzionalità aggiunge variazioni per l’orientamento verticale al blocco Buttons. Gli utenti possono passare da un layout orizzontale a uno verticale utilizzando il selettore delle trasformazioni disponibile nel pannello delle impostazioni del blocco (Gutenberg 9.6).

Miglioramenti alle Social Icon

WordPress 5.7 aggiunge nuove opzioni di personalizzazione alle Icone sociali: supporto delle dimensioni personalizzate e colori personalizzati.

Dimensione delle Icone Sociali

Con il blocco delle Icone sociali selezionato, la barra degli strumenti del blocco mostra ora un menu di opzioni Dimensione con le dimensioni disponibili (Gutenberg 9.4).

Colori Personalizzati nelle Icone Social

Lo stesso blocco ora supporta le impostazioni di colore, permettendoci di impostare colori personalizzati diversi per le icone e gli sfondi (Gutenberg 9.9).

Ora possiamo usare la palette di colori del tema per le icone social, evitando che i colori delle icone vadano in conflitto con la combinazione di colori del sito web (vedi anche PR #28084).

Supporto per le Dimensioni del Font

WordPress 5.7 aggiunge il supporto per le Dimensione del font sia per i blocchi Elenco che per i blocchi Codice.

Dimensione del Font nel Blocco Elenco

È stata aggiunta alle impostazioni del blocco Elenco la scheda Tipografia, contenente i controlli per la dimensione del carattere (Gutenberg 9.4).

Gli utenti possono scegliere una delle dimensioni dei caratteri disponibili per gli elementi della lista o impostare una dimensione del font personalizzata espressa in pixel. Il pulsante “Reimposta” ripristina i valori predefiniti.

Supporto della Dimensione del Font nel Blocco Codice

WordPress 5.7 aggiunge anche il supporto per la gestione delle dimensioni dei caratteri all’interno dei blocchi Codice. Selezionando il blocco Codice, la barra laterale delle impostazioni del blocco visualizza un nuovo controllo Dimensione del font. Questo controllo consente di scegliere una delle dimensioni preimpostate disponibili nel vostro tema o di impostare un valore personalizzato in pixel (Gutenberg 9.5).

L’implementazione di questa funzionalità permette anche di utilizzare variabili di stile globali nel CSS dei blocchi di codice (vedi anche PR #27294). L’immagine qui sotto mostra un blocco di codice sul frontend con il tema Twenty Twenty.

Allineamento ad Altezza Piena nel Blocco Copertina

WordPress 5.7 introduce il nuovo componente Full Height Toolbar Alignment. È stato aggiunto per la prima volta all’editor di blocchi con Gutenberg 9.5. Ora è confluito nel Core e implementato nel blocco Copertina.

Se si attiva il pulsante della barra degli strumenti del blocco, tenendo d’occhio il controllo dell’altezza minima, si vedrà che l’allineamento ad altezza piena è solo un’abbreviazione di 100vh (si veda le lunghezze in percentuale del viewport).

Si può utilizzare l’allineamento ad altezza piena in combinazione con altre impostazioni come lo sfondo fisso, la posizione del contenuto e così via. Probabilmente rimarrete sorpresi dal numero di effetti sorprendenti che sarete in grado di creare sulle vostre pagine.

Drag & Drop di Blocchi e Modelli dall’Inseritore

L’inseritore di blocchi ora supporta il drag & drop di blocchi e modelli. Gli utenti possono prendere qualsiasi blocco o modello dall’inseritore e posizionarlo ovunque sul canvas del post (Gutenberg 9.6 e 9.7).

Si noti che il drag & drop funziona solo se il tema corrente supporta i modelli di blocchi.

Blocco Spazio Vuoto Semitrasparente

Al posto del precedente colore grigio opaco, il blocco Spazio Vuoto (Spacer) ora ha uno sfondo semi-trasparente (Gutenberg 9.8).

Questa caratteristica dovrebbe rendere più semplice l’identificazione del blocco Spazio Vuoto al di sopra di qualsiasi colore di sfondo.

Altri Miglioramenti nell’Editor di Blocchi Degni di Nota

Il nostro elenco non copre tutte le funzionalità e i miglioramenti entrati a far parte del Core. Date un’occhiata alla documentazione ufficiale e alle note di sviluppo per un registro più completo delle novità che entrano a far parte dell’editor di blocchi con WordPress 5.7.

Ma, solo per citarne alcune, nella 5.7 troverete anche:

• Attivazione automatica del Dark Mode quando è abilitato lo sfondo scuro (PR #28233)
• Icone Patreon, Telegram e TikTok aggiunte alle Icone social (PR #26118)
• Supporto di tutte le unità di misura nelle impostazioni delle dimensioni dei font (PR #26475)
• Anteprima delle trasformazioni dei blocchi (PR #27861)
• Migliorata l’anteprima del modello di blocco nell’inseritore di blocchi (PR #27204)
• Il modale Opzioni è stato migliorato e il nome cambiato in Preferenze
• Novità nella @wordpress/data API
• Novità nelle Inner Blocks API
• Miglioramenti nella funzionalità di Importazione/Esportazione
• Modifiche a componenti e blocchi dell’editor

Lazy-Loading degli iframe

Il lazy loading è una tecnica di ottimizzazione che differisce il caricamento delle risorse non critiche fino a quando non sono nel viewport dell’utente. Le immagini in lazy-loading e le risorse incorporate non vengono scaricate e renderizzate finché non sono necessarie. Questo può migliorare significativamente le prestazioni dei siti, specialmente per i siti web che presentano immagini ad alta risoluzione e video.

Prima del lazy loading nativo, gli sviluppatori potevano differire il caricamento delle risorse solo tramite JavaScript. Per ottenere lo stesso effetto, gli utenti di WordPress erano costretti a utilizzare un plugin. Da quando il lazy loading è diventato uno standard, però, il caricamento delle immagini e degli iframe può essere differito semplicemente aggiungendo l’attributo loading="lazy" ai tag img e iframe.

Con WordPress 5.5 è stato introdotto il Lazy-Loading Nativo delle Immagini nel Core di WordPress, con l’aggiunta automatica dell’attributo loading="lazy" ai tag img nei quali siano stati specificati gli attributi width e height.

Ora, a partire da WordPress 5.7, il lazy loading è esteso ai tag iframe. Per quanto riguarda le immagini, per prevenire il layout shifting, l’attributo loading="lazy" sarà aggiunto a tutti i tag iframe nei quali siano stati specificati gli attributi width e height.

Il lazy-loading nativo funziona in WordPress con gli iframe nei seguenti contesti:

• iframe nel contenuto dei post (the_content)
• iframe nei riassunti dei post (the_excerpt)
• iframe nei widget di testo (widget_text_content)

In WordPress, la maggior parte degli iframe si basa sull’integrazione oEmbed, che trasforma automaticamente un URL nel tag iframe corrispondente. Sfortunatamente, non tutti i servizi web forniscono gli attributi width e height per gli iframe; questo impedisce a WordPress di aggiungere l’attributo loading a questi iframe.

L’immagine qui sotto mostra un tag iframe con l’attributo loading="lazy":

Nelle parole di Felix Arntz:

Il markup di questi tag iframe è controllato dal rispettivo servizio web e solo alcuni di questi servizi web seguono la best practice di fornire gli attributi width e height. Dato che WordPress non può indovinare le dimensioni della risorsa incorporata, l’attributo loading="lazy" sarà aggiunto solo se il tag oEmbed iframe dispone di entrambi gli attributi di dimensione.

L’immagine seguente mostra un tag iframe senza l’attributo loading="lazy":

Lazy-Loading degli iframe per gli Sviluppatori

Dal punto di vista di uno sviluppatore, la nuova funzionalità ha richiesto diverse modifiche, tra cui:

• Il comportamento della funzione wp_filter_content_tags() è stato esteso in modo da aggiungere l’attributo loading ai tag iframe. L’attributo loading era precedentemente aggiunto solo ai tag img.
• Di default, la funzione wp_lazy_loading_enabled() ora restituisce true per i tag iframe (quando abilitati).
• La nuova funzione wp_iframe_tag_add_loading_attr() permette di aggiungere l’attributo loading ai tag iframe (simile a wp_img_tag_add_loading_attr() – vedi la Code Reference).
• Il filtro wp_iframe_tag_add_loading_attr permette di personalizzare il lazy loading su specifici iframe. Restituendo false o una stringa vuota non verrà aggiunto l’attributo.

.
È possibile sovrascrivere il comportamento predefinito utilizzando il già disponibile filtro filtro wp_lazy_loading_enabled, che ora restituisce true per i tag iframe.

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

È anche possibile ustilizzare il nuovo filtro wp_iframe_tag_add_loading_attr, che permette di personalizzare il comportamento di uno specifico tag iframe. Ad esempio, si potrebbe disabilitare il lazy loading per i video di YouTube in un particolare contesto.

Il codice qui sotto è basato su un esempio dalla nota di sviluppo e mostra come disabilitare il lazy loading per gli iframe che incorporano i video di YouTube:

add_filter(
	'wp_iframe_tag_add_loading_attr',
	function( $value, $iframe, $context ){
		if ( 'the_content' === $context && false !== strpos( $iframe, 'youtube.com' ) {
		return false;
	},
	10,
	3
);

Si noti che, al momento in cui scriviamo, il lazy loading non è supportato dalla generalità dei browser. Qui sotto si vede che Firefox e Safari supportano il lazy loading solo sulle immagini.

Migrazione dei Siti da HTTP a HTTPS con un Solo Clic

Dalla 5.7, WordPress rileva se l’ambiente di un sito web supporta HTTPS. In caso positivo, la sezione Stato HTTPS nello strumento Salute del Sito fornisce un pulsante call-to-action che consente agli amministratori dei siti di passare i loro siti web da HTTP a HTTPS con un solo clic. Il contenuto del sito viene migrato al volo, prevenendo qualsiasi avviso di contenuto misto.

WordPress visualizzerà una notifica se HTTPS non è supportato.

Migrazione da HTTP a HTTPS per gli Sviluppatori

Insieme alla nuova funzione automatica accessibile dallo strumento Salute del SIto, WordPress 5.7 introduce nuove funzioni che consentono agli sviluppatori di testare e personalizzare diversi aspetti del rilevamento e della migrazione HTTPS.

La nuova funzione wp_is_using_https() restituisce true se sia “Indirizzo Sito” (home_url()) che “Indirizzo WordPress” (site_url()) hanno un URL contenente https. Questa nuova funzionalità è illustrata chiaramente da Felix Arntz nella nota di sviluppo:

Essenzialmente, cambiare entrambi gli URL in HTTPS significa formalmente che il sito sta utilizzando HTTPS. Anche se ci sono altri modi per abilitare parzialmente HTTPS in WordPress (ad esempio con la costante FORCE_SSL_ADMIN), il nuovo meccanismo di rilevamento si focalizza sull’utilizzo di HTTPS in tutto il sito, cioè sia sul frontend che sul backend.

Mentre la funzione wp_is_using_https() controlla la presenza di https nell’URL, wp_is_https_supported() verifica se l’ambiente del sito supporta correttamente HTTPS.

Questa funzione verifica essenzialmente la presenza dell’opzione https_detection_errors nel database e restituisce true nel caso in cui non vengano rilevati errori. Nel caso in cui il vostro ambiente non supporti HTTPS, l’opzione https_detection_errors sarà presente nella tabella wp_options, come mostrato nella seguente immagine:

Come accennato in precedenza, gli URL hardcoded nel contenuto del sito vengono modificati al volo, tutto grazie a due nuove funzioni: wp_replace_insecure_home_url() e wp_should_replace_insecure_home_url().

Per migrare un sito web da HTTP a HTTPS, l’amministratore del sito così avrebbe solo bisogno di aggiornare manualmente “Indirizzo sito” e “Indirizzo WordPress” in modo che contengano HTTPS invece di HTTP. Tuttavia, per rendere le cose ancora più semplici, WordPress 5.7 introduce la nuova funzione wp_update_urls_to_https().

Quest’ultima funzione permette di migrare un sito e tutti i suoi contenuti da HTTP a HTTPS con un solo clic (almeno negli scenari più comuni, come quando “Indirizzo sito” corrisponde a “Indirizzo WordPress”). È una novità assoluta e un notevole miglioramento dell’esperienza di amministrazione di WordPress.

Per altri aspetti tecnici del rilevamento e della migrazione HTTPS, si veda la nota di Felix Arntz e i ticket #47577 e #51437.

Nuove Funzioni Relative ai Post Genitori

WordPress 5.7 introduce due nuove funzioni relative ai Post Parent. Sono semplici da utilizzare e aiutano a ridurre la logica nei plugin e nei temi.

has_parent_post()

La funzione has_parent_post() è un tag condizionale che controlla se un dato post ha un genitore, quindi restituisce true o false di conseguenza. Accetta come parametro l’ID del post o l’oggetto WP_Post e utilizza la variabile globale $post se disponibile. Ecco un esempio:

<?php if ( has_parent_post( get_the_ID() ) ) : ?>
	// your code here
<?php endif; ?>

get_parent_post()

La funzione get_parent_post() è un template tag che recupera l’oggetto WP_Post genitore per un dato post. Come la funzione precedente, anche questa accetta come parametro l’ID del post o l’oggetto WP_Post. Ecco un esempio di utilizzo:

<a href="<?php the_permalink( get_parent_post( get_the_ID() ) ); ?>"><?php echo get_the_title( get_parent_post( get_the_ID() ) ); ?></a>

Nel mondo reale, queste funzioni vengono utilizzate insieme. Potete eseguire un test da soli, aggiungendo al template file single.php del vostro tema il seguente codice tratto dalla nota di sviluppo:

<?php if ( has_parent_post( get_the_ID() ) ) : ?>
	<p><a href="<?php the_permalink( get_parent_post( get_the_ID() ) ); ?>">
	<?php
		echo sprintf(
			esc_html__( 'Parent page: %s', 'text-domain' ),
			get_the_title( get_parent_post( get_the_ID() ) )
		);
	?>
	</a></p>
<?php endif; ?>

Aggiornamenti dell’Interfaccia di Accesso e Registrazione

WordPress 5.7 porta diversi miglioramenti alla funzionalità di login e registrazione, con un’interfaccia di Reset della Password migliorata, nuovi hook e altre modifiche minori.

Schermata del Reset della Password

La schermata del Reset della Password ora fornisce due pulsanti: Genera password e Salva password. Il primo pulsante genera una nuova password forte ad ogni clic, mentre il secondo pulsante salva la password. Questa modifica dovrebbe risultare in una migliore esperienza di reimpostazione della password per i nuovi utenti di WordPress.

L’immagine qui sotto mette a confronto le schermate di reset della password in WordPress 5.6 e 5.7:

Nuovi Filtri

Il nuovo hook lostpassword_user_data permette di filtrare la variabile $user_data al reset della password. Gli sviluppatori possono ora eseguire la convalida dell’utente utilizzando dati personalizzati al posto del nome utente o dell’indirizzo email. Per un esempio reale, si legga questo commento di Marcelo Villela Gusmão.

Il nuovo filtro login_site_html_link permette di sostituire completamente l’HTML che genera il link “Torna a {site_name}” con codice/link personalizzati. Ora gli sviluppatori possono impostare un testo personalizzato per il link, oppure cambiare il link stesso. Potete utilizzare il filtro come illustrato nel seguente esempio:

function custom_login_site_html_link( $link ) {
	return '' . __( 'Back to my awesome blog', 'textdomain' ) . '';
}
add_filter( 'login_site_html_link', 'custom_login_site_html_link', 10, 1 );

L’immagine qui sotto mostra l’output a schermo:

Per altre novità, si legga la nota di sviluppo Modifiche alle schermate di login e registrazione in WordPress 5.7.

Nuove Funzioni per Verificare se un Post è Visibile Pubblicamente

WordPress 5.7 introduce due nuove funzioni che permettono agli sviluppatori di verificare se un post è visibile pubblicamente.

is_post_status_viewable()

La nuova funzione is_post_status_viewable() permette agli sviluppatori di determinare se un post è visualizzabile pubblicamente a seconda dello stato del post.

Questa nuova funzione offre un modo migliore per verificare se un post è visualizzabile rispetto alla funzione esistente is_post_type_viewable(), che verifica se un tipo di post è visibile agli utenti anonimi ma non aiuta a stabilire se un post specifico è effettivamente visibile o meno.

Per i tipi di post integrati, is_post_status_viewable() verifica l’attributo public. Per i tipi di post personalizzati, verifica invece l’attributo publicly_queryable.

Abbiamo testato il seguente codice, basato sull’esempio della nota di sviluppo, in un’installazione locale:

$current_post_status = get_post_status( $post );
if ( is_post_status_viewable( $current_post_status ) ) {
	echo '<p>This post uses a public post status.' . ' Current status: <strong>' . $current_post_status . '</strong></p>';
} else {
	echo '<p>This post uses a non public post status.' . ' Current status: <strong>' . $current_post_status . '</strong></p>';
}

is_post_status_viewable() accetta un parametro obbligatorio:

• $post_status (string|stdClass) Il nome o l’oggetto dello stato del post.

In un post pubblico, il codice qui sopra genererebbe il seguente risultato:

In un post privato, il risultato sarebbe il seguente:

Jean-Baptiste Audras, autore della nota di sviluppo, avverte:

Si noti che i post protetti da password sono considerati visibili pubblicamente, mentre i post privati no.

is_post_publicly_viewable()

La nuova funzione is_post_publicly_viewable() restituisce true se sia is_post_status_viewable() che is_post_type_viewable() restituiscono true. Ci permette anche di stabilire se un post specifico è visualizzabile pubblicamente (cioè se è visualizzabile dagli utenti disconnessi).

is_post_publicly_viewable() accetta un parametro opzionale:

• $post (string|stdClass) Un ID o un oggetto post. Di default, viene passato l’oggetto globale $post.

Un Nuovo Hook Dinamico per Filtrare il Contenuto di un Tipo di Blocco Specifico

WordPress 5.7 introduce un nuovo hook dinamico che permette agli sviluppatori di filtrare il contenuto di uno specifico tipo di blocco.

Questo nuovo filtro render_block_{$this->name} è simile all’esistente filtro render_block, con una differenza importante: render_block filtra il contenuto di un singolo blocco, mentre il nuovo hook dinamico filtra il contenuto del blocco di tipo {$this->name}.

Per utilizzare questo filtro, è necessario fornire i seguenti parametri:

• $block_content (stringa): Il contenuto del blocco da aggiungere.
• $block (array): Il blocco completo, incluso il nome e gli attributi.

.
La callback restituisce il contenuto del blocco modificato.

L’esempio che segue mostra un caso d’uso di questo filtro su un blocco paragrafo:

add_filter( 
	'render_block_core/paragraph', 
	function( $block_content, $block ) {
		$content  = '<div class="my-custom-wrapper">' . $block_content . '</div>';
		return $content;
	}, 
	10, 
	2 
);

In questo esempio, il suffisso core/paragraph è lo slug del tipo di blocco core Paragrafo. Per i blocchi personalizzati, lo slug dovrebbe essere qualcosa tipo my-custom-plugin/my-custom-block.

Si veda la nota di sviluppo per un’analisi più approfondita e altri esempi di utilizzo.

Nuova Robots API

Il meta tag robots permette ai proprietari di sito di controllare il modo in cui una pagina web dovrebbe essere indicizzata e servita agli utenti nei risultati dei motori di ricerca (a proposito, non perdetevi la nostra guida alla SEO).

WordPress 5.7 introduce la nuova Robots API che permette agli sviluppatori di controllare il meta tag robots. La nuova API fornisce un filtro wp_robots che permette agli sviluppatori di temi di aggiungere le loro direttive personalizzate al meta tag robots.

Inoltre, è ora aggiunta di default la direttiva max-image-preview:large ai siti web configurati per essere visibili dai motori di ricerca. Questa istruisce i motori di ricerca a visualizzare anteprime di immagini di grandi dimensioni nei risultati di ricerca.

Gli sviluppatori possono rimuovere la direttiva max-image-preview:large utilizzando il seguente codice:

remove_filter( 'wp_robots', 'wp_robots_max_image_preview_large' );

Personalizzare le direttive robots è abbastanza semplice. Il seguente esempio tratto dalla nota di sviluppo mostra come aggiungere una direttiva personalizzata al meta tag:

add_filter( 
	'wp_robots', 
	function( $robots ) {
		$robots['follow'] = true;
		return $robots;
	}
);

Il codice qui sopra produrrebbe il seguente output:

<meta name="robots" content="max-image-preview:large, follow">

È anche possibile rimuovere le direttive esistenti semplicemente eliminando i valori. Il seguente codice disattiva la direttiva max-image-preview:

function my_wp_robots_directives( $robots ) {
	unset( $robots['max-image-preview'] );
	$robots['follow'] = true;
	return $robots;
}
add_filter( 'wp_robots', 'my_wp_robots_directives' );

Troverete una panoramica approfondita del meta tag robots sul blog di Ahrefs e sulla Google Search Reference. Si veda anche la nota di sviluppo per maggiori informazioni sulla nuova Robots API di WordPress e sulle funzioni deprecate.

Link di Ripristino della Password

Una nuova funzione permette ora agli amministratori dei siti di inviare un link di ripristino della password via email a qualsiasi utente registrato. Questa funzione potrebbe essere utile se un utente, per qualsiasi motivo, non può accedere al link di ripristino della password.

Gli amministratori dei siti possono inviare un link di ripristino della password via email da diverse aree. In primo luogo, troverete una nuova sezione che fornisce un pulsante Invia link di ripristino nello Schermata del profilo di qualsiasi utente.

Se tutto va bene, dovreste vedere un avviso che conferma che il link di ripristino della password è stato correttamente inviato via email all’utente.

Potete anche inviare un link per la reimpostazione della password dalla schermata degli utenti.

Potete anche selezionare diversi utenti e inviare link per la reimpostazione della password in blocco.

Come accennato in precedenza, gli utenti riceveranno un’email contenente un link per la reimpostazione della password. L’immagine che segue mostra un’email di reimpostazione della password nello strumento Email Inbox di DevKinsta.

Gli sviluppatori possono utilizzare i filtri retrieve_password_title e retrieve_password_message per personalizzare l’oggetto e il messaggio dell’email.

Altri Miglioramenti per Sviluppatori

Nuove Funzioni per Passare Attributi ai Tag script

Diverse nuove funzioni permettono ora di passare attributi ai tag <script> (cioè async o nonce).

wp_get_script_tag()

wp_get_script_tag() carica un tag script formattato e inietta automaticamente l’attributo type se il tema non ha dichiarato il supporto ai tag HTML5 script. Accetta un array di coppie chiave-valore che rappresentano gli attributi da aggiungere al tag <script>.

Questa funzione fa coppia con il nuovo filtro wp_script_attributes, che può essere utilizzato per filtrare gli attributi.

wp_print_script_tag()

wp_print_script_tag() stampa un tag script formattato.

wp_get_inline_script_tag()

wp_get_inline_script_tag() include codice JavaScript in linea in un tag script.

Questa funzione ha un corrispondente hook wp_inline_script_attributes che filtra gli attributi da aggiungere a un tag script.

wp_print_inline_script_tag()

wp_print_inline_script_tag() stampa codice JavaScript in linea in un tag script.

wp_sanitize_script_attributes()

La nuova funzione wp_sanitize_script_attributes() è utilizzata per sanificare un array di attributi in una stringa di attributi. Questi possono poi essere aggiunti ad un tag script.

Si legga la nota di sviluppo per maggiori informazioni ed esempi.

Colori Standardizzati in WP-Admin

Parte di un progetto più ampio che mira a ripulire il CSS del pannello di amministrazione, WordPress ora usa una nuova palette di colori standardizzata per il WP-Admin. La nuova palette di colori include 12 sfumature di blu, verde, rosso e giallo. Aggiunge anche 13 sfumature di grigi, nero e bianco. Inoltre, soddisfa i requisiti minimi WCAG 2.0 recommended contrast ratio.

Nelle parole di Jean-Baptiste Audras:

La standardizzazione di questo set di colori aiuterà i contributor a prendere decisioni di design coerenti e accessibili. Gli sviluppatori di temi e plugin sono incoraggiati a utilizzare questa nuova palette di colori, per una migliore coerenza tra i loro prodotti e il Core di WordPress.

.

Costante WP_MEMORY_LIMIT in Site Health

La costante WP_MEMORY_LIMIT specifica la massima quantità di memoria che PHP può consumare.

Non inclusa anche nelle precedenti versioni di WordPress, la costante WP_MEMORY_LIMIT ora è stata aggiunta alla scheda Info in Salute del Sito.

Ulteriori novità per gli sviluppatori sono elencate in Modifiche varie focalizzate sugli sviluppatori e Modifiche alla REST API in WordPress 5.7. Troverete un elenco completo delle note di sviluppo in WordPress 5.7 Field Guide.

Riepilogo

La quota di mercato di WordPress continua a crescere ad un ritmo costante:

WordPress è utilizzato dal 64,4% di tutti i siti web di cui si conosce il content management system. Si tratta del 40,3% di tutti i siti web.

.
È una prova significativa della salute del CMS, soprattutto per coloro che basano il loro business su WordPress. E questo è anche un ottimo motivo per prestare attenzione a ciò che sta succedendo nell’ecosistema di WordPress.

WordPress 5.7 aggiunge un sacco di nuove funzionalità e miglioramenti sia per gli utenti che per gli sviluppatori, ma questo è solo un assaggio di ciò che possiamo aspettarci di vedere nel 2021.

Adesso tocca a voi. Ci siamo persi qualcosa di importante? Quali sono le vostre modifiche e e le funzionalità preferite di WordPress 5.7?