PHP 8.2: cosa significa per WordPress, plugin e sviluppatori?

Pubblicato: 2022-12-14

PHP 8.2.0 ha fatto il suo debutto l'8 dicembre 2022. Come aggiornamento principale, apporta miglioramenti delle prestazioni, sintassi più semplice e maggiore sicurezza dei tipi con null , false e true come tipi autonomi. Uno dei maggiori cambiamenti che probabilmente metteranno alla prova gli sviluppatori di WordPress è l'introduzione di classi di sola lettura , che non consentono proprietà dinamiche.

Le proprietà dinamiche sono deprecate e produrranno un errore fatale in PHP 9 o possibilmente PHP 10. Sebbene potenzialmente doloroso, specialmente per il core di WordPress, la deprecazione è una caratteristica chiave e un regalo per gli sviluppatori di PHP.

Diamo un'occhiata alla recente evoluzione di PHP e anche al modo in cui gli sviluppatori di WordPress mantengono la compatibilità con le versioni precedenti sfruttando al contempo le nuove funzionalità quando andranno a vantaggio degli utenti finali.

Tenere il passo con lo sviluppo PHP in WordPress

Poiché il core di WordPress mantiene una significativa compatibilità con le versioni precedenti senza date di fine vita pianificate in cui le vecchie versioni non saranno supportate, spetta alle aziende di WordPress determinare il ciclo di vita del proprio prodotto o servizio e le versioni di PHP che supporteranno.

Contrariamente a WooCommerce, che richiede almeno PHP 7.4, il core di WordPress attualmente consiglia solo PHP 7.4 o superiore. "Funziona anche con" PHP 5.6.20, che ha raggiunto la data di fine vita alla fine del 2018. Il progetto WordPress ne prende atto e avverte che l'utilizzo di versioni PHP non supportate "potrebbe esporre il tuo sito a vulnerabilità di sicurezza". (Requisiti di WordPress.org)

Fortunatamente, solo il 5,1% di tutti i siti WordPress utilizza attualmente PHP 5.6 e solo il 2% utilizza una versione ancora più vecchia. Il 20% utilizza PHP da 7.0 a 7.3 e il gruppo più numeroso (56,7%) utilizza PHP 7.4. (Statistiche di WordPress.org)

Sfortunatamente, PHP 7.4 ha appena raggiunto la sua data EOL alla fine di novembre 2022. PHP 8.0 ha meno di un anno per il suo supporto ufficiale di sicurezza per la maggior parte del 2023. La versione corrente e supportata attivamente, PHP 8.1, scadrà alla fine del 2024. PHP 8.2, che ha appena avuto il suo primo rilascio stabile, avrà il supporto per la sicurezza fino a dicembre 2025.

Si tratta di un ciclo di rilascio rapido e non sorprende che l'ecosistema di WordPress faccia fatica a stargli dietro. Con oltre la metà del web in esecuzione su WordPress, è una grande nave che non può virare velocemente. È molto più un atto di bilanciamento che una corsa verso l'orlo sanguinante. Il salto a PHP 8 offre molti vantaggi, tuttavia, con grandi funzionalità di miglioramento delle prestazioni come la compilazione PHP Just-in-Time (JIT) in fase di esecuzione per un'esecuzione più rapida con un minore utilizzo della memoria.

Il compromesso tra compatibilità con le versioni precedenti e stabilità, lungimiranza e innovazione

Il compromesso tra soddisfare il più vasto pubblico possibile di utenti e mantenere la conformità con PHP ha sempre posto un dilemma per gli sviluppatori, gli host e le aziende produttrici di WordPress. Agenzie e liberi professionisti con clienti a lungo termine e siti legacy affrontano lo stesso problema: l'aggiornamento dei requisiti minimi può costringere i clienti esistenti ad apportare modifiche significative ai loro siti o vederli fallire.

Da un lato, i vantaggi di rimanere aggiornati con PHP sono il miglioramento della sicurezza e delle prestazioni e gli ultimi concetti e funzionalità di programmazione per gli sviluppatori. D'altra parte, il principale vantaggio di ritardare il PHP minimo richiesto è una base di clienti felice (anche se compiacente) e ampia. È una situazione del tipo "pagami ora o pagami dopo". Ad un certo punto, devi strappare il cerotto.

