Passare a PHP 8.x in quattro passaggi: un'intervista con Juliette Reinders Folmer

L'aggiornamento di un sito, plug-in o tema WordPress a una nuova versione di PHP è un'attività che ricorre regolarmente. Ma come farlo nel modo più efficiente possibile? Come fai a sapere che non trascurerai nulla? Esiste una tabella di marcia per questo?

In questo articolo, affronteremo queste domande (e altre) e esamineremo cosa comporta una transizione graduale a PHP 8.x per il tuo sito, plugin o tema WordPress, inclusa una roadmap.

Lo faremo sulla base di un'intervista che abbiamo condotto con l'esperta di PHP Juliette Reinders Folmer. Dedica gran parte della sua vita quotidiana alla programmazione e a tutto ciò che la circonda, concentrandosi principalmente su progetti open-source, tra cui WordPress.

Sei pronto anche tu a fare il passaggio senza intoppi? Curioso del nostro piano passo-passo? Allora tuffiamoci dentro!

PHP 8.x — Cosa è cambiato

Per una panoramica delle modifiche, consigliamo i seguenti articoli:

• Note di rilascio per PHP 8.0 e PHP 8.1
• Guida alla migrazione per PHP 8.0 e PHP 8.1
• WordPress e PHP 8.0 e stato attuale
• Novità di PHP 8.0 e PHP 8.1

Dopo aver letto questi articoli, sarai completamente aggiornato su cosa è cambiato in PHP 8.xe cosa devi fare per far funzionare i tuoi progetti PHP senza problemi.

Se non sei sicuro di quale sia il modo migliore per iniziare, nessun problema. Nella conversazione con Juliette, ne abbiamo discusso in dettaglio e in questo articolo ti spiegheremo nel modo più completo possibile come passare a PHP 8.x.

Spiegheremo anche in riquadri informativi come eseguire varie operazioni in MyKinsta, il nostro pannello di controllo proprietario per tutti i vostri siti, applicazioni e database WordPress.

Passare a PHP 8.x: come iniziare

Passare a PHP 8.x sembra semplice e tecnicamente lo è. Molti host ti consentono di specificare quale versione di PHP desideri utilizzare per il tuo sito Web nel pannello di amministrazione. Su Kinsta, cambiare la versione di PHP può essere fatto con un solo clic nel cruscotto di MyKinsta.

Ma prima di farlo, ci sono alcune cose di cui devi essere sicuro. A seconda del tuo livello di conoscenza ed esperienza, ti consigliamo quanto segue:

• Se hai creato il tuo sito WordPress con temi e plug-in standard, senza avere molta conoscenza di PHP, assumi uno sviluppatore o un'agenzia per verificare se il tuo sito è adatto per funzionare su PHP 8.x. Stai cercando una terza parte che possa aiutarti in questo? Quindi dai un'occhiata alla nostra pagina dei partner che elenca diverse aziende fidate che possono aiutarti.
• Se il tuo sito WordPress è stato creato da una parte esterna, uno sviluppatore o un'agenzia, contattali per chiedere se il tuo sito può essere eseguito su PHP 8.x.
• Se hai creato il tuo sito WordPress, ad esempio con il tuo tema personalizzato o plug-in sviluppati autonomamente, abbiamo una tabella di marcia per te di seguito.

Se il tuo sito rientra in una delle prime due categorie, ti invitiamo sicuramente a leggere il resto dell'articolo, ma ti sconsigliamo di iniziare a testare tu stesso la compatibilità con PHP 8. Lascialo ai professionisti.

Qualunque cosa tu scelga, ti consigliamo di non passare semplicemente al tuo sito live su PHP 8 e "vedere se funziona". Sei curioso di sapere come sarà il tuo sito e non vedi l'ora di vederlo girare su PHP 8? Quindi avvia i test all'interno di un ambiente di staging. Un buon host ti consentirà di creare facilmente un ambiente di staging.

Nell'ambiente di staging, puoi attivare PHP 8.x e vedere se questo aggiornamento funziona bene con il tuo sito. È anche possibile lavorare con una copia locale del tuo sito. Con il nostro strumento di sviluppo DevKinsta gratuito, potete importare facilmente il vostro sito dal cruscotto di MyKinsta, dopodiché potete cambiare la versione PHP in 8.0 o 8.1.

Se non vedi alcun problema nell'ambiente di staging, non significa necessariamente che non ci siano effettivamente problemi. La tabella di marcia qui sotto ti dirà perché.

