Le Novità di WordPress 5.6 (Accessibilità, Prestazioni, Sicurezza)

WordPress 5.6 “Simone” è finalmente disponibile: non vediamo l’ora di esplorare insieme a voi le funzionalità più interessanti e le aggiunte fuse nel Core con l’ultima release di WordPress del 2020.

Come avvenuto con le release precedenti, WordPress 5.6 include diverse versioni del Block Editor che migliorano l’esperienza di editing per gli utenti che non hanno ancora installato e aggiornato il plugin Gutenberg sul proprio sito web.

Non tutto però riguarda il Block Editor. Sono state aggiunte diverse funzionalità al Core di WordPress, come il nuovo tema predefinito TwentyTwenty-One, aggiornamenti automatici per le major release, un migliore supporto di PHP 8.0, password delle applicazioni per l’autenticazione via REST API.

E c’è molto di più in WordPress 5.6. Vedremo anche miglioramenti all’accessibilità e nell’interfaccia utente, un sacco di correzioni di bug e un elenco enorme di modifiche per gli sviluppatori.

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

• 20 ottobre 2020: Beta 1
• 27 ottobre 2020: Beta 2
• 2 novembre 2020: Beta 3
• 12 novembre 2020: Beta 4
• 17 novembre 2020: RC 1
• 1 dicembre 2020: RC 2
• 7 dicembre 2020: Prova generale per il rilascio di WordPress 5.6
• 8 dicembre 2020: Release di WordPress 5.6 “Simone”

Iniziamo? Via!

Cosa C’È di Nuovo nel Block Editor

Con il rilascio di WordPress 5.6, diverse versioni del plugin Gutenberg sono state fuse nel core, per cui chi usa e scrive con WordPress dovrebbe notare diversi miglioramenti nell’editor. Vedremo migliori modelli di blocchi, il conteggio delle parole nel pannello informativo, miglioramenti nella navigazione da tastiera e nell’interfaccia utente drag-and-drop e molto altro.

Per un elenco più completo di tutti i miglioramenti e le modifiche aggiunte all’editor di blocchi, date un’occhiata ai post delle note di rilascio: 8.6, 8.7, 8.8, 8.9, 9.0, 9.1 e 9.2.
In WordPress 5.6 ci saranno anche le correzioni di bug e i miglioramenti delle prestazioni implementati in Gutenberg 9.3 e 9.4.

Immergiamoci nelle novità più interessanti che vedremo nell’editor dei blocchi.

1. Blocchi, Modelli e Miglioramenti dell’Interfaccia Utente
2. Block API V2
3. Caratteristiche Aggiuntive e Miglioramenti per Chi Sviluppa Blocchi

Blocchi, Modelli e Miglioramenti dell’Interfaccia Utente

Le nuove funzionalità dei blocchi, i miglioramenti e le correzioni di bug miglioreranno l’esperienza complessiva di editing. Inoltre, è stato fatto un grande lavoro sull’accessibilità. Qui sotto troverete la nostra selezione delle caratteristiche più interessanti che vedrete nell’editor a blocchi una volta aggiornato il vostro sito web a WordPress 5.6.

Controlli di Posizione per i Video nel Blocco Copertina

A partire da Gutenberg 8.6 sono stati inseriti nel blocco Copertina i controlli di posizione per i video: questi consentono agli utenti di spostare il punto focale e di impostare una posizione personalizzata per i video. Questa funzionalità era precedentemente disponibile solo per gli sfondi delle immagini.

