Il rilascio di WordPress 7.1 è previsto per il 19 agosto e si preannuncia come un aggiornamento entusiasmante per sviluppatori, professionisti, agenzie e blogger di tutto l’ecosistema.
Questa seconda versione importante dell’anno introduce una vasta gamma di aggiornamenti che coprono quasi ogni aspetto del CMS. Tra le nuove funzionalità, quella che ci entusiasma di più è l’elaborazione dei media lato client. Il motivo è che qui a Kinsta siamo ossessionati dalle prestazioni web e dalla velocità dei siti, e questa nuova architettura multimediale segna un significativo passo avanti, offrendo miglioramenti evidenti nell’efficienza del server e tempi di caricamento delle pagine più rapidi.
Oltre alla gestione dei media, WordPress 7.1 apporta notevoli miglioramenti alla collaborazione in team, tra cui nuove funzionalità per le note, oltre a diverse rifiniture dell’interfaccia utente nella bacheca, come la barra di amministrazione sempre visibile e la nuova schermata “Identità” nell’Editor del sito. Il rilascio include blocchi nuovi e aggiornati, strumenti di progettazione ampliati e una vasta gamma di aggiornamenti per gli sviluppatori.
Vuoi scoprire cosa ci aspetta? Diamo un’occhiata a WordPress 7.1.
Elaborazione dei file multimediali lato client
Fino a WordPress 7.0, la generazione delle dimensioni delle immagini e delle miniature da visualizzare sul frontend, la conversione dei formati e la gestione della rotazione delle immagini venivano gestite tutte lato server tramite PHP.
Ora, WordPress 7.1 introduce una nuova architettura di elaborazione dei media: il ridimensionamento delle immagini, la conversione dei formati, la rotazione EXIF e la generazione delle miniature avvengono ora sul lato client, direttamente nel browser dell’utente.
Questo cambiamento dovrebbe migliorare notevolmente le prestazioni del sito e ridurre il consumo di risorse del server.
Diamo un’occhiata più da vicino a cosa cambia nell’elaborazione delle immagini:
1. Cos’è l’elaborazione dei media lato client?
Mentre prima le immagini venivano elaborate sul server da PHP utilizzando le librerie GD o Imagick, ora la generazione di immagini in varie dimensioni, la conversione dei formati e la rotazione EXIF avvengono direttamente nel browser dell’utente, a condizione che il browser supporti l’intestazione DIP ( Document-Isolation-Policy ) per consentire l’accesso a SharedArrayBuffer.
Dato che l’elaborazione avviene nel browser, WordPress non riceve più una sola immagine, ma tutti i file immagine risultanti dalla pipeline di elaborazione. Questo ha due effetti principali: un minore utilizzo della CPU e della RAM del server e un numero maggiore di richieste HTTP per caricare le singole miniature.
Al momento della stesura di questo articolo, solo Chrome 137 e Microsoft Edge 137 (versione desktop) supportano pienamente Document-Isolation-Policy. Safari e Firefox non supportano la pipeline WASM, anche se Safari supporta la decodifica nativa dei formati HEIC/HEIF in JPG.
2. Quali sono le caratteristiche tecniche dell’elaborazione multimediale lato client?
Dal punto di vista dell’architettura, l’elaborazione dei media lato client è gestita tramite 3 pacchetti principali:
- Il nuovo pacchetto
@wordpress/vipsgestisce l’elaborazione lato client utilizzando la librerialibvipscompilata in WebAssembly (wasm-vips). Considerata da molti una delle librerie di elaborazione delle immagini più veloci ed efficienti disponibili, funziona in parallelo all’interno di un Web Worker, evitando il blocco dell’interfaccia utente e offrendo prestazioni nettamente migliori rispetto al puro JavaScript. - Il pacchetto
@wordpress/upload-mediagestisce l’intero flusso di caricamento, inclusa la gestione delle code di caricamento, la concorrenza dei caricamenti (fino a 5 caricamenti simultanei e 2 operazioni di elaborazione delle immagini), i tentativi automatici, il ripristino dei caricamenti interrotti e il supporto offline. - Il pacchetto
@wordpress/media-utilsgestisce il trasporto HTTP e le richieste all’API REST.
Oltre all’elaborazione delle immagini, questa nuova funzionalità introduce la conversione automatica delle GIF animate in video MP4/WebM. La conversione è gestita dal nuovo pacchetto @wordpress/video-conversion, che avvolge la libreriamediabunny in un Web Worker per convertire le GIF opache (senza sfondi trasparenti) in file video leggeri.
L’elaborazione multimediale lato client introduce anche nuovi endpoint dell’API REST (sideload, finalize e replace_file) insieme a 2 nuovi parametri: generate_sub_sizes e convert_format.
3. Quali sono i vantaggi per gli utenti di WordPress?
L’elaborazione multimediale lato client sposta l’elaborazione delle immagini dal server al client. Questo libera il server dal pesante carico di lavoro legato alla generazione di miniature in varie dimensioni, alla rotazione delle immagini e alla conversione dei formati, trasferendo tale lavoro direttamente al browser dell’utente.
Ecco alcuni dei vantaggi per gli utenti derivanti dal trasferire l’elaborazione dei file multimediali al client:
- Meno errori di memoria insufficiente in PHP: l’elaborazione dei media lato client elimina gli errori di esaurimento della memoria (
PHP memory limit exceeded) che prima si verificavano durante l’elaborazione di file immagine di grandi dimensioni. - Minor consumo di CPU e RAM: un altro grande vantaggio per il server è la notevole riduzione dell’utilizzo di CPU e RAM dell’host, che libera risorse per altre attività.
- Migliori prestazioni del sito: la libreria
libvipsutilizza algoritmi di compressione avanzati che producono immagini che, in media, sono circa il 15% più piccole di quelle generate da GD o Imagick. Questo si traduce in immagini più leggere e tempi di caricamento delle pagine più rapidi. - Maggiore affidabilità nel caricamento: ogni caricamento di immagine richiede una richiesta HTTP indipendente. Questo comporta un volume maggiore di richieste HTTP, ma garantisce che ogni immagine venga elaborata in modo indipendente. Le richieste non andate a buon fine vengono automaticamente messe in pausa e riprovate.
Inoltre, le GIF animate possono essere convertite automaticamente in video con riproduzione automatica più efficienti, le foto HEIC caricate dagli iPhone possono essere convertite in JPG dal browser prima del caricamento (aggirando potenziali problemi di compatibilità del server), e il supporto AVIF ora funziona anche senza funzionalità AVIF lato server (il controllo del tipo MIME viene bypassato per i caricamenti decodificati dal client).
4. Cosa cambia per sviluppatori e sviluppatrici?
Chi si occupa di sviluppo può disattivare l’elaborazione dei media lato client utilizzando il nuovo filtro wp_client_side_media_processing_enabled. Ecco un esempio:
add_filter( 'wp_client_side_media_processing_enabled', '__return_false' );Oltre a questo, non ci sono grandi cambiamenti per chi sviluppa plugin. Gli hook associati all’elaborazione dei media continuano a funzionare proprio come se le immagini fossero elaborate sul server.
I filtri esistenti leggono le impostazioni dal server e continuano a funzionare come previsto. Ad esempio, il filtro wp_generate_attachment_metadata viene eseguito due volte: la prima durante il caricamento iniziale (create) e la seconda dopo la chiamata all’endpoint di finalizzazione (update). I plugin che utilizzano questo filtro continueranno a funzionare come previsto.
Per chi sviluppa temi, le dimensioni delle immagini registrate tramite add_image_size() vengono ora generate sul lato client. Se un tema definisce una dimensione dell’immagine con misure identiche a quelle predefinite di WordPress, le immagini vengono “deduplicate” in un unico file immagine registrato con entrambi i nomi delle dimensioni.
5. Quali sono i vantaggi in termini di sicurezza?
Sebbene l’elaborazione dei media lato client sia pensata principalmente per le prestazioni e l’efficienza piuttosto che per la sicurezza, offre diversi vantaggi che migliorano la sicurezza dei siti WordPress.
Innanzitutto, riduce la superficie di attacco. Come accennato prima, prima di WordPress 7.1, l’elaborazione delle immagini si basava su librerie lato server come GD e Imagick. Nel corso del tempo, queste librerie sono state colpite da varie vulnerabilità di sicurezza legate alla decodifica delle immagini.
Con l’elaborazione delle immagini lato client, il server non ha più bisogno di GD o Imagick perché riceve immagini già pre-elaborate. Questo riduce significativamente la quantità di codice sensibile eseguito sul server.
Un altro vantaggio in termini di sicurezza è che l’elaborazione delle immagini avviene all’interno di un ambiente browser isolato, utilizzando WebAssembly in un Web Worker.
L’elaborazione lato client riduce anche il rischio di attacchi Denial-of-Service (DoS), poiché il carico computazionale ricade sul client.
Per elaborare le immagini sul client, WordPress si affida a SharedArrayBuffer, un oggetto JavaScript che permette al thread principale e ai Web Worker di condividere lo stesso spazio di memoria.
Per garantire l’accesso a SharedArrayBuffer, WordPress abilita l’header Document-Isolation-Policy: isolate-and-credentialless. Questo fornisce un contesto di esecuzione isolato per l’editor a blocchi nei browser basati su Chromium 137 (Chrome 137 e Edge 137).
In breve, sebbene l’obiettivo principale dell’elaborazione multimediale lato client sia migliorare le prestazioni e l’efficienza nella gestione dei contenuti multimediali, questa nuova funzionalità apporta anche notevoli miglioramenti in termini di sicurezza.
6. Risorse ufficiali
L’elaborazione dei media lato client è stata ampiamente documentata per utenti e developer. Dai un’occhiata alle seguenti risorse per i dettagli:
- Elaborazione multimediale lato client in WordPress 7.1 (nota di sviluppo)
- Architettura dell’elaborazione dei media lato client (Manuale dell’editor a blocchi)
- Elaborazione dei media lato client (guide pratiche)
- Filtri e parametri dell’elaborazione dei media lato client (Riferimento agli hook)
Miglioramenti alle Note
Introdotte per la prima volta in WordPress 6.9, le Note hanno ricevuto numerose aggiunte e miglioramenti che le rendono uno strumento di collaborazione più completo.
Innanzitutto, WordPress 7.1 aggiunge il supporto per il testo formattato nelle Note, rendendole «più espressive, più chiare da leggere e più in linea con le aspettative degli utenti rispetto a strumenti come Google Docs, Figma, GitHub e altri editor collaborativi».
Questo include la formattazione di base in linea come il grassetto (Ctrl/⌘ B), il corsivo (Ctrl/⌘ I), i link (Ctrl/⌘ K) e le emoji.
Ora puoi aggiungere note in linea selezionando frammenti di testo invece che un intero blocco (commenti in linea). È anche possibile aggiungere più note allo stesso blocco o alla stessa selezione di testo.
WordPress 7.1 introduce anche le @menzioni per taggare i tuoi collaboratori nelle note, rendendo la funzionalità Note più simile ai popolari strumenti di collaborazione. Quando digiti il carattere @, appare un pannello con l’elenco degli utenti del sito per una facile selezione. Il destinatario della menzione riceverà una notifica via e-mail con un link al post.
Un’altra novità riguarda la parte visibile delle note. Le note lunghe ora vengono nascoste per impostazione predefinita, in modo da non ingombrare troppo lo spazio sullo schermo. Un pulsante Mostra di più/Mostra di meno permette di visualizzare o nascondere il testo completo.
Puoi vedere l’elenco completo delle nuove funzionalità per le Note incluse in WordPress 7.1 nella sezione dedicata alle Note di WordPress 7.1.
Miglioramenti all’UI di amministrazione
L’interfaccia utente di amministrazione riceve diversi aggiornamenti che migliorano la coerenza dell’interfaccia e semplificano la navigazione tra le schermate.
Barra di amministrazione sempre visibile nell’editor dei post e nell’Editor del sito
Prima di WordPress 7.1, la barra di amministrazione non veniva visualizzata nell’editor dei post e nell’Editor del sito. Questo comportamento era incoerente perché la barra degli strumenti di amministrazione è l’elemento più utilizzato dell’interfaccia di amministrazione, e ometterla dagli editor non era considerato ottimale. A partire da WordPress 7.1, questo comportamento cambia e la barra di amministrazione è ora visibile nell’editor dei post e nell’editor del sito.
Schema colori dell’utente esteso all’editor del sito
Un altro miglioramento, pensato per rendere coerente l’aspetto di tutte le aree di amministrazione, consiste nell’applicare anche all’editor del sito la stessa combinazione di colori impostata dall’utente nella pagina delle impostazioni. Prima della versione 7.1, la barra laterale dell’editor del sito era sempre nera.
Anche la barra laterale dell’editor è stata aggiornata con WordPress 7.1. L’icona del sito è stata rimossa dalla barra degli strumenti dell’editor e ora compare nella barra degli strumenti di WordPress.
Nelle versioni precedenti, per tornare alla bacheca di WordPress, dovevi cliccare sull’icona del sito, che tecnicamente non era un pulsante “Indietro”.
Con l’aggiornamento, l’icona del sito ora compare solo nella barra degli strumenti di amministrazione, mentre nella barra degli strumenti dell’editor compare un pulsante “Indietro” più chiaro.
Categorie di comandi e UI della palette dei comandi migliorata
La palette dei comandi ha ricevuto diverse aggiunte e modifiche per migliorarne l’usabilità. Innanzitutto, i comandi disponibili sono stati suddivisi in sezioni (recenti, suggerimenti e risultati) per renderli più facili da trovare.
La finestra modale è stata ridimensionata (512px) e ora i comandi sono più facili da leggere.
Schermata “Identità” nell’Editor del sito
Nel menu Design dell’Editor del sito compare ora una nuova voce Identità. La schermata corrispondente permette di configurare il titolo, lo slogan, il logo e l’icona del sito. In questo modo puoi modificare le impostazioni di identità del tuo sito senza uscire dall’Editor del sito.
Scorrimento infinito per la visualizzazione a griglia della Libreria multimediale
Fino a WordPress 7.0, era possibile abilitare lo scorrimento infinito per la visualizzazione a griglia della Libreria multimediale tramite il filtro media_library_infinite_scrolling, impostato di default su false. Chi si occupa di sviluppo poteva modificare l’impostazione predefinita aggiungendo la seguente riga ai propri plugin:
add_filter( 'media_library_infinite_scrolling', '__return_true' );A partire da WordPress 7.1, il filtro media_library_infinite_scrolling è impostato su true, il che significa che lo scorrimento infinito nella visualizzazione a griglia della Libreria multimediale è attivo per tutti gli utenti per impostazione predefinita.
Inoltre, una nuova impostazione nella pagina del profilo utente nell’area di amministrazione di WordPress permette di impostare le preferenze relative allo scorrimento infinito.
WordPress memorizza la scelta dell’utente nelle opzioni utente utilizzando il meta key infinite_scrolling. Puoi recuperare la preferenza dell’utente in questo modo:
$infinite_scrolling = get_user_option( 'infinite_scrolling', $user_id );Blocchi di base e miglioramenti ai blocchi
WordPress 7.1 introduce due nuovi blocchi e vari miglioramenti a quelli esistenti.
Nuovi blocchi “Playlist” e “Schede”
Un nuovo blocco Playlist permette di incorporare una semplice playlist nei tuoi contenuti.
Puoi personalizzare diversi aspetti dell’aspetto del blocco, tra cui tipografia, sfondo, dimensioni, bordi ed elementi. I controlli di stile specifici per questo blocco includono Waveform e pulsante di riproduzione e Sfondo della Waveform. Il controllo Forma ti permette di cambiare la visualizzazione della forma d’onda dell’audio.
Il blocco Playlist supporta tutti i file audio compatibili con l’installazione di WordPress. Se aggiungi il supporto per un nuovo tipo MIME, il blocco lo eredita automaticamente.
Il nuovo blocco Schede del core è pensato per organizzare i contenuti in schede. Ogni scheda può contenere qualsiasi blocco, il che lo rende particolarmente utile per ospitare contenuti suddivisi per argomento, domande frequenti o confronti tra prodotti/servizi.
Blocchi modificabili all’interno del blocco “HTML personalizzato”
Il blocco HTML personalizzato ha ricevuto un nuovo miglioramento. Ora puoi aggiungere blocchi modificabili direttamente all’interno del codice HTML. Questo permette di combinare HTML statico e blocchi modificabili all’interno dello stesso snippet.
Sebbene siano modificabili, questi blocchi non possono essere spostati o rimossi, né è possibile aggiungere blocchi aggiuntivi tramite l’editor visivo. Tuttavia, il codice sottostante rimane completamente modificabile nell’editor di codice.
Prima di WordPress 7.1, i contenuti dovevano essere o interamente in HTML statico o composti interamente da blocchi. Ora puoi mescolare liberamente HTML e blocchi, il che è particolarmente utile quando crei contenuti usando modelli di AI.
Questa modifica va di pari passo con la possibilità di aggiungere codice HTML statico alle varianti dei blocchi. Grazie al nuovo supporto per innerContent, puoi registrare una variante del blocco Codice HTML come mostrato nell’esempio qui sotto:
wp.blocks.registerBlockVariation( 'core/html', {
name: 'custom-image-card',
title: 'Custom image card',
description: 'A custom HTML block with static header/footer and an editable image.',
innerContent: [
'<h2>Static heading</h2>n',
null,
'n<footer>Static footer</footer>'
],
innerBlocks: [
[
'core/image',
{
id: 419,
sizeSlug: 'medium',
linkDestination: 'none',
url: 'https://example.com/wp-content/uploads/...',
alt: ''
}
]
],
} );Il valore null in innerContent funge da segnaposto per il blocco “Immagine”.
Tieni presente che innerContent è disponibile solo per il blocco HTML personalizzato. Applicarlo alle varianti di altri blocchi non avrà alcun effetto.
Miglioramenti al sistema delle icone SVG
WordPress 7.0 ha introdotto un nuovo blocco Icone e una libreria di icone. Con WordPress 7.1, il sistema di gestione delle icone acquisisce un’API pubblica, che consente di registrare, visualizzare ed eliminare le icone a livello di programmazione, oltre che di recuperarle tramite l’API REST.
Registrazione e cancellazione delle icone
Per registrare un’icona o un set di icone, devi prima registrare una raccolta di icone agganciando la nuova funzione wp_register_icon_collection() all’azione “init”:
function custom_icons_register_icon_collection() {
wp_register_icon_collection(
'my-icon-set',
array(
'label' => __( 'My awesome icons', 'my-plugin' ),
'description' => __( 'My personal set of icons.', 'my-plugin' ),
)
);
}
add_action( 'init', 'custom_icons_register_icon_collection' );Una raccolta ha un nome univoco, che la distingue dalle icone del core e da altri set di icone registrati da plugin di terze parti. Il nome della raccolta deve iniziare e finire con una lettera minuscola e può contenere lettere minuscole, numeri, trattini e trattini bassi.
Il secondo argomento della funzione è un array contenente l’etichetta della raccolta visualizzata nella Libreria delle icone e una descrizione facoltativa.
Per rimuovere una raccolta, usa la funzione wp_unregister_icon_collection(). La rimozione di una raccolta elimina automaticamente tutte le icone ad essa associate.
Per registrare una singola icona, usa la funzione wp_register_icon(), come mostrato nell’esempio seguente:
wp_register_icon(
'my-icon-set/motorbike',
array(
'label' => __( 'Motorbike', 'my-plugin' ),
'content' => '<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24">...</svg>',
)
);Nell’esempio sopra, abbiamo registrato un’icona utilizzando una stringa SVG. Puoi anche registrare un’icona direttamente da un file .svg:
wp_register_icon(
'my-icon-set/motorbike',
array(
'label' => __( 'Motorbike', 'my-plugin' ),
'file_path' => plugin_dir_path( __FILE__ ) . 'icons/motorbike.svg',
)
);È importante notare che il codice SVG viene sanificato con wp_kses e che al momento sono consentiti solo gli elementi <svg>, <path> e <polygon>. Tutti gli altri elementi vengono filtrati, anche se in futuro l’elenco degli elementi consentiti potrebbe essere ampliato per includere ulteriori elementi e attributi.
Per eliminare un’icona, puoi usare la funzione wp_unregister_icon().
Aggiornamenti alla libreria delle icone e ai blocchi
La libreria delle icone è stata aggiornata di conseguenza e ora presenta una barra laterale che mostra l’elenco delle raccolte di icone registrate sul sito.
Anche il blocco “Icona” è stato aggiornato. Per impostazione predefinita, il blocco ora mostra l’icona “Info” invece di un segnaposto vuoto come nelle versioni precedenti. Inoltre, due nuovi controlli nella barra degli strumenti del blocco permettono di capovolgere l’icona sia in verticale che in orizzontale.
Nuovi endpoint API REST per le icone
Sono stati introdotti anche nuovi endpoint API REST in sola lettura per accedere alle raccolte di icone o a icone specifiche.
Per le raccolte di icone, userai i seguenti endpoint:
GET /wp/v2/icon-collections
GET /wp/v2/icon-collections/<collection>Per leggere le icone, userai invece i seguenti endpoint:
GET /wp/v2/icons - Introduced with WordPress 7.0.
GET /wp/v2/icons/<collection>
GET /wp/v2/icons/<collection>/<name>Un utente con il ruolo edit_posts deve autenticare le richieste.
Per una panoramica più approfondita del sistema delle icone in WordPress 7.1, dai un’occhiata alle note di sviluppo.
Nuovi strumenti di progettazione
Creator ed editor hanno ora a disposizione nuovi strumenti di progettazione migliorati che consentono di personalizzare lo stile dei blocchi di contenuto senza ricorrere a CSS personalizzati.
Supporto per i gradienti di sfondo
WordPress 7.1 introduce il supporto perbackground.gradient e un nuovo controllo nell’interfaccia di amministrazione per i gradienti di sfondo.
Nella barra laterale delle impostazioni dei blocchi, un nuovo pannello “Sfondo” con controlli separati per Immagine, Colore e Sfumatura permette di sperimentare diverse combinazioni di immagini di sfondo, colori e sfumature evitando conflitti.
In WordPress 7.1, il supporto per background.gradient è abilitato di default per i blocchi Gruppo, Fisarmonica, Pullquote, Contenuto del post e Citazione. Chi sviluppa temi può aggiungere il supporto per background.gradient nel file block.json inserendo una proprietà gradient sotto styles.background oppure a livello di singolo blocco, come mostrato nel codice seguente:
{
"styles": {
"background": {
"gradient": "linear-gradient( 135deg, #1e3c72 0%, #2a5298 100% )"
},
"blocks": {
"core/group": {
"background": {
"gradient": "linear-gradient( 135deg, #f5f7fa 0%, #c3cf8d 100% )"
}
}
}
}
}Supporto per la larghezza minima
Un’altra novità di WordPress 7.1 che piacerà un sacco a designer e sviluppatori di temi è il supporto per la dimensione minWidth . Questa si aggiunge al supporto già esistente per height, minHeight e width, completando così il set di strumenti di progettazione per le dimensioni.
Gli sviluppatori di temi possono aggiungere il supporto per la larghezza minima tramite theme.json, sia abilitando gli Strumenti di Aspetto sia aggiungendo il campo dimensions.minWidth nelle impostazioni:
{
"settings": {
"dimensions": {
"minWidth": true
}
}
}
Puoi anche aggiungere il supporto per la larghezza minima a livello globale o per singolo blocco:
{
"styles": {
"dimensions": {
"minWidth": "400px"
},
"blocks": {
"core/group": {
"dimensions": {
"minWidth": "400px"
}
}
}
}
}Chi sviluppa blocchi può aggiungere in modo simile il supporto per minWidth su block.json:
{
"supports": {
"dimensions": {
"minWidth": true
}
}
}Il controllo è nascosto di default nella barra laterale, ma puoi modificare l’impostazione predefinita usando __experimentalDefaultControls. In Stili globali, il controllo è visibile di default.
Supporto per l’ombra del testo negli Stili globali
WordPress 7.1 introduce il supporto per text-shadow negli Stili globali. Prima era necessario usare un plugin o ricorrere a CSS personalizzati.
Tieni presente che si tratta di un’implementazione iniziale. Alcune decisioni chiave sono ancora in sospeso, come ad esempio quale controllo dell’interfaccia utente utilizzare per personalizzare le ombre del testo nell’editor e se text-shadow debba essere disponibile come preimpostazione. Per ora, è possibile definire text-shadow nel tuo theme.json solo in uno dei seguenti modi:
{
"$schema": "https://schemas.wp.org/wp/6.7/theme.json",
"version": 3,
"settings": {},
"styles": {
"typography": {
"textShadow": "1px 1px 2em white, 0 0 2em yellow, 0 0 0.2em red;"
},
"blocks": {
"core/paragraph": {
"typography": {
"textShadow": "1px 1px 2px red, 0 0 1em red, 0 0 0.2em red"
}
}
},
"elements": {
"h2": {
"typography": {
"fontSize": "var:preset|font-size|x-large",
"textShadow": "1px 1px 2em white, 0 0 2em yellow, 0 0 0.2em red;"
}
}
}
}
}L’immagine seguente mostra il risultato delle definizioni di cui sopra.
Aggiornamenti per developer
Gli aggiornamenti in arrivo per sviluppatori e sviluppatrici di temi e plugin con WordPress 7.1 sono notevoli. Le numerose aggiunte e miglioramenti all’API Abilities e alla personalizzazione del sistema di design ci sembrano le novità più degne di nota.
Temi del sistema di design
WordPress 7.1 introduce un nuovo sistema di design che chi sviluppa plugin può usare per personalizzare lo stile degli elementi dell’interfaccia di amministrazione. Il nuovo sistema è composto da due parti: i token di design e un nuovo componente React chiamato ThemeProvider.
Token di design
I token di design di WordPress sono proprietà CSS personalizzate che seguono uno schema prestabilito. Ecco, ad esempio, lo schema per la famiglia di token Color:
--wpds-color-<property>-<target>-<tone>[-<emphasis>][-<state>]In base allo schema sopra riportato, la seguente variabile imposta il colore di sfondo per le superfici con enfasi normale:
--wpds-color-background-surface-neutral-strongA partire da WordPress 7.1, i token di design possono essere utilizzati da qualsiasi plugin che generi elementi dell’interfaccia di amministrazione grazie a un nuovo foglio di stile wp-theme che include un set completo di token di design semantici ed è disponibile come dipendenza del plugin. Puoi mettere in coda un foglio di stile personalizzato che utilizza wp-theme come mostrato di seguito:
function myplugin_enqueue_admin_assets( $hook_suffix ) {
wp_enqueue_style(
'myplugin-admin-style',
plugin_dir_url( __FILE__ ) . 'assets/css/admin.css',
array( 'wp-theme' ),
'1.0.0'
);
}
add_action( 'admin_enqueue_scripts', 'myplugin_enqueue_admin_assets' );Il vantaggio dei token di design è che possono sostituire i valori delle proprietà CSS hardcoded. Dai un’occhiata all’esempio seguente tratto dalla nota per gli sviluppatori:
.card {
background-color: var(--wpds-color-background-surface-neutral-strong);
color: var(--wpds-color-foreground-content-neutral);
border: var(--wpds-border-width-xs) solid var(--wpds-color-stroke-surface-neutral-weak);
border-radius: var(--wpds-border-radius-lg);
padding: var(--wpds-dimension-padding-2xl);
}I token di design possono essere utilizzati insieme al componente ThemeProvider per personalizzare l’aspetto di aree specifiche della pagina di amministrazione.
ThemeProvider
Puoi sovrascrivere i valori predefiniti dei token di design forniti dal foglio di stile wp-theme racchiudendo il contenuto dell’area di amministrazione all’interno del nuovo componente React ThemeProvider, come mostrato nell’esempio seguente tratto dalla nota di sviluppo:
import { ThemeProvider } from '@wordpress/theme';
import { Card } from '@wordpress/ui';
function Application() {
return (
<ThemeProvider
color={
{
primary: '#3858e9',
background: '#11004d'
}
}
cornerRadius="pronounced"
>
<Card.Root>
<Card.Content>
Card content
</Card.Content>
</Card.Root>
</ThemeProvider>
);
}Dati un colore primario e uno di sfondo, il componente genera automaticamente una sfumatura armoniosa e coerente che garantisce un contrasto accessibile tra gli elementi dell’interfaccia utente.
Il ThemeProvider permette a chi sviluppa plugin di esprimere l’identità del brand all’interno delle aree dell’interfaccia, pur rimanendo coerenti con lo stile generale dell’interfaccia di amministrazione di WordPress.
Per un’analisi più approfondita, dai un’occhiata alla nota di sviluppo e alla documentazione ufficiale sui token di design e sul ThemeProvider.
Miglioramenti all’API Abilities
Con il rilascio di WordPress 7.1, l’API Abilities riceve diverse aggiunte che ne ampliano le funzionalità.
Nuovo ciclo di vita di esecuzione per l’API Abilities
Innanzitutto, il ciclo di esecuzione è stato potenziato con 4 nuovi filtri che vengono eseguiti prima, durante e dopo l’esecuzione di un’abilità.
Il filtro wp_pre_execute_ability viene eseguito all’inizio di WP_Ability::execute() e serve a intercettare e interrompere l’esecuzione di un’azione prima ancora che WordPress inizi a elaborarla. Se il filtro restituisce un valore diverso dal valore predefinito $pre (un errore, dei dati o un valore booleano), WordPress si ferma immediatamente, salta i controlli e restituisce quel valore.
Questo filtro si presta a casi d’uso interessanti, come disabilitare una funzionalità durante la manutenzione del sito, limitare la frequenza delle richieste provenienti dallo stesso IP o simulare la risposta di una funzionalità (test unitari).
Il filtro wp_ability_normalize_input viene eseguito subito dopo l’applicazione dei valori predefiniti e prima della convalida formale dello schema e dei controlli dei permessi. Viene utilizzato per preparare o trasformare i dati in entrata prima che vengano convalidati ed elaborati dall’abilità — ad esempio, aggiungendo metadati contestuali, normalizzando i dati prima della convalida, arricchendo un prompt AI o interrompendo l’esecuzione dell’abilità in caso di errore.
Il filtro wp_ability_permission_result permette di modificare il risultato dei controlli dei permessi eseguiti prima dell’esecuzione di un’abilità. Puoi usarlo per aggiungere regole di autorizzazione più dettagliate, creare un sistema di autorizzazioni personalizzato o bypassare le autorizzazioni in casi specifici.
Tieni presente che dovresti usare questo filtro con cautela:
I plugin dovrebbero prestare particolare attenzione a questo filtro perché restituire un valore
truepuò sovrascrivere un rifiuto proveniente dalpermission_callbackoriginale dell’abilità.
Il filtro wp_ability_execute_result viene eseguito dopo il callback di esecuzione dell’abilità e prima della convalida dell’output, permettendo di modificare il risultato finale restituito da un’abilità. Permette di trasformare la risposta generata dall’elaborazione dell’abilità prima che venga restituita a chi l’ha chiamata.
Filtraggio e manipolazione delle abilità
Prima di WordPress 7.1, per filtrare le abilità registrate era necessario scorrere manualmente il registro usando array_filter(). A partire da WordPress 7.1, wp_get_abilities() accetta un array opzionale di argomenti per filtrare le abilità registrate in base a category, namespace, meta o una combinazione di questi.
L’esempio seguente mostra come recuperare le abilità appartenenti a una categoria specifica:
$abilities = wp_get_abilities(
array(
'category' => 'content-generation',
)
);Puoi anche combinare più parametri:
$abilities = wp_get_abilities(
array(
'category' => 'content-generation',
'meta' => array(
'public' => true,
),
)
);Per un filtraggio più avanzato, l’API mette a disposizione i parametri item_include_callback e result_callback: due callback che servono per includere o escludere le funzionalità dall’array e per ordinare o modificare il set di risultati prima che venga restituito.
Oltre agli aggiornamenti a wp_get_abilities(), WordPress 7.1 introduce due nuovi filtri globali:
wp_get_abilities_item_include. Viene eseguito per ogni abilitazione che supera i filtri dichiarativi eitem_include_callback. Puoi usare questo filtro per includere o escludere abilitazioni specifiche a livello di sito.wp_get_abilities_result. Viene eseguito doporesult_callback. Puoi usarlo per manipolare l’intero insieme di risultati delle abilità in tutto il sito.
Consulta la nota di sviluppo per una panoramica più approfondita degli aggiornamenti a wp_get_abilities() e ai relativi filtri.
Nuovo flag di esposizione pubblica
WordPress 7.1 introduce anche un nuovo flag nei metadati per indicare che un’abilità è accessibile da client esterni, come l’API REST, gli adattatori MCP e gli agenti AI.
Quando registri un’abilità, ora puoi usare meta.public per consentire che la tua abilità venga individuata e richiamata tramite gli endpoint REST delle abilità. In precedenza, dovevi specificare l’esposizione separatamente per ogni canale, ad esempio impostando ‘show_in_rest’ => true per rendere visibile un’abilità tramite REST.
Altri miglioramenti all’API Abilities
Oltre agli aggiornamenti descritti sopra, WordPress 7.1 introduce ulteriori miglioramenti che riguardano vari aspetti dell’API.
Due nuovi filtri, wp_ability_validate_input e wp_ability_validate_output, permettono ai plugin di convalidare i dati in ingresso e in uscita utilizzando regole più complesse rispetto a quelle espressibili dallo schema JSON di WordPress. Il primo filtro viene eseguito dopo che l’input è stato preparato e la convalida iniziale dello schema è stata superata. Il secondo filtro viene eseguito dopo che l’abilità è stata eseguita e prima che venga restituito il risultato finale.
L’azione wp_ability_invoked viene eseguita all’inizio di WP_Ability::execute() e può essere usata per tracciare e registrare ogni tentativo di invocare un’abilità. Puoi agganciarti a questa azione per registrare i tentativi di accesso a un’abilità specifica, misurare il carico del server, impostare contatori di utilizzo giornalieri o mensili e rilevare tentativi di chiamate con attacchi brute-force.
Attenzione però:
L’azione riceve input grezzi e non normalizzati. I plugin dovrebbero quindi evitare di registrare gli input in modo indiscriminato, poiché potrebbero contenere credenziali, informazioni personali o altri dati sensibili.
Altri aggiornamenti per developer
Gli aggiornamenti per chi sviluppa non finiscono qui. WordPress 7.1 introduce un numero impressionante di miglioramenti e novità, fornendo strumenti di sviluppo nuovi e più affidabili. Con questa nuova versione troverai anche:
- Quattro nuovi filtri per configurare le schermate dell’Editor del sito
- L’editor dei post è sempre contenuto in un iframe
- Aggiornamenti ai componenti dell’editor
- jQuery UI aggiornato alla versione 1.14.2
- Preparazione dello schema JSON per la compatibilità con i client.
- Ora puoi applicare stili agli pseudo-stati.
- Stili dei blocchi reattivi e viewport configurabili
- Nuove funzioni per il rendering dei tooltip e delle note informative
Hosting di nuova generazione per WordPress di nuova generazione
WordPress 7.1 segna un importante passo avanti per il CMS su diversi fronti.
L’elaborazione dei media lato client rappresenta una svolta nella gestione delle immagini. L’elaborazione avviene ora sul lato client, con conseguente maggiore efficienza delle risorse del server e prestazioni più veloci delle pagine.
Per quanto riguarda le funzionalità di AI, dopo gli aggiornamenti rivoluzionari delle versioni 6.9 e 7.0, WordPress 7.1 segna un momento di consolidamento. L’API Abilities acquisisce nuove funzionalità che permettono agli sviluppatori di creare integrazioni e funzionalità di AI più affidabili e sicure.
Un’altra potente novità che sviluppatori, sviluppatrici e agenzie apprezzeranno è il Theme Provider, che permette ai plugin di esprimere la propria identità di brand nell’area di amministrazione, pur rimanendo coerenti con l’interfaccia della bacheca di WordPress.
Ci sono anche miglioramenti alle Note, nuovi blocchi, un sistema di icone SVG più potente e molto altro ancora. Insomma, WordPress è ben lontano dal rallentare ed è più lungimirante che mai.
Per un CMS sempre più avanzato, è fondamentale scegliere un provider di hosting che stia al passo con le tecnologie moderne. Kinsta offre l’ambiente ideale per i siti WordPress di nuova generazione: infrastruttura cloud containerizzata, prestazioni eccezionali, sicurezza solida e un’assistenza veloce e di prim’ordine.
Se non hai ancora provato il nostro hosting, approfitta della prova gratuita su alcuni piani selezionati o contattaci per saperne di più.
Carlo è cultore appassionato di webdesign e front-end development. Gioca con WordPress da oltre 20 anni, anche in collaborazione con università ed enti educativi italiani ed europei. Su WordPress ha scritto centinaia di articoli e guide, pubblicati sia in siti web italiani e internazionali, che su riviste a stampa. Lo trovate su LinkedIn.