Test di compatibilità PHP 8.x: la roadmap

Testing: la parola chiave per un buon software. Anche per i siti Web WordPress e i loro componenti, come temi, plug-in e il core di WordPress, il test è il mezzo per garantire che non accadano cose che non vuoi che accadano.

Un progetto di sviluppo software consiste in gran parte di test. In questo articolo, esaminiamo nello specifico i test che possono aiutarti a rendere agevole la transizione a PHP 8.x. Nel nostro articolo sugli strumenti DevOps, troverai una sezione con una raccolta di strumenti che puoi utilizzare.

I seguenti tipi di test sono discussi in questo post del blog:

Diamo un'occhiata più da vicino ai diversi tipi di test che possiamo eseguire.

Analisi statica (o test statico)

Il primo passo che puoi compiere come sviluppatore PHP è eseguire un'analisi statica del tuo codice con vari strumenti. L'analisi statica è il processo di analisi del software senza eseguire il codice. Con l'analisi statica, è possibile rilevare errori, rilevare problemi con la compatibilità di PHP 8.x, applicare standard di codifica (ad esempio, WordPress Coding Standards) e persino modificare e ripulire il codice.

Strumenti per l'analisi statica

È possibile eseguire un'analisi statica con vari strumenti, come ad esempio:

• Compatibilità PHP
• Salmo
• PHPStan

Al momento della scrittura, non tutti i controlli PHP 8.1 sono supportati nell'ultima versione di PHPCompatibility. I controlli PHP 8.1 possono essere nella versione di sviluppo, quindi assicurati di usarli (per ora) quando usi PHPCompatibility per analizzare il tuo progetto e vedere quali errori/raccomandazioni ci sono.

I controlli PHP 8.1 saranno presto rilasciati in una nuova versione principale . Se vuoi essere aggiornato su questo e hai un account GitHub, apri il repository GitHub di PHPCompatibility e vai su Watch -> Custom -> Releases , dove puoi scegliere di essere avvisato quando viene rilasciata una nuova versione.

PHPCompatibility, che verifica solo la compatibilità per una particolare versione (o gamma di versioni) di PHP, è facile da configurare. Ottieni i risultati migliori se esegui un testVersion, ad esempio 8.0+ (8.0 e versioni successive), all'interno di PHPCompatibility.

Dovresti cercare funzioni deprecate o cancellate, valori predefiniti modificati dei parametri di funzione, se usare concat senza parentesi, se usare match come nome di funzione (poiché è stato riservato da PHP 8.0), ecc.

Salmo e PHPStan sono buone aggiunte e possono aiutarti eseguendo controlli aggiuntivi relativi ai tipi di variabili. Lo svantaggio di questi strumenti è che ci vuole molta configurazione per ottenere report su PHP 8.0 e 8.1. Anche se hanno successo, puoi aspettarti molti falsi positivi. I falsi positivi sono notifiche fornite in modo errato, a causa delle limitazioni dell'analisi statica.

È necessaria una solida conoscenza per interpretare correttamente i risultati di questi due strumenti, ma tale conoscenza può aiutarti a identificare ulteriori incompatibilità che PHPCompatibility non riesce a trovare. Guarda la documentazione per Psalm e PHPStan se vuoi saperne di più su di loro.

Riepilogo:

• Esegui analisi statiche con PHPCompatibility, Psalm, PHPStan
• Risolvi tutti i problemi legittimi

Test unitario

Il passaggio successivo nel processo è il test unitario. Il test unitario è un metodo per testare singolarmente pezzi di codice. Nel test unitario, verranno sviluppati specifici test mirati per ciascuna unità. Ciò comporterà l'esecuzione di diversi scenari. Preferibilmente, ogni scenario viene testato separatamente dagli altri in modo che i test siano indipendenti l'uno dall'altro.

Avere test unitari da soli, ovviamente, non è sufficiente. Devono anche essere eseguiti. I test unitari sono meglio automatizzati utilizzando strumenti CI (integrazione continua) come Jenkins, GitHub Actions o Travis.

Supporto di più versioni di PHP

In qualità di generatore di plug-in, se desideri supportare più versioni PHP, assicurati che i test in CI vengano eseguiti su tutte le versioni PHP supportate.

Ovviamente puoi anche supportare solo le versioni più recenti, la scelta spetta interamente a te.