Buoni dati e dati di telemetria sugli ambienti degli utenti possono aiutare a determinare il tempo meno dirompente per aumentare un requisito minimo di versione PHP. La maggior parte degli sviluppatori di plug-in tiene d'occhio questi numeri con i propri strumenti, in quanto non fa parte dei dati di installazione attiva del repository di plug-in di WordPress.org. Inevitabilmente, qualsiasi modifica potenzialmente rivoluzionaria che abbia un impatto su molte persone si tradurrà sicuramente in una raffica di ticket di supporto.

Dare la priorità alla compatibilità con le versioni precedenti comporta anche un elevato lavoro di manutenzione. Supportare una base di utenti molto ampia e diversificata è ottimo per l'utente finale, ma significa che gli sviluppatori devono mantenere il loro codice funzionante con molti ambienti diversi. "Adoro supportare le versioni precedenti di PHP man mano che vengono aggiunte nuove funzionalità", ha detto nessuno sviluppatore, mai!

Non è solo il PHP legacy di cui devono preoccuparsi, ma anche i database legacy e dozzine di altre varianti nello stack di WordPress. I casi limite emergono e confondono anche gli esperti quando esiste un ampio spettro di ambienti server WordPress con elementi obsoleti.

Il momento migliore per aumentare i requisiti minimi di PHP

La versione 7.2 di iThemes Security Pro è un buon esempio di aumento del requisito PHP minimo di un prodotto WordPress per offrire innovazione e stabilità ai clienti esistenti.

A partire dalla versione 7.2, iThemes Security Pro richiede PHP 7.3 o versioni successive e supporta fino a 8.1. La decisione di aggiornare i requisiti PHP per iThemes Security Pro è stata presa per implementare il framework WebAuthn. L'implementazione richiede librerie che necessitano di PHP 7.3+ per gestire la crittografia e le chiavi pubbliche. Le funzionalità di accesso 2FA, passkey e biometrico introdotte in iThemes Security Pro 7.2 sono il risultato diretto di questa decisione. In un momento in cui le sue password chiare vengono violate, il team di sicurezza di iThemes ha portato per la prima volta l'accesso senza password a WordPress come esperienza di autenticazione utente principale.

Sarebbe stato possibile creare queste funzionalità riscrivendo le librerie WebAuthn per compatibilità con le versioni precedenti di PHP. Ovviamente, sarebbe molto più lavoro e creerebbe codice aggiuntivo da mantenere. La cosa più saggia era tenere il passo con la comunità PHP a un ritmo moderato adottando dipendenze che richiedono PHP 7.3 o superiore. La maggior parte dei loro utenti era già lì. Ecco perché il team di sviluppo di iThemes Security ha deciso di aumentare il requisito minimo di PHP per gli utenti nuovi ed esistenti.

Per i prodotti WordPress che sono fortemente investiti nell'editor di blocchi Gutenberg, come GiveWP, la gestione del cambiamento può essere ancora più impegnativa. La stabilità e il lento tasso di cambiamento nel core di WordPress possono essere frustranti per gli sviluppatori PHP back-end, ma consentono agli sviluppatori JavaScript/React front-end di portare avanti la piattaforma.

Jason Adams, responsabile dello sviluppo di GiveWP, osserva che non devono essere compatibili con le versioni precedenti perché possono migrare gli utenti tra le versioni man mano che l'editor del sito si evolve. Tuttavia, "Non esiste una migrazione per PHP", ha commentato. Alla fine, dovranno adattarsi all'architettura PHP 9 e allontanarsi dalle nuove funzionalità deprecate in PHP 8.2.

Non esiste un singolo "momento giusto" per ogni prodotto dell'ecosistema WordPress per aggiornare i requisiti minimi di PHP. "Non è un problema che puoi risolvere filosoficamente", mi ha detto Adams. Dipende davvero da un giudizio basato su quanti utenti saranno influenzati negativamente dal cambiamento. Se il 90% o più è su PHP 7.2 o 7.4, è possibile aumentare il requisito minimo a quel livello.

