WordPress 5.8 “Tatum” è arrivato ed è una versione epocale. A parte l’incredibile numero di funzionalità, miglioramenti e correzioni di bug, WP 5.8 introduce un nuovo modo di costruire siti web con l’introduzione delle prime funzionalità che rientrano nel più ampio progetto noto come Full Site Editing.
Oltre al Full Site Editing, WordPress 5.8 ci porta tantissime modifiche e miglioramenti in diverse aree del CMS.
Gli utenti di WordPress che non utilizzano il plugin Gutenberg troveranno tutte insieme le funzionalità e i miglioramenti introdotti da ben nove versioni di Gutenberg (per un’analisi approfindita di ogni versione, si veda Gutenberg 9.9, 10.0, 10.1, 10. 2, 10.3, 10.4, 10.5, 10.6, 10.7).
Una novità importante per gli utenti che prendono sul serio le prestazioni dei propri siti è il supporto del formato WebP.
Gli sviluppatori apprezzeranno sicuramente la rimozione di IE11 dall’elenco dei browser supportati, la nuova configurazione dei blocchi e il meccanismo di configurazione e stile basato sul file theme.json, il migliorato sistema di registrazione dei blocchi basato sul file block.json e i molti miglioramenti alle API in arrivo con la seconda release del 2021.
Quindi, mettetevi comodi perché sarà una lunga carrellata di funzionalità e miglioramenti che aprono la strada a nuovi potenti strumenti di site-building che saranno progressivamente rilasciati nei prossimi mesi.
Funzionalità di Full Site Editing in WordPress 5.8
La visione alla base del Full Site Editing è quella di fornire un insieme di strumenti e funzionalità che permettano agli utenti di WordPress di costruire un intero sito web utilizzando i blocchi. Con il Full Site Editing, avremo a disposizione blocchi per creare qualsiasi elemento sulla pagina, dai menu di navigazione al site branding, dai widget della sidebar ai template e molto altro.
Anche se WordPress 5.8 introduce diverse funzionalità che rientrano nell’ambito del Full Site Editing (FSE), non possiamo aspettarci di vedere un ambiente di costruzione visiva del sito completa in tutte le sue funzionalità. Il FSE è ancora in pieno sviluppo, e il rilascio di WordPress 5.8 apre una sorta di fase beta pubblica. Secondo Josepha Haden Chomphosy:
Il full site editing è un insieme di progetti che insieme rappresentano un grande cambiamento, probabilmente troppo grande per una sola release. La cosa più importante da condividere è che non viene fornito come esperienza completa e predefinita per gli utenti. Uno dei feedback più chiari che abbiamo ricevuto durante la Fase Uno del processo di fusione è stato che non c’era abbastanza tempo per i nostri estensori (agenzie, autori di temi, sviluppatori di plugin, costruttori di siti, ecc) per prepararsi ai cambiamenti in arrivo.
Con questo bene in mente, il processo di fusione non porterà un interruttore on/off. Il focus ora non è tanto su un’esperienza utente completa e sfumata, ma più su una beta pubblica aperta all’interno di WordPress 5.8.
.
Al momento WordPress 5.8 non introduce un’esperienza FSE perfetta e completa. Piuttosto vedremo nuove funzionalità aggiunte e migliorate nel tempo, a partire proprio dalla versione 5.8. Per lo stesso motivo, possiamo presumere che WordPress 5.8 non avrà un impatto drastico sul modo in cui siamo abituati a costruire siti web.
Al momento in cui scriviamo, i proprietari di siti e gli amministratori devono ancora optare consapevolmente per l’FSE installando un tema a blocchi, come Twenty-Twenty One Blocks (la versione a blocchi di Twenty-Twenty One), e attivando il plugin Gutenberg.
Il Full Site Editing comprende una serie di sottoprogetti separati, tra cui Site Editor, Global Styles, Query block, Navigation block, Templates, temi a blocchi e molto altro. Ma la cosa più vicina al Site Editing in WordPress 5.8 è la Modalità di Template Editing e i corrispondenti Blocchi per i temi disponibili in questa modalità, come vedremo più avanti in questo articolo.
Dunque, immergiamoci nelle prime funzionalità del FSE confluite nel Core con WordPress 5.8.
Modalità di Template Editing
Il Template Editing Mode fornisce un modo per creare template di post e pagine utilizzando blocchi. È un ottimo modo per ridurre la complessità della costruzione di un sito, permettendo agli utenti di approfittare di diverse funzioni di modifica del sito dal di fuori dell’interfaccia dell’editor del sito, mentre ci si abitua a lavorare con i blocchi. È anche ottimo per gli utenti che non utilizzano temi basati su blocchi, ma cercano comunque un modo semplice per creare e modificare i template dall’interfaccia utente dell’editor di blocchi.
Personalizzare i temi non è mai stato così facile in WordPress. Ora non è più necessario creare un child theme per creare template personalizzati. Con WordPress 5.8, il Template Editing non è limitato ai temi a blocchi, ma è disponibile anche per i temi classici, anche se in quest’ultimo caso è necessario un opt-in per abilitarlo.
Per creare un nuovo template, è sufficiente attivare la modalità di modifica del template nella barra laterale delle Impostazioni. QUi è disponibile il nuovo pannello Template che permette agli utenti di cambiare la modalità di editing (si veda la nota di sviluppo di Gutenberg 10.5).
Dal pannello Template, è possibile creare un nuovo template o modificarne uno esistente.
Per creare un nuovo template, fate clic su Nuovo. Quindi inserite un nome per il template nel modale e poi su Crea, e siete pronti per le vostre modifiche.
Nella modalità di template editing, è possibile creare i propri template utilizzando tutti i blocchi disponibili, compresi i blocchi del FSE come Site Title, Site Tagline, Login/out e molti altri.
Una volta che si è soddisfatti delle modifiche, si può tornare alla modalità di editing del Post e salvare il template separatamente dal contenuto del post o della pagina, come mostrato nell’immagine qui sotto:
I template sono memorizzati nel database di WordPress come custom post type dal nome wp_template
. Questo non solo permette di modificare un template dall’interfaccia dell’editor, ma anche di importare o esportare facilmente i template. È anche possibile utilizzare un template su diversi siti web (al momento in cui scriviamo, questa funzionalità è disponibile solo attivando il plugin Gutenberg).
Mentre scriviamo, la modalità di Template Editing presenta ancora alcuni bug, come riportato in questo invito ai test e questo esperimento di Justin Tadlock.
Ma basta avere un po’ di pazienza e aspettare che i principali errori vengano risolti per comprendere appieno come il Template Editing cambierà il modo di personalizzare l’aspetto dei propri siti.
Gli utenti non avranno più bisogno di competenze da sviluppatore per avere il controllo completo sul layout e sull’aspetto generale del proprio sito web.
Il Template Editing era inizialmente disponibile sia per i temi a blocchi che per i temi classici. Dopo un’attenta discussione nel canale dei lead della versione 5.8, è stato deciso di rendere l’editor dei template opzionale per i temi classici e predefinito per i temi a blocchi (si veda anche pull #32858).
Secondo Carolina Nymark:
Inizialmente, la modifica dei template era abilitata per tutti i temi. Gli sviluppatori di temi hanno espresso la preoccupazione di non poter aggiornare tutti i loro temi classici esistenti per supportare questa nuova funzionalità. Con un cambiamento tardivo, la release squad e l’editor team hanno deciso di cambiare l’editing dei template rendendolo opzionale per i temi classici.
Per l’opt-in nei temi classici, ora gli sviluppatori dovrebbero aggiungere il supporto ai temi:
add_theme_support( 'block-templates' );
I temi classici che usano il theme.json possono rimuovere il supporto del tema come segue:
remove_theme_support( 'block-templates' );
Per una panoramica più dettagliata del Template Editing Mode in WordPress 5.8 e alcuni utili esempi di utilizzo, non perdete questo video di Anne McCarty:
Blocchi dei Temi
Come accennato in precedenza, il FSE non è una singola funzionalità, ma un insieme completo di funzioni di site-building che non sono solo legate all’editor del sito. Il Template Editing ne è solo un esempio. Ma, insieme al Template Editing, WordPress 5.8 introduce anche molti blocchi per i temi che permettono di visualizzare informazioni recuperate dinamicamente dal database. Alcuni di questi blocchi possono essere utilizzati anche in contesti diversi dal FSE (si veda la issue #28744).
I blocchi dei temi estendono le funzionalità dei template tag ai temi classici e si possono utilizzare allo stesso modo dei blocchi regolari. Ad esempio, è possibile aggiungere i tag del post o l’immagine di anteprima del post in qualsiasi punto del contenuto del post o del template. Per avere un’idea del numero di blocchi dei temi aggiunti al core con WordPress 5.8, basta digitare /post nel segnaposto del blocco:
Un utile blocco di tema disponibile con WordPress 5.8 è il blocco Login/out, che fornisce link di login e logout. Il blocco può anche essere configurato in modo da visualizzare il modulo di login invece di un link. Gli amministratori di siti WordPress possono anche personalizzare il target di redirect (vedi PR #29766).
Per un’analisi più approfondita dei blocchi del FSE, si veda “Enabling Full Site Editor blocks in classic themes” su Github.
Il Blocco Query Loop
Quante volte ci siamo trovati nella situazione di dover visualizzare una lista personalizzata di articoli del blog o di custom post type? Si pensi a elenchi di prodotti, di eventi, di immobili… Naturalmente, ci sono tantissimi plugin tra cui scegliere per creare simili liste, ma la capacità di creare query altamente personalizzate spesso richiede competenze da sviluppatore per cimentarsi con il Loop di WordPress.
Con l’introduzione del blocco Query Loop nel Core di WordPress, i proprietari e gli amministratori di siti possono creare elenchi di articoli e CPT senza scrivere codice complesso o dover assumere uno sviluppatore, almeno nei casi di utilizzo più comuni.
Dunque, cosa fa il blocco Query Loop?
In breve, fa lo stesso lavoro del Loop di WordPress, ma nel contesto visuale dell’editor di blocchi.
Il blocco Query Loop esegue sul database di WordPress una query basata sulle impostazioni dell’utente, esegue un loop su ogni post recuperato e visualizza i dati sulla pagina.
Dopo un intenso sviluppo, questo blocco ha raggiunto la sua struttura attuale e ora consiste di due blocchi annidati: i blocchi Query e Post Template.
Essendo una funzionalità avanzata, il blocco Query Loop richiede alcune configurazioni.
In primo luogo, è possibile scegliere tra diversi modelli di blocco (block pattern) visualizzati come Carousel e Griglia. Una volta scelto il modello, basta cliccare su Scegli, e il blocco Query Loop genererà un elenco personalizzato di post.
Facendo clic su Start blank, si vedrà una lista di quattro varianti Core del blocco: Titolo & Data; Titolo & Estratto; Titolo, Data & Campo; Immagine, Data & Titolo (si veda Offering Patterns on Block setup).
Una volta in posizione, selezionando il blocco Query Loop verrà visualizzata la barra laterale delle impostazioni del blocco, dove è possibile costruire la query. Si può ereditare la query dall’URL o personalizzare gli argomenti della query: il tipo di post da includere nella lista, l’ordine di visualizzazione e se avere o meno post fissi.
È anche possibile impostare diversi filtri, scegliendo tra categorie, autori e parole chiave.
Inoltre, un pulsante Impostazioni di Visualizzazione (Display settings) nella barra degli strumenti del blocco fornisce altre impostazioni che permettono di controllare il numero di elementi per pagina, l’offset e il numero massimo di pagine da mostrare.
In effetti il blocco Query Loop è uno strumento potente, che permette ai proprietari di siti di creare elenchi finemente personalizzati di post e custom post type.
Ma se si dà un’occhiata ai parametri della classe WP_Query, è chiaro che il livello di personalizzazione ottenibile utilizzando il codice è molto più granulare di quanto sia possibile utilizzando il blocco Query Loop.
Tuttavia, è davvero uno strumento prezioso e flessibile che si presta a svariati impieghi, e molto probabilmente vedremo ulteriori miglioramenti in futuro.
Persistent List View nell’Editor dei Post
Un’altra caratteristica dell’FSE estesa al Post Editor è la Persistent List View. Prima di WordPress 5.8 (e Gutenberg 10.7), la List View veniva visualizzata in un popover. Quando si spostava il focus fuori dal popover, l’elenco scompariva.
Al contrario, il Site Editor mostrava la List View in una barra laterale contenente l’intero albero dei blocchi.
Con WordPress 5.8, la List View è visualizzata in una barra laterale anche nel Post Editor, permettendo agli utenti di navigare nell’albero dei blocchi in modo più rapido e preciso.
Facendo clic su un elemento nella List View si evidenzia la voce dell’elenco e si sposta il focus sul blocco corrispondente nell’editor del Post. Inoltre, se si passa il mouse sopra gli elementi presenti nella List View, vengono evidenziati sia l’elemento che il blocco corrispondente nell’Editor del Post.
Infine, aggiungendo un’ancora a un blocco, questa apparirà anche accanto all’elemento corrispondente nella List View.
Con tutti questi miglioramenti alla List View, la navigazione di documenti complessi dovrebbe essere molto più semplice e rapida.
Widget Editor a Blocchi e Widget a Blocchi nel Customizer
L’editor a blocchi dei widget è un progetto di ampio respiro che mira a portare l’interfaccia dell’editor di blocchi ai widget dei temi classici.
Il nuovo editor di widget offre molti vantaggi a coloro che utilizzano ancora i temi classici, che sono ancora la grande maggioranza di utenti. Allo stesso tempo, permette loro di familiarizzare con l’interfaccia a blocchi prima che diventi standard per tutti gli utenti di WordPress.
Come sottolineato da Anne McCarty, i widget a blocchi forniscono diversi vantaggi, tra cui:
- È ora possibile creare layout nelle barre laterali, nelle intestazioni e nei footer utilizzando colonne, separatori, distanziatori e altri blocchi di design.
- I widget ora supportano di default il rich text editing, senza la necessità per gli utenti di aggiungere codice personalizzato o incorporare un editor HTML di terze parti con un plugin.
- Molti widget basati su shortcode sono ora disponibili come blocchi, semplificando così l’esperienza di editing.
Anche Andrei Draganescu sottolinea i vantaggi offerti dalla possibilità di modificare i widget da un’interfaccia basata sui blocchi:
Il vantaggio principale dell’aggiornamento della funzionalità dei widget ai blocchi deriva dalla possibilità di modificare direttamente i widget utilizzando la familiare interazione dei blocchi che si usa quando si modifica una pagina o un post sul proprio sito. Essere in grado di utilizzare i blocchi apre una moltitudine di nuove possibilità creative, dai mini layout senza codice alla disponibilità della vasta libreria di blocchi core e di terze parti per creare contenuti.
Non dovete preoccuparvi che i vostri widget possano smettere di funzionare con WordPress 5.8 perché la community ha lavorato duramente per garantire la retrocompatibilità in modo che “i widget esistenti e i widget di terze parti continuino a funzionare e possano essere utilizzati insieme ai blocchi” (si legga al riguardo Block-based widgets editor in WordPress 5.8).
Ma, di nuovo, per evitare qualsiasi problema di compatibilità sulla vostra installazione esistente di WordPress, prima di aggiornare il vostro sito live non dimenticate di testare la nuova versione in un ambiente di staging.
Per chi sceglie di non utilizzare subito l’editor di widget basato sui blocchi, è ancora possibile ripristinare la classica schermata dei Widgets in tre modi diversi:
- È possibile installare il plugin ufficiale Classic Widgets, che ripristina la precedente interfaccia della schermata dei widget. Il plugin “sarà supportato e mantenuto almeno fino al 2022, o per tutto il tempo necessario”.
- Gli sviluppatori di temi possono disabilitare l’editor di widget a blocchi rimuovendo il supporto del tema come al solito:
remove_theme_support( 'widgets-block-editor' );
- Si può utilizzare anche il nuovo filtro
use_widgets_block_editor
:add_filter( 'use_widgets_block_editor', '__return_false' );
Si veda anche Restoring the classic widgets editor in Widget Block Editor Overview.
Widget a Blocchi nel Customizer
Come parte dello stesso progetto, WordPress 5.8 porta anche i widget a blocchi nel customizer.
Aggiungere un widget a blocchi nel customizer è abbastanza semplice. È possibile lanciare il pannello di inserimento dei widget facendo clic sull’icona più (+) che si trova nell’angolo in alto a destra del pannello dei widget.
È anche possibile lanciare il quick inserter dalla parte inferiore del pannello dei widget, come mostrato nell’immagine che segue.
Al momento in cui si scrive questo articolo, la nuova interfaccia di modifica dei widget richiede ancora miglioramenti e correzioni di bug, ma le possibilità di personalizzazione sono praticamente illimitate.
Fondamentalmente, a partire da WordPress 5.8, si avrà a disposizione la potenza del block editor nel customizer, e si potranno creare senza difficoltà barre laterali altamente personalizzate.
La nota di sviluppo sull’editor di widget a blocchi fornisce una panoramica più approfondita sui widget a blocchi, con esempi e risorse per gli sviluppatori.
Funzionalità e Miglioramenti nell’Editor di Blocchi
Oltre alla prima implementazione dell’FSE, WordPress 5.8 porta con sé anche nuove funzionalità e modifiche a diversi elementi dell’editor di blocchi, che migliorano significativamente l’esperienza complessiva di editing.
Queste modifiche includono:
Miglioramenti al Blocco Media & Text
Trasformare un blocco in un blocco colonne è possibile da un po’ di tempo. Tuttavia, tutti i blocchi trasformati in blocchi colonne hanno una sola colonna. Questo potrebbe portare a risultati non ottimali per il blocco Media & Text, per il quale una singola colonna non è solitamente adatta.
A partire da WordPress 5.8 (e Gutenberg 10.2), la trasformazione del blocco Media & Text in un blocco colonne aggiunge automaticamente due colonne: una per l’immagine e una per il testo.
Miglioramenti ai Blocchi Riutilizzabili
I blocchi riutilizzabili permettono all’utente di salvare un blocco o un gruppo di blocchi per il successivo riutilizzo in qualsiasi post o pagina di un sito web. Questo è utile soprattutto per gli utenti che inseriscono ripetutamente lo stesso blocco o gruppo di blocchi in diversi post/pagine.
Con WordPress 5.8, i blocchi riutilizzabili sono visivamente più chiari e più facili da gestire per gli utenti di WordPress.
Ecco un rapido elenco di miglioramenti dei blocchi riutilizzabili che gli utenti troveranno dopo aver aggiornato i propri siti a WordPress 5.8:
- Quando si crea un blocco riutilizzabile, un modale permette ora agli utenti di assegnare un nome al blocco.
- Il nome del blocco riutilizzabile viene ora visualizzato nella barra degli strumenti del blocco, nell’elenco di navigazione e nei breadcrumb.
- I blocchi riutilizzabili vengono ora evidenziati quando viene selezionato un blocco figlio. Questo segna un miglioramento significativo nell’usabilità in quanto permette di identificare facilmente il blocco genitore e il suo contenuto.
- È ora possibile modificare il nome del blocco nell’ispector della barra laterale.
Toolbar dei Blocchi Normalizzate
Le barre degli strumenti di diversi blocchi sono state riorganizzate per fornire una UI coerente per tutti i blocchi e migliorare l’esperienza utente. Ora, i controlli delle barre degli strumenti sono raggruppati seguendo l’ordine semantico “meta, block-level, inline”.
A partire da Gutenberg 10.1 e Gutenberg 10.3, un intero set di barre degli strumenti di blocchi è stato normalizzato. Tra questi ricordiamo i blocchi immagine, pulsante, pulsanti, lista, titolo, paragrafo, citazione, audio, file, media & testo, video, e altro.
Secondo Matias Ventura:
I raggruppamenti semantici che abbiamo nella barra degli strumenti – meta, block level, inline – dovrebbero avere anche una rappresentazione visiva con i bordi. In questo momento controlli separati a livello di blocco hanno rappresentazioni diverse, compresi casi come il blocco Navigation, in cui ogni singolo controllo ha dei bordi.
.
Così, a partire da WordPress 5.8, la toolbar dei blocchi raggruppa i controlli in segmenti circondati da bordi. Inoltre:
- Il segmento Meta contiene controlli legati al tipo di blocco, come il commutatore di blocco, la maniglia di trascinamento e il controllo di movimento.
- Il segmento Block level contiene strumenti specifici del blocco che influenzano l’intero contenuto, come l’allineamento in un blocco paragrafo o il link in un blocco immagine.
- Il segmento Inline level/Altro contiene strumenti di trasformazione in linea, come la formattazione in linea in un blocco di testo.
- Il menu More contiene strumenti aggiuntivi.
L’immagine qui sotto mette a confronto la barra degli strumenti del blocco immagine in WordPress 5.7 e 5.8:
Miglioramenti alla Barra degli Strumenti Superiore
Nelle precedenti versioni di WordPress, con la modalità top toolbar attiva, la barra degli strumenti superiore e la barra degli strumenti dei blocchi venivano visualizzate fianco a fianco, come mostrato nella seguente immagine:
Con WordPress 5.8, l’abilitazione della visualizzazione della barra degli strumenti superiore fisserà la barra degli strumenti a blocchi nella parte superiore dell’editor, proprio sotto la top toolbar. Questo avviene indipendentemente dalla larghezza della finestra del browser e dovrebbe migliorare significativamente l’esperienza utente.
Questo miglioramento porta anche delle novità per gli sviluppatori in quanto unifica le API della barra degli strumenti nel componente <BlockTools />
(vedi PR #31134).
PDF Incorporati
Quando viene aggiunto al documento un file PDF attraverso il blocco file, un nuovo interruttore nella barra laterale permette di abilitare/disabilitare una versione incorporata del PDF (si veda PR #30857).
È possibile trascinare il file direttamente sull’area di editing dell’editor o semplicemente selezionarlo dalla libreria. È anche possibile regolare manualmente l’altezza del visualizzatore del PDF o utilizzando il controllo della barra laterale.
Tutti i principali browser web supportano il visualizzatore PDF, eccetto i browser mobili.
Bicromia dei Blocchi (Duotone)
Una delle funzionalità più interessanti confluite nel Core con WordPress 5.8 è il filtro a due tonalità, introdotto per la prima volta con Gutenberg 10.6.
Disponibile come funzione “block supports”, il filtro bicromia è abilitato di default nei blocchi core immagine e cover. Nel blocco cover, però, non funziona con gli sfondi fissi.
Le barre degli strumenti dei blocchi immagine e copertina ora mostrano un controllo Applica filtro bicromia che mostra un selettore di bicromia con molte combinazioni predefinite tra cui scegliere.
Due sottocontrolli permettono di personalizzare separatamente le ombre e le luci. L’effetto è applicato con un filtro SVG nascosto con stili in linea e applicato utilizzando un nome di classe specifico.
Il nuovo strumento arriva in coppia con la nuova proprietà color.__experimentalDuotone
, che permette agli sviluppatori di aggiungere il filtro bicromia a blocchi o parti di blocchi nel file block.json (maggiori informazioni su questo punto in color object reference):
supports: {
color: {
__experimentalDuotone: '> .duotone-img, > .duotone-video',
background: false,
text: false
}
}
Quando un blocco dichiara il supporto per color.__experimentalDuotone
, può essere utilizzato l’attributo style
per impostare colori predefiniti personalizzati:
attributes: {
style: {
type: 'object',
default: {
color: {
duotone: [
'#FFF',
'#000
]
}
}
}
}
Qui sotto si vede la stessa immagine con due diversi effetti di bicromia:
Gli sviluppatori possono definire i set predefiniti di bicromia nel file theme.json (si veda la sezione successiva), come mostrato nel seguente snippet:
{
"version": 1,
"settings": {
"color": {
"duotone": [
{
"colors": [ "#000", "#7f7f7f" ],
"slug": "black-and-white",
"name": "dark-grayscale"
}
],
...
Per approfindire il discorso sui filtri bicromia, si legga Coloring Your Images With Duotone Filters.
Colori e Bordi nel Blocco Tabella
WordPress 5.8 porta anche alcuni miglioramenti al blocco Tabella, tra cui un migliore controllo sui colori di sfondo e di primo piano della tabella.
Un’altra aggiunta al blocco Tabella è il supporto dei bordi del blocco, che dà agli utenti la possibilità di controllare il colore, lo stile e la larghezza dei bordi.
Se il tema attivo supporta la nuova funzionalità, un nuovo pannello di configurazione dei bordi fornisce tre nuovi controlli per le personalizzazioni dell’utente.
Gli sviluppatori possono aggiungere il supporto dei bordi del blocco ai loro temi aggiungendo il seguente codice al file theme.json:
"border": {
"customColor": true,
"customStyle": true,
"customWidth": true
}
Miglioramenti al Block Inserter
In WordPress 5.8, il pannello di inserimento dei blocchi è stato migliorato con diverse aggiunte (PR #26938 e #21080):
1. Navigazione in due dimensioni da tastiera sul pannello di inserimento dei blocchi. Ora è possibile navigare tra i blocchi in modo più preciso e intuitivo.
- Premendo la freccia su (↑) e la freccia giù (↓) si sposta il focus sulla riga superiore o inferiore.
- Premendo Tab o Maiusc + Tab è possibile spostare il focus tra la casella di ricerca, la lista delle schede e la prima voce di ogni categoria.
.
2. In Full Site Editing adesso appare nel pannello di inserimento una nuova categoria “Tema” per le parti e le varianti dei template (vedi PR #30020).
3. Sono ora permesse parole multiple nel suggerimento di ricerca (vedi PR #29939).
Altri Miglioramenti dell’Editor di Blocchi
WordPress 5.8 introduce moltissimi cambiamenti piccoli e medi che meritano un riferimento. Tra questi miglioramenti, citiamo i seguenti:
Supporto del Drag and Drop nei Blocchi Copertina
Ora è possibile trascinare le immagini dal desktop per sostituire lo sfondo di un blocco copertina (vedi Gutenberg 10.3 e PR #29813).
UI di Pubblicazione Migliorata
A partire da WordPress 5.8, l’interfaccia di pubblicazione mostra l’icona del sito e il titolo per rendere più chiaro dove si stanno pubblicando i propri post o pagine (Gutenberg 10.4).
Questo novità è utile soprattutto se si lavora in modalità a schermo intero o su dispositivi mobili.
Impostazioni e Stili dei Blocchi con il File theme.json
Con WordPress 5.8, il file theme.json diventa “un punto centrale di configurazione”, offrendo agli sviluppatori di temi un nuovo modo per personalizzare le impostazioni e gli stili dell’editor.
Con il file theme.json, i temi possono impostare preset personalizzati e/o aggiungere il supporto di nuove funzionalità, come la bicromia e i bordi delle tabelle (vedi Global Settings & Styles).
Secondo André Maneiro:
Questo nuovo meccanismo mira a riprendere e consolidare tutte le varie chiamate
add_theme_support
che erano precedentemente necessarie per controllare l’editor.
Ad esempio, è possibile impostare globalmente un preset personalizzato di bicromia con il seguente codice:
{
"version": 1,
"settings": {
"color": {
"duotone": [
{
"colors": [ "#000", "#0FF" ],
"slug": "black-cyan",
"name": "Black Cyan"
}
],
Questo codice sovrascriverebbe i preset predefiniti, e offrirà all’utente una sola opzione di bicromia:
Il nuovo meccanismo fornisce un modo per controllare le impostazioni sia a livello globale che in base al blocco. Ad esempio, è possibile aggiungere una dimensione di font personalizzata di 12px a livello globale aggiungendo il seguente preset al file theme.json:
{
"version": 1,
"settings": {
"typography": {
"customLineHeight": true,
"fontSizes": [
{
"slug": "extra-extra-small",
"size": "12px",
"name": "Extra extra small"
},
{...}
Questo si traduce in una nuova dimensione di font che gli utenti possono utilizzare nel proprio contenuto con qualsiasi blocco di testo.
Se si vuole personalizzare solo il blocco paragrafo, il codice sarà leggermente diverso:
{
"version": 1,
"settings": {
"blocks": {
"core/paragraph": {
"typography": {
"fontSizes": [
{
"slug": "extra-extra-small",
"size": "12px",
"name": "Extra extra small"
},
{
"slug": "extra-small",
"size": "16px",
"name": "Extra small"
},
{
"slug": "small",
"size": "18px",
"name": "Small"
},
{
"slug": "normal",
"size": "20px",
"name": "Normal"
},
{
"slug": "large",
"size": "24px",
"name": "Large"
}
]
}
}
}
}
}
Ecco fatto! Avete appena impostato i vostri preset personalizzati delle dimensioni del font sul blocco paragrafo.
I blocchi core sono stati adeguati al nuovo meccanismo, mentre i blocchi di terze parti possono adattarsi al nuovo sistema utilizzando l’hook di React useSetting
(si legga di più su questa funzione nella nota di sviluppo e nella documentazione dell’API):
const isEnabled = useSetting( 'spacing.margin' );
Il nuovo meccanismo basato sul file theme.json non si applica solo alle impostazioni di blocco. Infatti, a partire da WordPress 5.8, non sarà più necessario creare stili per l’editor ed accodarli. Sarà sufficiente dichiarare dei preset all’interno del file theme.json; il motore genererà le classi e le accoderà automaticamente sia per l’editor che per il frontend.
Il motore genererà anche le corrispondenti Proprietà CSS Personalizzate.
Nell’esempio precedente, abbiamo impostato cinque fontSizes
per il blocco paragrafo. Per queste impostazioni, verranno generate le seguenti proprietà CSS personalizzate:
p {
--wp--preset--font-size--extra-extra-small: 12px;
--wp--preset--font-size--extra-small: 16px;
--wp--preset--font-size--small: 18px;
--wp--preset--font-size--normal: 20px;
--wp--preset--font-size--large: 24px;
}
Una volta che è stata impostata la dimensione del carattere del paragrafo nel file theme.json, il corrispondente elemento p
prenderà la classe has-{preset-slug}-{preset-category}
.
Questo significa che un paragrafo con una dimensione del carattere extra-extra-small
avrà la classe has-extra-extra-small-font-size
:
<p class="has-extra-extra-small-font-size">Lorem ipsum dolor...</p>
Ed ecco il blocco di dichiarazioni CSS:
p.has-extra-extra-small-font-size {
font-size: var(--wp--preset--font-size--extra-extra-small) !important;
}
Per un’analisi più dettagliata delle impostazioni e degli stili tramite il file theme.json, si legga la nota di sviluppo e la documentazione dell’API.
Infine, si dia anche un’occhiata all’call for testing per il FSE di Anne McCarty per un’utile lettura e un’interessante sfida per gli sviluppatori che vogliono esplorare le nuove funzionalità del file theme.json.
Miglioramenti delle API dei blocchi
Meritano particolare attenzione da parte degli sviluppatori di plugin i miglioramenti delle API dei blocchi in arrivo con WordPress 5.8.
È ora incoraggiato l’utilizzo del file block.json come metodo canonico per registrare i tipi di blocco. Il nuovo metodo offre diversi vantaggi:
- Per quanto riguarda le prestazioni, se il tema supporta il lazy loading delle risorse, la registrazione dei tipi di blocco attraverso il file block.json ne ottimizza automaticamente l’accodamento. Questo perché le risorse specificate dalle proprietà
style
escript
saranno messe in coda sul frontend solo quando viene rilevato il blocco. Questo permette lo sviluppo di plugin più efficienti, riduce la dimensione delle pagine e previene molti dei problemi trattati in questo articolo. - Il file block.json semplifica la registrazione dei blocchi lato server permettendo al REST API Endpoint dei Tipi di Blocco di listare il blocco.
- Il file block.json è necessario se si decide di presentare il plugin del blocco nella Directory dei Plugin di WordPress.
Modifiche alla Funzione register_block_type
A partire da WordPress 5.8, la funzione register_block_type
è stata migliorata in modo da leggere i metadati dal file block.json. Ora, il primo parametro della funzione accetta il percorso della cartella dove si trova il file block.json.
La funzione può essere utilizzata come mostrato nel seguente esempio:
function create_custom_block_init() {
register_block_type( __DIR__ );
}
add_action( 'init', 'create_custom_block_init' );
La funzione restituisce il tipo di blocco registrato o false
in caso di insuccesso.
Come si può notare, la funzione register_block_type
è ora utilizzata allo stesso modo della funzione register_block_type_from_metadata
, che in precedenza era l’unica funzione disponibile per registrare un tipo di blocco leggendo i metadati dal file block.json. Come spiegato da Greg Ziółkowski:
Abbiamo deciso di consolidare nella funzione
register_block_type
la preesistente funzionalità disponibile con il metodoregister_block_type_from_metadata
per evitare una certa confusione che si era creata. È possibile utilizzare entrambe le funzioni, ma d’ora in poi abbiamo intenzione di usare nei documenti e strumenti ufficiali solo la versione più corta.
.
Una volta che il blocco è registrato sul server, bisogna solo registrare le impostazioni sul client utilizzando lo stesso nome del blocco nel file index.js.
Per una panoramica più approfondita dei miglioramenti alle API dei Blocchi introdotti da WordPress 5.8, si legga la nota di sviluppo di Greg Ziółkowski.
Supporto WebP in WordPress 5.8
Da Kinsta siamo ossessionati dalla velocità dei siti web e dalle prestazioni di WordPress. Ecco perché è così entusiasmante per noi la notizia del supporto del formato WebP in WordPress 5.8.
Considerato un formato di ultima generazione, WebP è un formato immagine sviluppato da Google per offrire “una migliore compressione rispetto a PNG o JPEG, il che significa download più veloci e minore consumo di dati.”
Secondo la definizione di Google:
WebP è un moderno formato immagine che offre una compressione lossless e lossy superiore per le immagini sul web. Grazie a WebP, i webmaster e gli sviluppatori web possono creare immagini più piccole e più ricche che rendono il web più veloce.
Le immagini WebP lossless sono più piccole del 26% rispetto alle PNG. Le immagini WebP lossy sono più piccole del 25-34% rispetto alle immagini JPEG comparabili con un indice di qualità SSIM equivalente.
A partire da WordPress 5.8, è possibile usare il formato immagine WebP allo stesso modo dei formati JPEG, PNG e GIF. Basta caricare le immagini nella Libreria Media e inserirle nei contenuti.
In un articolo precedente, abbiamo analizzato in modo approfondito il formato WebP e gli strumenti disponibili per utilizzarlo in WordPress. Ora, per via del supporto delle immagini WebP in WordPress 5.8, le cose potrebbero cambiare un po’. Dato che il formato WebP è supportato nativamente, non è necessario installare plugin di terze parti per caricare immagini WebP in WordPress, almeno nei casi d’uso più frequenti.
Si noti che, anche se ora è possibile caricare le immagini WebP su WordPress utilizzando la Libreria Media, WordPress non supporta la conversione automatica delle immagini in formato WebP. Per abilitare questa funzionalità, si avrà ancora bisogno di un plugin WebP per WordPress plugin di terze parti.
Come Utilizzare le Immagini WebP in WordPress
È possibile convertire le immagini in WebP in molti modi:
- Si possono utilizzare le utility e la libreria WebP precompilata di Google per Linux, Windows o Mac OS X.
- Gli utenti Mac possono installare un gestore di pacchetti come il pacchetto WebP di Homebrew o il pacchetto Macports WebP.
- Si può utilizzare uno strumento di editing delle immagini che supporti WebP, come Squoosh di Google Chrome Labs, il convertitore di immagini batch XnConvert, un popolare editor di immagini come GIMP e molti altri.
- È possibile installare un plugin WebP per WordPress per avere un maggiore controllo generale sulle immagini WebP in WordPress.
Se optate per uno strumento a riga di comando, potete codificare e decodificare le vostre immagini utilizzando le utility cwebp e dwebp. Ad esempio, il seguente comando esegue una conversione base da JPEG a WebP:
cwebp [options] original_image.jpg -o compressed_image.webp
È anche possibile eseguire una conversione in blocco delle immagini utilizzando Bash e cwebp
(esempio di Jeremy Wagner):
find ./ -type f -name '*.png' -exec sh -c 'cwebp -q 75 $1 -o "${1%.png}.webp"' _ {} \;
Il comando qui sopra converte tutte le immagini .png in formato .webp con un fattore di compressione di 75.
Una volta che sia hanno a disposizione le immagini WebP, basta semplicemente caricarle dalla Libreria Media di WordPress. Qui sotto si può vedere un’immagine JPEG da 127 KB nella Libreria Media prima della conversione:
La dimensione dell’immagine compressa WebP è del 42% più piccola dell’immagine JPEG originale!
Infine, le immagini WebP dispongono delle stesse funzionalità di editing delle immagini JPEG, PNG e GIF. È possibile ritagliarle, ruotarle, capovolgerle e scalarle e applicare le modifiche alle dimensioni dell’immagine.
Avvertenze su WebP in WordPress 5.8
Secondo Adam Silverstein,
Le immagini WebP supportano la compressione lossy e lossless, un formato animato e le immagini trasparenti. In WordPress, il formato WebP lossless è supportato solo quando il server di hosting utilizza Imagick (la libreria PHP) finché non sarà aggiunto il supporto in LibGD. Inoltre, i formati animati e alfa non sono ancora supportati per le immagini ridimensionate (quando si caricano immagini in questi formati vengono invece create immagini lossy).
Se il web host non supporta le immagini WebP, quando si cercherà di caricarle si riceverà un messaggio di errore. Se non si è sicuri che il proprio host web supporti la libreria Imagick, la scheda Info del Site Health contiene un campo Libreria Imagick che fornisce questa informazione.
Con il supporto del formato WebP, WordPress 5.8 introduce anche due campi aggiuntivi alla sezione Gestione Media in Site Health: Versione Imagick e Formati file supportati da ImageMagick.
Se WebP non è nell’elenco dei tipi di file supportati, bisognerà contattare il proprio host web per chiedere supporto.
La nota di sviluppo fornisce informazioni aggiuntive sul supporto del formato WebP in WordPress 5.8, con utili FAQ e ulteriori risorse.
Chi è interessato all’ottimizzazione delle immagini, potrebbe apprezzare anche i seguenti tutorial:
- Come Ottimizzare le Immagini per il Web e le Prestazioni
- Perché e Come Utilizzare la Compressione Lossy sulle Immagini di WordPress
- Come Utilizzare le Immagini WebP in WordPress (e Ridurre le Dimensioni dei File Immagine Fino al 35%)
- I 15 Migliori Tipi di File Immagine
- Tutto Quello che c’è da Sapere sulle Dimensioni delle Immagini di WordPress
Altre Funzionalità per Sviluppatori
Ci sono decine di funzionalità interessanti per sviluppatori in WordPress 5.8. In questo articolo abbiamo prestato più attenzione a quelle che dovrebbero avere l’impatto più significativo sul lavoro di sviluppo. Ma ci sono davvero molte nuove funzionalità che meritano attenzione, tra cui le seguenti:
Block Supports API
WordPress 5.8 aggiunge nuovi flag di supporto dei blocchi che permettono agli sviluppatori di personalizzare i blocchi registrati con le ultime funzionalità dei blocchi.
Oltre allo sperimentale supporto al bicromia dei blocchi di cui si è parlato in precedenza (color._experimentalDuotone
), WordPress 5.8 aggiunge anche il supporto per il colore dei link. Per sfruttare questa funzionalità, basta aggiungere il seguente flag ai metadati del blocco:
supports: {
color: {
link: true;
}
}
È possibile impostare valori predefiniti utilizzando gli attributi, come mostrato nel seguente esempio, o impostare i propri preset nel file theme.json:
attributes: {
style: {
type: 'object',
default: {
color: {
link: '#FF0000',
}
}
Tra le altre modifiche all’API dei blocchi ricordiamo:
fontSize
elineHeight
sono diventati stabili.il supporto per la spaziatura
è stato esteso e ora è possibile controllaremargin
epadding
, così come controllare individualmente le dimensionitop
,right
,bottom
eleft
.
.
Maggiori informazioni sulla Block Supports API in WordPress 5.8 sono nella nota di sviluppo Block supports API updates.
Per una visione più ravvicinata all’utilizzo della Block Supports API, si faccia riferimento alla documentazione ufficiale della Block Supports API.
Schede Personalizzate in Salute del Sito
Due nuovi hook ora permettono agli sviluppatori di aggiungere schede personalizzate all’interfaccia di Salute del Sito e personalizzare le schermate disponibili.
Il filtro site_health_navigation_tabs
è un array associativo di ID di schede ed etichette che permette di registrare una nuova scheda nella schermata Salute del Sito. È possibile utilizzare il filtro aggiungendo il seguente codice di esempio al file functions.php del tema o ad un plugin personalizzato:
function kinsta_site_health_navigation_tabs( $tabs ) {
$tabs['kinsta-site-health-tab'] = esc_html_x( 'Kinsta', 'Site Health', 'text-domain' );
return $tabs;
}
add_filter( 'site_health_navigation_tabs', 'kinsta_site_health_navigation_tabs' );
L’immagine qui sotto mostra la nuova scheda Salute del Sito:
Inoltre, grazie al filtro site_health_navigation_tabs
, è possibile riordinare le schede o rimuovere uno o più elementi.
L’azione site_health_tab_content
si attiva quando un utente visita la schermata Salute del Sito, ad eccezione della schermata predefinita Stato. È possibile utilizzare questo hook come mostrato nel seguente frammento di codice (esempio tratto dalla nota di sviluppo):
function kinsta_site_health_tab_content( $tab ) {
// Return if this is not your tab.
if ( 'kinsta-site-health-tab' !== $tab ) {
return;
}
// Include the interface, kept in a separate file just to differentiate code from views.
include trailingslashit( plugin_dir_path( __FILE__ ) ) . 'views/kinsta-site-health-tab.php';
}
add_action( 'site_health_tab_content', 'kinsta_site_health_tab_content' );
QUesto codice rileva in primo luogo se la scheda corrente è la scheda personalizzata, poi carica il contenuto della schermata Salute del Sito da un file .php. L’azione site_health_tab_content
permette agli sviluppatori anche di estendere la scheda predefinita Info aggiungendo informazioni specifiche ai propri temi o plugin.
Modifiche alla Block Editor API per il Supporto in Diverse Pagine di Amministrazione
Con WordPress 5.8, il post editor non è più l’unica pagina di amministrazione ad utilizzare l’editor di blocchi (la schermata dei widget è un esempio).
I core contributor hanno trovato diversi hook definiti sul server che dipendono dall’oggetto $post
. Questo oggetto non è presente nelle schermate di modifica del sito, dei widget e di navigazione. Andando avanti, diversi filtri sono stati deprecati e sostituiti con alternative in grado di rilevare il contesto.
Inoltre, è stata introdotta la nuova classe WP_Block_Editor_Context
che rappresenta il contesto corrente dell’editor di blocchi e diversi metodi.
Queste modifiche migliorano le schermate con nuove funzionalità e permettono agli sviluppatori di aggiungere le loro personalizzazioni.
Per un elenco completo delle modifiche all’API del Block Editor relative alle pagine di amministrazione, si veda la nota di sviluppo di Greg Ziółkowski.
Ulteriori Funzionalità e Miglioramenti
Ci sono tantissime nuove funzionalità e aggiunte per gli sviluppatori introdotte da WordPress 5.8 che sarebbe impossibile per noi menzionarle tutte in questo articolo. Ma abbiamo raccolto una lista di note di sviluppo non trattate in questo articolo per ulteriori letture:
- Dropping support for Internet Explorer 11
- Block-styles loading enhancements in WordPress 5.8
- Blocks in an iframed (template) editor
- On layout and content width in WordPress 5.8
- Introducing “Update URI” plugin header in WordPress 5.8
- Various Block Editor API removals in WordPress 5.8
- REST API Changes in WordPress 5.8
- Miscellaneous developer focused changes in WordPress 5.8
- Miscellaneous block editor API additions in WordPress 5.8
Riepilogo
WordPress 5.8 segna una pietra miliare sulla strada verso il Full Site Editing. Ma la seconda release dell’anno porta molto più del FSE. Gli utenti e gli sviluppatori troveranno una quantità di miglioramenti all’editor di blocchi, un nuovo meccanismo basato sul file theme.json, una Block API più potente, il supporto del formato immagine WebP e molto altro.
Siamo stati particolarmente colpiti dai tanti miglioramenti, piccoli e grandi, all’editor di blocchi e alla sua UI. Ci piace moltissimo la migliore navigabilità tra i blocchi, la toolbar dei blocchi rinnovata, la maggiore chiarezza dell’interfaccia e i miglioramenti a diversi blocchi.
Questi piccoli cambiamenti migliorano l’esperienza di editing poco a poco, e, senza quasi rendercene conto, ci ritroviamo ad usare un software migliore e più robusto. Questo è WordPress!
Adesso tocca a voi! Cosa pensate del Full Site Editing? E quali sono le novità che preferite in WordPress 5.8?
Lascia un commento