Il test con più versioni di PHP richiede l'utilizzo di più versioni di PHPUnit, a seconda della versione di PHP. Dal momento che PHPUnit ha introdotto diverse modifiche nel corso degli anni che influenzano il modo in cui vengono scritti i test, questa parte può essere complicata.

Per aggirare questo problema, puoi utilizzare PHPUnit Polyfills (scritto da Juliette e sponsorizzato da Yoast). Ciò ti consente di scrivere test che non sono ufficialmente supportati per PHPUnit 9 (e quindi possono essere eseguiti su PHP 8.x). I Polyfill quindi fanno funzionare i tuoi test in PHPUnit da 4.x a 9.x e con PHP da 5.4 a PHP 8.1 (a partire da ora).[/notice]

Ora che i test sono in esecuzione, il passaggio successivo consiste nell'assicurarsi che i problemi riscontrati nei test siano stati risolti.

Copertura del codice

L'esecuzione di questi test è il modo più affidabile per trovare incompatibilità tra versioni diverse.

Nel fare ciò, presta attenzione alla copertura del codice dei tuoi test:

• Supponiamo di avere una funzione A e di aver scritto un test per essa, e che la funzione A chiami le funzioni B, C e D come parte della logica nella funzione.
• Il test per la funzione A è scritto per testare la logica della funzione A, ma chiamerà anche le funzioni B, C e D durante il test. Per le funzioni B, C e D, di solito si testa solo il "percorso felice" - la situazione in cui tutto va bene - e quindi anche quelle funzioni non sono ancora completamente testate, sebbene (parte del) codice in quelle funzioni sia eseguito durante il test della funzione A.
• Per ciascuno dei tuoi test, indica quale codice viene specificamente testato. Puoi farlo assegnando a ogni test un @covers In questo modo, B, C e D non vengono "contati" nel calcolo della copertura del codice, che ti consente di vedere quale parte del tuo codice è coperta dai test.

Spesso gli sviluppatori scrivono e testano, a volte anche inconsapevolmente, il "percorso felice". In questi casi, è anche necessario testare cosa succede quando vengono passati dati imprevisti a una funzione. Il test con solo valori/tipi previsti non è sufficiente .

''Nei test devi assicurarti che una funzione faccia quello che dovrebbe fare, ma anche che una funzione non faccia quello che non dovrebbe.'' - Juliette Reinders Folmer Click to Tweet

La seconda parte della citazione di cui sopra è spesso dimenticata, quando forse è ancora più importante della prima parte. Cosa succede se passi un tipo errato? Hai ricevuto un messaggio di errore? O la variabile è stata lanciata con la funzione che continua normalmente? Cosa succede se viene passato un valore imprevisto alla funzione?

Assicurati di testare le tue funzioni con variabili, tipi e valori imprevisti. Solo allora puoi fare affidamento sui tuoi test per trovare i problemi che una nuova versione di PHP potrebbe causare.

PHP sta diventando più severo

PHP sta diventando più preciso (rigoroso) nel modo in cui gestisce i "tipi" per le funzioni proprie di PHP, così come cose come le proprietà dinamiche. Queste modifiche hanno generalmente lo scopo di aiutare gli sviluppatori a fornire codice privo di errori (beh, codice con meno errori). Ma questo può rappresentare un ostacolo all'aggiornamento per il codice preesistente scritto sulla base dei "vecchi" principi di PHP.

A causa di questa spinta verso messaggi di errore più utili in PHP, puoi vedere che rendere il codice esistente adatto alle nuove versioni di PHP richiede sempre più tempo. Rendere il codice che funzionava su PHP 5.6 adatto a PHP 7.0 ha richiesto solo una frazione del tempo nella maggior parte dei casi rispetto all'aggiornamento del codice per renderlo adatto a PHP 8.1. E questo nonostante il fatto che PHP 7.0 fosse una versione "principale", mentre PHP 8.1 è una "minore".

In molti casi, il test è ancora l'unico modo affidabile per determinare cosa deve essere modificato per supportare una nuova versione.

Il test unitario è possibile con vari strumenti, tra cui:

• Unità PHP
• Beffa
• Beh,
• Giocatore di storie

Molti di questi strumenti sono costruiti sulla base o in combinazione con PHPUnit.

In definitiva, non importa quali strumenti utilizzi. La cosa più importante è testare e far funzionare i test sulle nuove versioni di PHP. Questo passaggio a volte può essere molto complicato, ma fortunatamente, come accennato in precedenza, esistono strumenti per questo, come PHPUnit Polyfills.