Questi numeri possono variare notevolmente a seconda della base di utenti specifica di un prodotto, afferma Adams. Un prodotto utilizzato da clienti tecnicamente più esperti tenderà ad essere più vicino alle versioni PHP attualmente supportate. Un prodotto come GiveWP, con molte organizzazioni senza scopo di lucro che lo utilizzano, dovrà dare più peso alla compatibilità con le versioni precedenti. Un altro modo per andare avanti è lasciare che il codice legacy e i suoi utenti si ramifichino in una versione a lungo termine che sarà supportata ma non vedrà l'aggiunta di nuove funzionalità. Quando gli utenti sono pronti per effettuare l'aggiornamento, possono migrare a una nuova versione principale creata per la futura compatibilità con PHP.

Gli avvisi di deprecazione promuovono lo sviluppo

WordPress.com ha appena implementato PHP 8.2 come opzione per i suoi piani Business ed E-commerce con le funzionalità di hosting attivate e, nell'ecosistema WordPress.org, è improbabile che il vecchio codice ragionevolmente ben progettato si rompa o diventi insicuro con la prossima versione principale di PHP pubblicazione. Anche se la base di codice principale di WordPress.org offre ufficialmente solo il supporto "beta" per PHP 8.0, generalmente funziona bene con le ultime versioni di PHP, così come i plugin ben supportati. Non genereranno errori fatali o di analisi. Non dovresti nemmeno vedere molti avvisi con il debug attivato. Potresti vedere molti avvisi di funzioni deprecate, che non sono ancora errori.

Le frustrazioni di un veloce ciclo di rilascio di PHP hanno molto a che fare con gli sviluppatori che si impantanano nel refactoring del loro codice e giocano al recupero con aspetti deprecati di PHP. Questo lavoro critico può lasciare loro meno tempo per esplorare e innovare con nuovi concetti e funzionalità offerti dall'ultima versione di PHP.

C'è un altro modo di vedere questa situazione. Affrontare le funzionalità obsolete di PHP è in realtà lungimirante e costringe gli sviluppatori a diventare fluenti nelle successive iterazioni di un linguaggio in evoluzione. Senza questo esercizio in qualche modo forzato, la conoscenza esistente si adatterebbe più facilmente a vecchie abitudini che diventeranno cattive quando saranno obsolete.

Gli avvisi di deprecazione indicano cose che funzionano ora ma che non funzioneranno nelle versioni future di PHP. Questo è un bene per te se sei uno sviluppatore, come spiega Brent Roose. Se gli sviluppatori prestano attenzione a questi avvisi, avranno tutto il tempo per recuperare qualsiasi codice obsoleto. E non dovrebbe essere un blocco per gli aggiornamenti delle versioni minori.

Timothy Jacobs, iThemes Security Lead Developer e WordPress Core Committer, afferma che è bene avere avvisi di deprecazione. Spingono gli sviluppatori ad adottare un codice "più corretto" e "meno fragile" che sarà sempre più sicuro, performante, a prova di errore e maggiormente in grado di far fronte ai casi limite. In questa prospettiva, E_DEPRECATED nota che riempire il registro degli errori è "come un sistema di allerta precoce che le cose si romperanno in futuro, ma non lo sono ora".

Fare a meno delle proprietà dinamiche dopo PHP 8.2

La logica di Nikita Popov per l'eliminazione graduale delle proprietà dinamiche in PHP 9 è un buon esempio della spinta evolutiva di PHP verso un codice più resiliente e convenzioni di programmazione:

La motivazione di questo cambiamento è duplice: prevenire errori (dovuti a refusi o rinominazioni) nel caso comune e rendere espliciti gli usi intenzionali. Il problema principale è che la lettura da una proprietà inesistente genera una diagnostica che rende immediatamente evidente il problema, mentre la scrittura su una proprietà inesistente è completamente silenziosa. PHP non fornisce alcuna indicazione che il programmatore abbia commesso un errore.

Il video di due minuti di Brent Roose sull'evoluzione da PHP 5.6 a 8.2 è una brillante e semplice illustrazione visiva di quanto sia arrivato PHP dal 2014 ad oggi. Usando l'esempio di un semplice oggetto di trasferimento dati, Roose mostra come il codice PHP 5.6 si riduca drasticamente a un blocco di codice molto più semplice, più snello e nel complesso più elegante sulla strada per PHP 8.2.