I valori di posizione vengono impostati facendo clic in qualsiasi punto del controller del punto focale e/o usando i tasti freccia sulla tastiera. Potete saltare i valori di 10 in 10 tenendo premuto il tasto shift (si veda anche la issue di GitHub: #22531).

Aggiornamenti dei Block Pattern

WordPress 5.6 include anche diversi miglioramenti nei Block Pattern aggiunti con Gutenberg 8.6.

Il layout, il testo e il colore del Large header and paragraph sono stati aggiornati (#23858)

Il titolo del blocco Due colonne di testo è stato spostato fuori dal blocco di testo e posizionato sopra le colonne (#23853)

Il pattern del blocco Citazione ora include un’immagine in alto e un separatore in basso.

Gutenberg 8.7 ha aggiunto un nuovo pattern per titolo e paragrafo (#24143).

Un buon miglioramento dell’usabilità per l’inseritore di blocchi è il menu a tendina con le categorie dei pattern dei blocchi, che consente di filtrare i pattern per categoria. Questo è estremamente utile quando avete un sacco di pattern tra cui scegliere (#24954).

Supporto per i Sottotitoli Video

I blocchi video ora supportano i sottotitoli video.

I sottotitoli video devono avere il formato Web VTT (Web Video Text Tracks Format), che è “un formato per la visualizzazione di tracce di testo a tempo (come sottotitoli o didascalie) utilizzando l’elemento <track>” (#25861).

Una volta caricati i file .vtt, chi visita il vostro sito potrà abilitare i sottotitoli nella sua lingua preferita.

Trasformare Blocchi Multipli in un Blocco Colonne

Un interessante miglioramento dell’usabilità è la possibilità di convertire una selezione di più blocchi in un unico blocco colonne.

È sufficiente selezionare i blocchi che si desidera visualizzare in colonne, quindi fare clic sul pulsante in alto a destra della barra degli strumenti del blocco.

Ogni blocco selezionato sarà convertito in una colonna di un blocco Colonne.

Pattern dello Sfondo nel Blocco Copertina

I blocchi Copertina possono ora visualizzare dei pattern di sfondo.

Per aggiungere uno sfondo, caricate un’immagine, quindi attivate l’opzione Sfondo ripetuto (ecco tutto quello che c’è da sapere sulla libreria media in WordPress).

Una volta terminato, regolate il selezionatore di punti focali in base alle vostre esigenze e provate diverse combinazioni con sfondi fissi.

Controllo delle Dimensioni delle Immagini Aggiunto al Blocco Media & Testo

Con Gutenberg 9.1, è stato aggiunto un nuovo controllo delle dimensioni delle immagini nel blocco Media & Testo.

Gli utenti possono ora scegliere tra tutte le dimensioni delle immagini disponibili (#24795).

Block API V2

Una nuova versione della Block API permette di rendere l’elemento wrapper dei blocchi. L’obiettivo della nuova versione dell’API è quello di alleggerire il DOM dell’editor e renderlo corrispondente al contenuto della pagina frontale. Secondo Ella van Durpe:

Il più grande vantaggio è che i temi e i plugin possono stilizzare più facilmente il contenuto del blocco se il markup è lo stesso nell’editor.

La nuova versione richiede di dichiarare la proprietà apiVersion nella registrazione del tipo di blocco:

registerBlockType( name, { apiVersion: 2 } );

La nuova API richiede anche l’hook useBlockProps nella funzione Edit. Questo hook contrassegna l’elemento wrapper di un blocco come elemento di blocco.

Qualsiasi proprietà passata a questo hook sarà accorpata e restituita all’elemento wrapper. L’esempio seguente delle note di rilascio mostra un semplice caso d’uso:

import { useBlockProps } from '@wordpress/block-editor';
 
function Edit( { attributes } ) {
    const blockProps = useBlockProps( {
        className: someClassName,
        style: { color: 'blue' },
    } );
    return <p { ...blockProps }>{ attributes.content }</p>;
}

Per ulteriori esempi, date un’occhiata al post Block API Version 2.

Caratteristiche Aggiuntive e Miglioramenti per Chi Sviluppa Blocchi

Oltre alla Block API Versione 2, ecco un elenco di aggiunte utili per chi si occupa di sviluppo.

API Block Support

L’API Block Support permette a chi sviluppa i blocchi di aggiungere funzionalità ai loro blocchi. Colori, sfondi, dimensioni dei caratteri sono solo alcune delle molte caratteristiche che possono essere aggiunte ai blocchi attraverso l’API Block Supports.

WordPress 5.6 introduce anche diversi nuovi supporti per i blocchi “per aumentare la coerenza e facilitare l’introduzione di queste opzioni nei blocchi”.

Gli sviluppatori possono utilizzare i nuovi Block Supports aggiungendo le chiavi corrispondenti alla proprietà supports del file block.json o direttamente nella funzione registerBlockType.

L’esempio seguente tratto dalle note di rilascio dei Block Supports mostra come funziona:

supports: {
    color: {
        background: true, // Enable background color UI control.
        gradient: true, // Enable gradient color UI control.
        text: true // Enable text color UI control.
    },
    fontSize: true, // Enable font size UI control.
    lineHeight: true // Enable line height UI control.
}

Il valore dello stile sarà automaticamente collegato all’elemento wrapper attraverso la classe has-<value>-<preset-category> (per i valori preimpostati) o con un elemento di style (per i valori personalizzati).

Per questo motivo, i Block Supports vanno utilizzati con la nuova Block API V2.

API createBlocksFromInnerBlocksTemplate

Gli sviluppatori possono utilizzare il componente InnerBlocks per creare blocchi personalizzati contenenti altri blocchi. Esempi sono il blocco Colonne e il blocco Icone Social.

La nuova API createBlocksFromInnerBlocksTemplate permette di creare blocchi dal template InnerBlocks.

Date un’occhiata alle note di rilascio per approfondire l’argomento e vedere un esempio di codice.

Componente ToolbarButton

Un paio di modifiche riguardano anche i componenti della Toolbar:

1. Componente ToolbarGroup

Prima di WordPress 5.6, il componente Toolbar permetteva agli sviluppatori di raggruppare le opzioni correlate in un contenitore comune. Ora, invece, bisogna utilizzare il nuovo componente ToolbarGroup.

<BlockControls>
    <ToolbarGroup>
        <ToolbarButton />
    </ToolbarGroup>
</BlockControls>

2. Componenti ToolbarButton e ToolbarItem

L’utilizzo degli elementi a schede direttamente come elementi della barra degli strumenti (come <button> ) è ora deprecato. Al fine di migliorare l’accessibilità, gli elementi della barra degli strumenti possono essere aggiunti utilizzando il ToolbarButton per i pulsanti e il ToolbarItem per gli altri controlli.
L’esempio seguente mostra un pulsante e un menu a tendina:

<BlockControls>
    <ToolbarItem as="button" />
    <ToolbarButton />
    <ToolbarItem>
        { ( itemProps ) => ( <DropdownMenu toggleProps={ itemProps } /> ) }
    </ToolbarItem>
</BlockControls>

Disabilitazione dei Block Pattern del Core

I pattern del core possono ora essere disabilitati grazie al flag di supporto core-block-patterns (#24042)

Disabilitazione della Modifica In Linea delle Immagini

Gutenberg 8.4 ha aggiunto la funzione Inline Image Editing che permette agli utenti di modificare le immagini in linea, direttamente dal Block Editor.

Ora è possibile disabilitare l’editor di immagini utilizzando il filtro block_editor_settings (#23966):

add_filter( 'block_editor_settings', function( $settings ) {
    $settings['imageEditing'] = false;
    return $settings;
} );

Blocchi Riutilizzabili Spostati in un Pacchetto Separato

I blocchi riutilizzabili, precedentemente parte del pacchetto @wordpress/editor, sono stati spostati nel pacchetto @wordpress/reusable-blocks per renderli disponibili in altri editor.

Un Nuovo Tema di Default: Twenty Twenty-One

WordPress 5.6 include un nuovo tema predefinito. Twenty Twenty-One è un tema WordPress altamente accessibile, minimalista, con un layout a colonna singola e una sidebar nel footer.

Il nuovo tema usa uno stack di font di sistema e una tavolozza di colori minimale basata su colori di sfondo pastello.

Potete scoprire di più su Twenty Twenty-One nel nostro approfondito articolo del blog: Twenty Twenty-One: Analisi Approfondita del Nuovo Tema Predefinito di WordPress.

Aggiornamenti Automatici per le Release Principali

Gli aggiornamenti automatici sono una funzionalità del Core introdotta in WordPress 3.7 con l’obiettivo di migliorare la sicurezza dei siti e rendere più facile mantenerli aggiornati per chi li amministra.

Mentre nelle versioni precedenti sono stati implementati gli aggiornamenti automatici delle minor release del core, con WordPress 5.6 chi amministra il sito può ora abilitare manualmente gli aggiornamenti automatici anche per le versioni principali (approfondiremo tra un attimo).

Purtroppo, questo task fondamentale di manutenzione potrebbe ancora creare confusione negli utenti meno tecnici. Potete leggere di più sugli aggiornamenti automatici nella nostra Analisi Approfondita degli Aggiornamenti Automatici di WordPress.

WordPress 5.6 introduce una nuova interfaccia che permette a chi amministra il sito di abilitare gli aggiornamenti automatici per le major release del core.

L’ambito di questa funzione è cambiato durante il ciclo beta di WordPress 5.6 e le note di sviluppo originali sono state sostituite. Come dice Jb Audras,

Il campo di applicazione iniziale degli aggiornamenti automatici del Core è stato cambiato così:

• Aggiornare il design dell’interfaccia utente.
• Per le installazioni esistenti, il comportamento rimarrà lo stesso di oggi: l’opt-in funziona di default per gli aggiornamenti minori, mentre per gli aggiornamenti principali è l’utente a dover fare l’opt-in (le costanti e i filtri già in uso da parte degli host o delle agenzie avranno comunque la precedenza).
• Per le nuove installazioni, il comportamento predefinito cambierà: opt-in di default sia per le major release che per le minor release.

A partire da WordPress 5.6, è possibile scegliere di attivare gli aggiornamenti automatici per le major release nella schermata Aggiornamenti, dove la nuova interfaccia utente mostrerà la casella di controllo Abilita gli aggiornamenti automatici per tutte le nuove versioni di WordPress..

Una volta abilitati gli aggiornamenti automatici del Core per le release principali, potrete cambiare abilitando solo le release di manutenzione e sicurezza facendo clic su Passa agli aggiornamenti automatici solo per le versioni di manutenzione e sicurezza..

Aggiornamenti Automatici delle Major release del Core per Sviluppatori

In primo luogo, quando sono abilitati gli aggiornamenti automatici delle major release del core, l’opzione auto_update_core_major viene memorizzata nel database con option_value abilitato. Quindi, se get_site_option( 'auto_update_core_major' ) restituisce true, viene selezionata la casella degli aggiornamenti automatici.

Poi WordPress controlla se i principali aggiornamenti automatici del core sono abilitati tramite la costante WP_AUTO_UPDATE_CORE o il filtro allow_major_auto_core_updates e imposta la casella di spunta di conseguenza.

Gli sviluppatori possono anche disabilitare gli aggiornamenti automatici del core impostando la costante WP_AUTO_UPDATE_CORE su false o minor come mostrato di seguito (si veda anche Controllare gli Aggiornamenti in Background Tramite wp-config.php):

# Disables all core updates:
define( 'WP_AUTO_UPDATE_CORE', false );

# Enables minor updates:
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Si noti che i possibili valori per WP_AUTO_UPDATE_CORE sono true (tutti), 'beta', 'rc', 'minor' e false.

Un’altra opzione per disabilitare di default i principali aggiornamenti automatici del core è l’utilizzo del nuovo filtro allow_major_auto_core_updates:

add_filter( 'allow_major_auto_core_updates', '_return_false' );

Alcuni Commenti sugli Aggiornamenti Automatici del Core

Già a dicembre 2018, Matt Mullenweg aveva condiviso le 9 priorità per il 2019, e la numero 7 era “offrire agli utenti un modo per partecipare agli aggiornamenti automatici delle principali release del core”. Forse un po’ in ritardo, ma ci stiamo arrivando.

I principali aggiornamenti automatici del core dovrebbero avere un grande impatto sulla sicurezza e sull’esperienza complessiva di WordPress. Una cosa sembra chiara: da un punto di vista tecnico, la funzione principale di aggiornamento automatico del core è un task complesso che non viene raggiunto al 100% con il rilascio di WordPress 5.6.

Dopo un’attenta discussione su Slack, Josepha Haden ha riassunto le preoccupazioni e le domande dei Core contributor.

L’obiettivo principale a lungo termine è quello di avere aggiornamenti automatici disponibili nella maggior parte dei siti WordPress per migliorare la sicurezza di tutto l’ecosistema WordPress (cioè oltre il 30% del web).

In ogni caso, secondo Helen Hou-Sandí, Core Lead Developer:

Secondo me ci sono alcune cose tecniche molto difficili da eseguire e questo richiede una gestione tecnica del prodotto MOLTO disciplinata e focalizzata.

Dovremmo quindi vedere altre modifiche e miglioramenti all’interfaccia utente degli aggiornamenti automatici delle major release del Core nel corso del tempo. Questo è quanto possiamo aspettarci da questo momento in poi:

WordPress 5.6:

• Nelle installazioni esistenti, gli aggiornamenti del core devono essere abilitati dall’utente. Qualsiasi costante e filtro già in uso avrà la precedenza. Gli aggiornamenti minori sono abilitati di default.
• Nelle nuove installazioni, sia gli aggiornamenti minori che quelli principali sono abilitati di default.

WordPress 5.6.1:

• Dovremmo vedere alcune modifiche all’interfaccia utente degli aggiornamenti automatici del Core in base ai feedback ricevuti.

WordPress 5.7:

• Dovrebbe essere aggiunto un elemento nella schermata Salute del Sito per tutti coloro che hanno optato per gli aggiornamenti automatici delle versioni principali.
• Da WordPress 5.7, nella procedura di installazione dovrebbe essere aggiunto un opt-in per gli aggiornamenti automatici.

Una grande preoccupazione relativa agli aggiornamenti automatici del Core è la fiducia degli utenti. Secondo Helen Hou-Sandí:

Credo che possiamo ancora fare molto lavoro per aumentare in modo proattivo la fiducia degli utenti, specialmente di quelli che hanno avuto precedenti esperienze negative con WordPress e/o con i suoi aggiornamenti.

Tuttavia, ogni sito web WordPress è un mix di Core, plugin e tema. Nelle parole di Hou-Sandí:

Gli aggiornamenti del core sono in generale abbastanza sicuri e ci sono alcune protezioni integrate, ma dato che i siti possono eseguire qualsiasi codice da qualsiasi fonte, non esiste una cosa come il “100%” per “ogni tipo di sito WordPress”.

Gli utenti che hanno abilitato gli aggiornamenti automatici del Core dovrebbero eseguire regolarmente il backup dei loro siti web o scegliere un host web che fornisca backup automatici nei loro piani.

Gli aggiornamenti automatici del Core influenzeranno anche l’esperienza complessiva degli aggiornamenti, compresi gli aggiornamenti automatici dei plugin e dei temi. Joost de Valk ha scritto in un commento:

Se attiviamo di default gli aggiornamenti automatici del Core di WordPress, dovremmo fare lo stesso per i plugin. Altrimenti, i plugin e i temi non possono aggiornarsi se si devono correggere delle cose a causa degli aggiornamenti del core. Penso che gli utenti si aspettino anche questo: se WordPress si aggiorna automaticamente, anche i plugin e i temi dovrebbero farlo.

Modifiche alla Salute del Sito (Site Health) in WordPress 5.6

Oltre a tutte le caratteristiche qui discusse, WordPress 5.6 porta con sé anche una versione migliorata dello strumento Salute del Sito, che ora si comporta in modo diverso in background.

Convalida dei Dati di Verifica dello Stato di Salute del Sito

D’ora in poi un validatore controllerà le risposte ai test sulla salute del sito svolte da Site Health. Il validatore scarterà qualsiasi risposta non valida, impedendo allo strumento Site Health di causare errori fatali e bloccare ogni ulteriore controllo.

Questo significa che d’ora in poi le risposte non valide non influenzeranno l’indicatore di Site Health (#50145).

Controlli Asincroni Tramite Endpoint REST

Site Health è un potente strumento di sicurezza che permette ai proprietari del sito di essere a conoscenza dello stato di salute dei loro siti web.

Questo strumento esegue una serie di test di sicurezza che forniscono una panoramica dello stato di salute del vostro sito web.

Questi test si dividono in due categorie: test diretti, in esecuzione sul caricamento della pagina, e test asincroni, che possono richiedere un certo tempo per essere completati, e saranno eseguiti in seguito tramite chiamate JavaScript.

In precedenza, questi test venivano eseguiti con una chiamata a admin-ajax.php. Con WordPress 5.6, le cose si spostano da admin-ajax.php e al loro posto sarà utilizzato un nuovo endpoint della REST API. A partire da WordPress 5.6, i test asincroni si trovano sotto il namespace /wp-json/wp-site-health/v1.

Grazie a questo miglioramento della API REST, anche i plugin e i temi sono in grado di utilizzare gli endpoint REST e non si limitano alle azioni Ajax per i loro test di salute del sito.

Ogni test asincrono può ora dichiarare l’argomento has_rest il cui valore è false di default.

Il codice sottostante, tratto da wp-admin/includes/class-wp-site-health.php, mostra l’array dei test asincroni di WordPress 5.6:

'async'  => array(
    'dotorg_communication' => array(
        'label'             => __( 'Communication with WordPress.org' ),
        'test'              => rest_url( 'wp-site-health/v1/tests/dotorg-communication' ),
        'has_rest'          => true,
        'async_direct_test' => array( WP_Site_Health::get_instance(), 'get_test_dotorg_communication' ),
    ),
    'background_updates'   => array(
        'label'             => __( 'Background updates' ),
        'test'              => rest_url( 'wp-site-health/v1/tests/background-updates' ),
        'has_rest'          => true,
        'async_direct_test' => array( WP_Site_Health::get_instance(), 'get_test_background_updates' ),
    ),
    'loopback_requests'    => array(
        'label'             => __( 'Loopback request' ),
        'test'              => rest_url( 'wp-site-health/v1/tests/loopback-requests' ),
        'has_rest'          => true,
        'async_direct_test' => array( WP_Site_Health::get_instance(), 'get_test_loopback_requests' ),
    ),
    'authorization_header' => array(
        'label'     => __( 'Authorization header' ),
        'test'      => rest_url( 'wp-site-health/v1/tests/authorization-header' ),
        'has_rest'  => true,
        'headers'   => array( 'Authorization' => 'Basic ' . base64_encode( 'user:pwd' ) ),
        'skip_cron' => true,
    ),
),

Controlli Programmati di Site Health:

Mentre i test asincroni sono stati implementati per prevenire il caricamento di pagine lente e i timeout, tale preoccupazione non esiste con i test programmati.

Tenuto conto di questo, oltre all’argomento has_rest di cui abbiamo parlato qui sopra, gli array dei test possono anche dichiarare l’argomento async_direct_test (si veda il codice qui sopra), che dovrebbe essere un’istanza callable di un test.

Se un test viene eseguito durante un evento programmato, il test non utilizzerà l’endpoint della REST API ma verrà eseguito direttamente.

Password delle Applicazioni per l’Autenticazione della REST API

Application Passwords (Password delle Applicazioni) è un nuovo sistema per effettuare richieste autenticate a varie API WordPress.

Le password sono lunghe 24 caratteri e consistono di caratteri maiuscoli, minuscoli e numerici, che possono essere generati manualmente o attraverso la REST API.

Per generare manualmente una nuova password delle applicazioni, andate alla schermata Profilo e scorrete la pagina.

Scegliete un nome per la vostra Password delle applicazioni e confermate. WordPress visualizzerà la nuova password.

Le password delle applicazioni vengono visualizzate in blocchi di 4 caratteri, separati da spazi, come mostrato di seguito:

gsUc UhkU 0ScI gdRd TGoU vrW5

Tuttavia, le password possono essere utilizzate con o senza spazi:

Le password delle applicazioni passate attraverso il flusso di autorizzazione non includono spazi. Gli spazi sono lì solo per rendere permettere di inserire facilmente una stringa lunga se la si inserisce manualmente.

Possono essere utilizzate a pezzi, senza spazi, oppure, se lo si volesse, si potrebbe probabilmente aggiungere uno spazio dopo ogni carattere.

Nella schermata del profilo utente è possibile visualizzare, creare e revocare le password delle applicazioni. Le colonne Last Used e Last IP permettono di trovare facilmente le password non più utilizzate e/o che devono essere revocate.

Al momento della stesura di questo articolo, le Application Passwords possono essere utilizzate con le richieste autenticate della REST API e con la legacy XML-RPC API. Tuttavia, potremmo vedere le Application Passwords utilizzate con altre API in futuro.
George Stephanis spiega:

Lo schema di autenticazione delle password delle applicazioni può essere applicato anche alle future API di WordPress non appena saranno disponibili. Per esempio, se GraphQL o altri sistemi sono abilitati in WordPress, le password delle applicazioni forniranno loro una solida e collaudata infrastruttura di autenticazione da cui partire.

Non è possibile utilizzare le password delle applicazioni su wp-login.php.

Per una analisi più dettagliata di questa funzionalità e per approfondimenti più tecnici, date un’occhiata alle seguenti risorse:

• Proposal: REST API Authentication / Application Passwords
• Application Passwords: Integration Guide
• Application Passwords feature plugin

Migliore Supporto di PHP 8

PHP 8.0 introduce molte nuove funzionalità e ottimizzazioni che ne fanno una vera e propria pietra miliare nell’evoluzione del linguaggio. La versione più recente di PHP contiene molti aggiornamenti che impediscono la retrocompatibilità mentre molte funzionalità deprecate sono state ufficialmente rimosse. Quindi, aggiungere il supporto di PHP 8 in WordPress è una grande sfida.

Infatti, anche se il team di lavoro del Core di WordPress si è impegnato a fondo per rendere WordPress 5.6 compatibile con PHP 8, non potevamo aspettarci di veder risolto ogni possibile problema. L’obiettivo è quello di raggiungere un punto in cui l’intero ecosistema di WordPress sia compatibile con PHP 8, cosa che al momento sembra davvero difficile.

Inoltre, ogni sito WordPress comprende almeno un tema e un numero variabile di plugin. Quindi, anche se ci dovessimo attendere un buon supporto di PHP 8 nel Core di WordPress, sarebbe difficile credere che i plugin e i temi arrivino rapidamente a supportare PHP 8.

Siamo d’accordo con Jonathan Desrosiers quando afferma:

Lo stato del supporto di PHP 8 all’interno dell’ecosistema in senso ampio (plugin, temi, ecc.) è impossibile da conoscere. Per questo motivo, WordPress 5.6 dovrebbe essere considerato “beta compatibile” con PHP 8.

“Beta compatibile con PHP 8” sembra una buona espressione per rappresentare un processo continuo che richiede ancora grandi sforzi, ma allo stesso tempo riconosce il grande lavoro svolto finora.

Tuttavia,

Tutti coloro che sviluppano plugin e temi, così come le compagnie di hosting, sono chiamati a rendere il loro codice compatibile con PHP 8. Questo permetterà a WordPress di raggiungere prima una vera e propria “piena compatibilità”, e senza che gli utenti finali debbano portarne il peso.

Alcuni Novità di PHP 8 di Cui Tenere Conto

Come abbiamo detto, la piena compatibilità di WordPress con PHP 8 è un lavoro in corso. Jonathan Desrosiers fornisce un elenco di funzionalità e di modifiche di PHP 8 che chi sviluppa WordPress dovrebbero conoscere.

Named Parameters

Con i named arguments di PHP è ora possibile passare gli argomenti a una funzione in base al nome del parametro, piuttosto che alla posizione del parametro. Questo permette di scrivere codice che si auto-documenta, gli argomenti sono indipendenti dall’ordine e i valori di default possono essere arbitrariamente saltati.

Purtroppo, al momento i named parameters possono causare problemi di retrocompatibilità in WordPress. Il motivo principale è che i nomi dei parametri sono soggetti a modifiche senza preavviso fino al completamento dell’audit in corso. Quindi, al momento in cui scriviamo questo articolo:

L’uso di parametri denominati nella chiamata delle funzioni e dei metodi di classe di WordPress non è esplicitamente supportato e si sconsiglia vivamente l’utilizzo dei named parameters fino al completamento di questo audit, in quanto durante l’audit i nomi dei parametri sono soggetti a modifiche senza preavviso. Quando questo audit sarà completato, lo annunceremo in una futura nota di sviluppo.

Rigorose Validazioni Tipo/Valore per le Funzioni Interne

Quando si passa un tipo di parametro non consentito, le funzioni interne e quelle definite dall’utente si comportano in modo diverso. Le funzioni definite dall’utente emettono un TypeError, mentre le funzioni interne si comportano in diversi modi, a seconda di diverse condizioni.

Per rimuovere queste incongruenze, in PHP 8 le API interne di parsing dei parametri generano sempre un ThrowError in caso di discrepanza del tipo di parametro.

Il Core di WordPress non utilizza una rigorosa dichiarazione dei tipi. Tuttavia, le persone che contribuiscono al Core stanno lavorando per evitare che i tipi non validi vengano passati alle funzioni del Core. Fino a quando questo lavoro non sarà completato, questa modifica di PHP 8 può portare a TypeErrors, “specialmente se il tipo di un valore è cambiato in modo non corretto attraverso il codice agganciato a un filtro”.

Controlli dei Tipi Più Rigorosi per Operatori Aritmetici e Bitwise

Nelle versioni precedenti di PHP, l’utilizzo di operatori aritmetici e bitwise per un array, una risorsa o un oggetto non overloaded era permesso, ma il comportamento era incoerente e a volte anche irragionevole:

var_dump([] % [42]);
// int(0)

Con PHP 8, il comportamento è sempre lo stesso e tutti gli operatori aritmetici e bitwise lanceranno un’eccezione TypeError quando l’operando è un array, una risorsa o un oggetto non overloaded (v. RFC).

Questa è un’altra modifica che richiede lavoro extra da parte di chi contribuisce al Core, come le modifiche ai molti errori, avvisi e notifiche.

Anche in questo caso, a causa dei diversi problemi ancora irrisolti, si consiglia vivamente di eseguire test di compatibilità in un ambiente di staging o di sviluppo prima di passare a PHP 8 sul vostro sito live. Maggiori info su WordPress e PHP 8.0.

Altre Modifiche di Interesse degli Sviluppatori

WordPress 5.6 porta un sacco di modifiche per chi si occupa di sviluppo, ma non abbiamo potuto includerle tutte nella nostra lista. Ecco i primi 3 che pensiamo valga la pena tenere a mente:

1. Action Hook wp_after_insert_post

Prima di WordPress 5.6 si poteva utilizzare save_posts o azioni simili per eseguire codice personalizzato dopo la pubblicazione di un post. Ora WordPress 5.6 introduce il nuovo action hook wp_after_insert_post, che si attiva solo dopo che i termini e i metadati sono stati salvati.

Inoltre, sono state aggiornate diverse funzioni per evitare l’attivazione di questi hook. Il nuovo parametro $fire_after_hooks è stato aggiunto alle funzioni wp_insert_posts(), wp_update_post() e wp_insert_attachment(). Se impostato su false, impedisce l’attivazione degli hooks after insert.

Consultate le note di sviluppo per un’analisi più approfondita.

2. Typecasting

Le funzioni di typecasting intval(), strval(), floatval() e boolval() sono state rimosse dal Core in favore del typecasting diretto:

1. intval() → (int)
2. strval() → (string)
3. floatval() → (float)

Questo cambiamento ha effetti diretti sulle prestazioni, poiché il typecasting diretto è circa 6 volte più veloce delle funzioni di typecasting.

3. Oggetti WP_Error

La classe WP_Error è stata migliorata per consentire l’accorpamento di più istanze di WP_Error in una sola. In precedenza era possibile farlo solo manualmente. Ora, WordPress 5.6 introduce tre nuovi metodi per aiutare a gestire istanze multiple di WP_Error. Il codice qui sotto è un esempio presto dalle note di sviluppo:

<?php $error_1 = new WP_Error( 'code1', 'This is my first error message.', 'Error_Data' ); $error_2 = new WP_Error( 'code2', 'This is my second error message.', 'Error_Data2' ); // Merge from another WP_Error. $error_1->merge_from( $error_2 );
 
// Retrieve all error data, optionally for a specific error code.
$error_1->get_all_error_data( 'code2' );
 
// Export to another WP_Error
$error_1->export_to( $error_2 );

Altre Letture per Sviluppatori

È impossibile solo citare tutti le novità incentrate sullo sviluppo introdotte da WordPress 5.6, ma potete saperne di più leggendo queste risorse risorse:

• Updating jQuery version shipped with WordPress
• Updating core jQuery to version 3 – part 2
• WordPress and PHP 8.0
• REST API Batch Framework in WordPress 5.6
• Miscellaneous developer focused changes in WordPress 5.6

Riepilogo

WordPress 5.6 è una release importante con un sacco di funzionalità e modifiche sia per utenti che per sviluppatori. Siamo sempre felici di vedere come l’evoluzione delle tecnologie web influisca direttamente sulla sicurezza, le prestazioni, l’usabilità e l’accessibilità di WordPress.

Ma l’evoluzione non si ferma mai e possiamo già dare una sbirciatina alle future possibili date di uscita delle prossime versioni.

Ora tocca a voi: Cosa vi piace di più in WordPress 5.6? E quali funzionalità vorreste vedere in WordPress 5.7?