Test d'integrazione

Il test di integrazione è il passaggio successivo che eseguiremo, dopo l'analisi statica e il test unitario. Un test di integrazione è dove le situazioni della vita reale vengono testate in un contesto più ampio di una semplice "unità di codice". Questi includono test con un database attivo (test) o test con un'API esterna, per fare solo due esempi.

Quindi, quando si testa il codice di un plugin o di un tema nel contesto di WordPress e si utilizza una versione reale, questi sono, per definizione, test di integrazione.

WP Test Utils (sempre scritto da Juliette e sponsorizzato da Yoast) è uno strumento eccellente per i test di integrazione. WP Test Utils fornisce strumenti per scrivere test di integrazione e unit test, in cui WordPress viene "riprodotto" utilizzando Brainmonkey e Mockery, dove le funzioni di WordPress comunemente utilizzate sono "false" in modo da testare il proprio codice e non il codice di WordPress.

Il test di integrazione con WordPress è una storia più complicata perché comporta l'integrazione con WordPress e la suite di test di WordPress. A seconda delle versioni di WordPress supportate da un plugin o da un tema, devi considerare quali versioni di PHPUnit sono supportate da WordPress stesso per eseguire i test su diverse versioni di PHP.

Ad esempio, WordPress da 5.6 a 5.8 utilizza PHPUnit da 5 a 7 per testare PHP da 5.6 a PHP 8.0, ma a partire da WordPress 5.9, WordPress stesso utilizza anche PHPUnit Polyfills per un supporto più ampio. WP Test Utils funge da ponte per superare tutte queste differenze.

Vuoi saperne di più su come eseguire test di integrazione su più versioni diverse di WordPress, incluso WordPress 5.9 e versioni successive? Quindi leggi a riguardo sul sito web di WordPress.

Test manuale

Ora che hai eseguito unit test e test di integrazione e hai risolto tutti i problemi riscontrati, è il momento di eseguire test manuali. Il tuo sito è in esecuzione e il tuo codice funziona, ma stai utilizzando anche i plug-in A, B e C. Sai se questi plug-in sono compatibili?

Ad esempio, controlla questo con gli autori del plugin e vedi se indicano che è compatibile con PHP 8.x. La domanda quindi, ovviamente, è come è stato testato il plugin. Spesso la risposta qui è: in isolamento. Le funzioni del plug-in sono state generalmente testate in combinazione con WordPress da solo, senza altri plug-in attivi. E anche se altri plug-in sono stati utilizzati all'interno di questi test, è probabile che non tutti i plug-in utilizzati da te facessero parte del test, quindi prendi tale dichiarazione di compatibilità con le pinze.

Ad esempio, un sito WordPress con 3 plugin (A, B e C). È possibile che il plug-in B, ad esempio, restituisca un tipo di variabile errato tramite un filtro, con cui il plug-in C, utilizzando lo stesso filtro, desidera lavorare. Ciò può quindi causare un errore irreversibile perché il tipo non è più quello previsto. Il plug-in C viene quindi visto come il colpevole del messaggio di errore, anche se il plug-in B è il vero colpevole.

Le incompatibilità di interoperabilità dei plug-in sono impossibili da scoprire durante il test in isolamento. Più plugin sono attivi, più è probabile che qualcosa vada storto. Ad esempio, sarebbe molto vantaggioso passare le richieste di pagina da un sito Web live a un ambiente di staging (con la registrazione degli errori abilitata) per scoprire cosa sta effettivamente andando storto.

Con questo tipo di problema, un proprietario del sito di solito vedrà solo un messaggio che c'è stato un errore con l'ultimo codice eseguito (in questo caso, dal plugin C), anche se il plugin C non è necessariamente la causa del problema.

Nella maggior parte dei casi, è coinvolto molto lavoro manuale e umano ed è necessaria una buona quantità di olio di gomito per rilevare e risolvere questi problemi. Questo potrebbe essere automatizzato utilizzando test end-to-end, ma non lo vediamo accadere molto in WordPress.

Verifica la disponibilità per i plug-in utilizzati

Per sviluppatori e team di sviluppo: accetta il codice solo quando i test sono disponibili. In questo modo, ti assicuri che siano necessari meno test manuali, il che ti fa risparmiare molto tempo.