Come osserva Roose nei suoi suggerimenti per gestire le proprietà dinamiche (che sono deprecate in PHP 8.2), gli sviluppatori dovrebbero avere un sacco di spazio per aggiornare il loro codice esistente prima che gli avvisi di deprecazione si trasformino in errori fatali. Quella passerella diminuirà rapidamente, tuttavia, e WordPress è un caso speciale. Tonya Mork ha una proposta accettata in Trac per la gestione delle deprecazioni di proprietà dinamiche sconosciute nel core di WordPress. Lei e Juliette Reinders Folmer temono che gli sviluppatori di WordPress non avranno abbastanza tempo per rifattorizzare il loro codice, per non parlare delle sfide speciali di mantenere la compatibilità con le versioni precedenti per un progetto di vent'anni. Mork, Reinders Folmer e Sergey Biryukov sono stati gli eroi in gran parte sconosciuti di questo arduo compito.

Nella loro discussione sulle proprietà dinamiche e sui metodi magici in PHP 8.2, Mork e Reinders Folmer sottolineano che le radici di WordPress in PHP 3 e 4 lo mantengono in un universo di programmazione solidamente procedurale mentre PHP continua ad avanzare come linguaggio orientato agli oggetti. Gli sviluppatori principali devono trovare un modo per mantenere il comportamento del codice legacy nel PHP di oggi senza rompere la compatibilità con le versioni precedenti "e rendere comunque il codice migliore e più sicuro e mitigare la deprecazione delle proprietà dinamiche di PHP 8.2", come afferma Reinders Folmer. "In realtà ci stiamo rendendo la vita molto difficile con la regola di non [compatibilità con le versioni precedenti] [del core di WordPress]", osserva nel video.

“C'è una buona ragione per farlo”, risponde Mork, “è per gli utenti. Gli utenti hanno fiducia di poter premere quel pulsante e aggiornare, e che abbiamo pensato alla compatibilità con le versioni precedenti, che abbiamo dato la priorità. È una pietra miliare per noi... in modo che gli utenti possano essere sicuri di eseguire l'aggiornamento."

Tutto lo sviluppo è manutenzione...

È una sfida unica provare a eseguire il backport di PHP "moderno" per lavorare con le due precedenti versioni principali di PHP per mantenere la compatibilità con le versioni precedenti nel core di WordPress. Gli sviluppatori di plug-in hanno un compito molto più semplice nell'aggiornare il loro codice in modi che possano sfruttare le nuove funzionalità, come le classi di sola lettura di PHP 8.2 e la deprecazione delle proprietà dinamiche. Gran parte di questo lavoro è in gran parte anche una forma di manutenzione.

Dal punto di vista dell'architettura, i cambiamenti di PHP 8+ stanno focalizzando l'attenzione su concetti di programmazione come l'immutabilità. Le strutture di dati immutabili "non risolvono intrinsecamente i problemi di sicurezza", ma aiutano il codice degli sviluppatori a essere meno soggetto a errori e più corretto, secondo Jacobs:

Non direi che una struttura di dati immutabile sia intrinsecamente sicura e una struttura di dati mutabile sia insicura. Piuttosto, le strutture di dati immutabili possono aiutare a eliminare gli errori di programmazione che possono portare a problemi di sicurezza. Riducendo il numero di stati diversi in cui può esistere il nostro codice, possiamo ridurre la complessità del nostro codice e quindi ridurre le possibilità di commettere errori.

Il miglior motivo per mantenere il codice allo standard delle versioni PHP attivamente supportate è la riduzione dei rischi per la sicurezza. PHP 8.2 introduce utili comodità e "guard rail" secondo Adams, ma poco che entusiasmerà i programmatori o sarà visto come un punto di svolta. Qualcosa come l'attributo #[\SensitiveParameter] potrebbe essere più significativo dal punto di vista pratico poiché consente di filtrare i dati sensibili dalle tracce dello stack che spesso vanno a servizi di terze parti. Introdotti in PHP 8, gli attributi sono la scelta di Adams per l'ultima innovazione che ha attirato la sua attenzione per abilitare qualcosa che non si poteva fare in precedenza: "descrivere qualcosa [come classi, variabili, metodi, ecc.] da una meta-prospettiva".

Sfruttare le nuove funzionalità di PHP da 8.0 a 8.2 e le versioni future è dove la creatività degli sviluppatori può brillare, ma semplicemente supportare quelle versioni, in modo che i plugin e il core di WordPress non si rompano su di esse, è sia pratico che vitale.

…E tutta la manutenzione è arte

Jeff Atwood ha un vecchio ma eccezionale post sul blog intitolato "The Noble Art of Maintenance Programming" che ho letto di recente, grazie alla Hacker Newsletter di Kale Davis. "La programmazione della manutenzione è ampiamente vista come un lavoro di pulizia", ​​scrive Atwood. Questo mi ha ricordato l'artista Mirele Laderman Ukeles, il cui "Maintenance Art Manifesto" mi ha sempre colpito come molto rilevante per la programmazione e lo sviluppo web:

Due sistemi di base: sviluppo e manutenzione. La palla acida di ogni rivoluzione: dopo la rivoluzione, chi raccoglierà la spazzatura lunedì mattina? […] I sistemi di sviluppo sono sistemi di feedback parziali con ampi margini di cambiamento. I sistemi di manutenzione sono sistemi di feedback diretto con poco spazio per modifiche.

Laderman Ukeles era una giovane artista e neomamma nel 1969 quando scrisse il manifesto e dichiarò Maintenance is Art. Era frustrata dal modo in cui le opere d'arte all'avanguardia e il lavoro di alto rango sono separati dal lavoro che le rende possibili: genitorialità, insegnamento di abilità artistiche e tradizioni o semplicemente allestire una mostra d'arte. Ha fatto una mostra memorabile basata su se stessa come custode di un museo. Poi ha trascorso la maggior parte della sua carriera (in corso) come artista residente del New York City Department of Sanitation. Il suo primo progetto in quel ruolo è stato ringraziare personalmente tutti gli 8.500 operatori sanitari "per aver tenuto in vita New York".

Atwood ha una visione simile della programmazione. Cita diverse figure importanti dell'ingegneria del software che affermano che la denigrazione del lavoro di manutenzione è del tutto sbagliata. Robert L. Glass ha ritenuto che "la manutenzione è una sfida intellettuale significativa, nonché una soluzione e non un problema", quindi dovrebbe essere considerata un compito importante per le persone più qualificate. Joel Spolsky ha scritto molto tempo fa che gli sviluppatori sono pigri e il motivo per cui "vogliono sempre buttare via il codice e ricominciare da capo" è che "è più difficile leggere il codice che scriverlo".

In una conversazione con Andy Hunt, Dave Thomas ha affermato: “Tutta la programmazione è programmazione di manutenzione perché raramente scrivi codice originale. …. Trascorri la maggior parte del tuo tempo in modalità manutenzione. Quindi puoi anche mordere il proiettile e dire: "Sto mantenendo dal primo giorno". Le discipline che si applicano alla manutenzione dovrebbero applicarsi a livello globale”. Hunt ha concordato: “Sono solo i primi 10 minuti che il codice è originale quando lo digiti per la prima volta. Questo è tutto."

Atwood alla fine si appoggia a questo punto di vista, ma fa eco alla comune prospettiva degli sviluppatori di WordPress che ho sentito da Jason Adams e Timothy Jacobs. L'arte speciale dello sviluppo/manutenzione di WordPress?

"È un atto di bilanciamento."

Il miglior plug-in di sicurezza per WordPress per proteggere e proteggere WordPress ora con uno sconto del 35%!

WordPress attualmente alimenta oltre il 40% di tutti i siti Web, quindi è diventato un facile bersaglio per gli hacker con intenti dannosi. Il plug-in iThemes Security Pro elimina le congetture dalla sicurezza di WordPress per semplificare la sicurezza e la protezione del tuo sito Web WordPress. È come avere un esperto di sicurezza a tempo pieno nello staff che monitora e protegge costantemente il tuo sito WordPress per te.

Risparmia subito il 35%!