Metti in discussione la sua strategia di test se desideri acquistare un plug-in o un tema commerciale. In questo modo, creiamo collettivamente consapevolezza tra gli sviluppatori/team di sviluppo nella community di WordPress per portare i test in cima all'ordine del giorno e tutti ne traiamo vantaggio.

I test sono spesso visti, ingiustamente, come un costo quando, in realtà, fanno risparmiare denaro. L'investimento extra richiesto per scrivere i test ripaga sotto forma di un numero significativamente inferiore di segnalazioni di bug e meno tempo speso per correggere i bug. Inoltre, con i test automatizzati del software, le estensioni e le modifiche possono essere eseguite più rapidamente perché i test possono confermare rapidamente che le funzionalità esistenti continuano a funzionare.

''Sii gentile con te stesso in futuro, per favore ;-)'' - Juliette Reinders Folmer Click to Tweet

Il ruolo degli host WordPress e PHP 8.x

Per il proprietario medio del sito, la guida del tuo host è altamente desiderabile. Considera quanto segue:

• Documentazione e aggiornamenti per i clienti che WordPress Core, plugin e/o temi non sono (in alcuni casi) compatibili con la versione incrociata di PHP
• Opzioni per il test (come lavorare con un ambiente di staging)
• Metodi per la segnalazione degli errori e per contattare l'assistenza

Ciò avvantaggia anche un host web, poiché i proprietari dei siti spesso contattano l'host per chiedere aiuto in caso di problemi. Nel caso di un passaggio a PHP 8.0 o 8.1, il proprietario del sito è responsabile di potenziali problemi e più informazioni il proprietario deve preparare adeguatamente per il passaggio, meglio è.

Rendere PHP 8.0 o 8.1 disponibile ai clienti come host web è una cosa, ma così facendo, devono assicurarsi di creare consapevolezza tra i clienti in modo che siano consapevoli che potrebbero emergere problemi. Si consiglia di testare il sito in un ambiente di staging con una versione diversa da quella live. (La selezione delle versioni PHP è disponibile per impostazione predefinita su Kinsta.)

Versione PHP minima per WordPress

Oltre il 15% di tutti i siti Web utilizza attualmente PHP versione 7.0 o inferiore. Questo può essere visto nelle statistiche ufficiali di WordPress. Circa l'83% di tutti i siti WordPress utilizza attualmente PHP versione 7.4 o inferiore. Tieni presente che qualsiasi versione inferiore o uguale alla versione 7.4 non è attualmente più supportata da PHP. L'utilizzo di versioni di PHP al termine del ciclo di vita può causare problemi perché gli aggiornamenti di sicurezza non vengono più rilasciati.

Per evitare problemi, è importante che i proprietari dei siti WordPress siano a conoscenza e informati sulla versione minima di PHP che consentirà al loro sito di funzionare in sicurezza. Da parte loro, i proprietari del sito possono modificare da soli la versione PHP (possibile su Kinsta per tutti i pacchetti) o chiedere al proprio host di aggiornare il sito a una versione PHP più recente. In casi estremi, puoi passare a un host che supporti queste versioni più recenti.

Poiché WordPress richiede solo una versione minima di 7.4, molti host e proprietari di siti Web non sono sufficientemente motivati ​​ad aggiornare i propri siti. E questo nonostante il fatto che PHP 7.4 abbia raggiunto la fine del suo ciclo di vita nel novembre 2022.

Se WordPress aumenta la versione minima di PHP, ciò potrebbe significare che molti siti non saranno più compatibili con un aggiornamento all'ultima versione di WordPress. Tuttavia, gli aggiornamenti di sicurezza continueranno a essere rilasciati per quelle versioni obsolete per un po' di tempo.

Riepilogo

Per passare a PHP 8.0 o versioni successive per il tuo sito Web, ci sono diversi passaggi che tu o il tuo sviluppatore dovete eseguire. I passaggi importanti includono:

• Analisi statica
• Test unitario
• Test d'integrazione
• Test manuale

Quando passi a PHP 8.x, assicurati che tutto sia stato testato correttamente. Questo è l'unico modo per garantire che il tuo sito funzioni correttamente, rapidamente e in modo sicuro su una versione PHP più recente.

Ringraziamo immensamente Juliette per aver partecipato a questo articolo e per tutto il suo lavoro sugli strumenti menzionati!

Foto di Juliette, scattata da Jip Moors e utilizzata su autorizzazione.