Aggiornare un sito, un plugin o un tema WordPress a una nuova versione di PHP è un’operazione che si ripete regolarmente. Ma come farlo nel modo corretto? Come assicurarsi di non trascurare nulla? Esiste un piano d’azione da seguire?
In questo articolo risponderemo a queste domande (e ad altre ancora) e vedremo cosa è necessario per passare a PHP 8.x senza problemi per un sito, un plugin o un tema WordPress.
Tutto ciò si basa su un’intervista che abbiamo condotto con Juliette Reinders Folmer, esperta di PHP. Juliette dedica la maggior parte della sua giornata alla programmazione e a tutto ciò che la riguarda, concentrandosi principalmente su progetti open-source, tra cui WordPress.
E voi siete curiosi di conoscere il nostro piano d’azione? Allora iniziamo subito!
PHP 8.x – Cosa È Cambiato
Per una panoramica dei cambiamenti, consigliamo di consultare gli articoli qui sotto:
- 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 lo stato attuale
- Cosa c’è di nuovo in PHP 8.0 e PHP 8.1
- Le Novità di PHP 8.2 e guida alla migrazione a PHP 8.2
Dopo aver letto questi articoli, saprete cosa è cambiato in PHP 8.x e cosa dovete fare per far funzionare correttamente i vostri progetti PHP.
Se non siete sicuri di quale sia il modo migliore per iniziare, nella conversazione con Juliette ne abbiamo parlato nel dettaglio e in questo articolo vi spiegheremo nel modo più esaustivo possibile come passare a PHP 8.x.
E spiegheremo anche, e in modo dettagliato, come eseguire diverse operazioni in MyKinsta, il nostro pannello di controllo proprietario dove gestire tutti i vostri siti WordPress, le vostre applicazioni e i vostri database.
Passare a PHP 8.x: Come Iniziare
Passare a PHP 8.x sembra semplice, e tecnicamente lo è. Molti host permettono di specificare la versione di PHP che si vuole usare per il sito web nel pannello di amministrazione. Su Kinsta, il cambio di versione di PHP richiede un solo clic nel cruscotto di MyKinsta.
Ma prima di procedere, ci sono alcune cose da verificare:
- Se avete costruito il vostro sito WordPress con temi e plugin standard, senza avere grandi conoscenze di PHP, affidatevi a una persona esperta di sviluppo o a un’agenzia per verificare se il vostro sito è adatto a funzionare con PHP 8.x. State cercando una terza parte che possa aiutarvi? Allora consultate la nostra pagina dei Partner che elenca diverse aziende affidabili a cui chiedere assistenza.
- Se il vostro sito WordPress è stato realizzato da un soggetto esterno, uno sviluppatore o un’agenzia, contattateli per sapere se il vostro sito può funzionare con PHP 8.x.
- Se avete costruito il vostro sito WordPress, per esempio con un tema personalizzato o con plugin sviluppati da voi, vi proponiamo un piano d’azione.
Se il vostro sito rientra in una delle prime due categorie, vi invitiamo a leggere il resto dell’articolo, ma non vi consigliamo di iniziare a testare da soli la compatibilità con PHP 8 del vostro sito. Lasciatelo fare ai professionisti.
Qualunque sia la vostra scelta, vi consigliamo di non passare il vostro sito live a PHP 8 e “vedere se funziona”. Siete curiosi di sapere come sarà il vostro sito e non vedete l’ora di vederlo funzionare con PHP 8? Allora iniziate a fare dei test in un ambiente di staging. Un buon host vi permetterà di creare facilmente un ambiente di staging.
Nell’ambiente di staging potete attivare PHP 8.x e verificare se questo aggiornamento funziona bene con il vostro sito. È anche possibile lavorare con una copia locale del vostro sito. Con il nostro strumento di sviluppo gratuito DevKinsta, potete importare facilmente il vostro sito dalla bacheca di MyKinsta, dopodiché potrete cambiare la versione di PHP in 8.0 o 8.1.
Se non notate alcun problema nell’ambiente di staging, non significa necessariamente che non ci siano problemi. Il piano d’azione qui sotto vi spiega perché.
Test di Compatibilità con PHP 8.x: Piano d’Azione
Test: questa è la parola chiave per un buon software. Anche per i siti web WordPress e i loro componenti, come i temi, i plugin e il core di WordPress, il test è il mezzo per garantire che non accadano cose che non volete che accadano.
Un progetto di sviluppo software consiste in gran parte di test. In questo articolo analizziamo nello specifico i test che possono aiutarvi a rendere il passaggio a PHP 8.x senza intoppi. Nel nostro articolo sugli strumenti DevOps, troverete una sezione con una raccolta di strumenti che potete usare.
In questo blog post vengono trattati i seguenti tipi di test:
Vediamo più da vicino i diversi tipi di test che possiamo eseguire.
Analisi Statica (o Test Statici)
Il primo passo che potete fare come sviluppatore PHP è quello di eseguire un’analisi statica del vostro codice con vari strumenti. L’analisi statica è il processo di analisi del software senza eseguire il codice. Con l’analisi statica potete rilevare gli errori, individuare i problemi di compatibilità con PHP 8.x, applicare gli standard di codifica (per esempio gli standard di codifica di WordPress) e persino modificare e ripulire il codice.
Strumenti per l’Analisi Statica
Potete eseguire un’analisi statica con diversi strumenti, come per esempio:
Al momento in cui scriviamo, non tutti i controlli di PHP 8.1 sono supportati nell’ultima versione di PHPCompatibility. I controlli di PHP 8.1 possono essere presenti nella versione di sviluppo, quindi assicuratevi di usare quelli (per ora) quando usate PHPCompatibility per analizzare il vostro progetto e vedere quali errori/raccomandazioni ci sono.
I controlli di PHP 8.1 saranno presto rilasciati in una nuova versione major. Se volete rimanere sempre aggiornati e avete un account GitHub, aprite il repository GitHub di PHPCompatibility e andate su Watch -> Custom -> Releases, dove potete scegliere di ricevere un avviso quando viene rilasciata una nuova versione.
PHPCompatibility, che testa la compatibilità solo per una particolare versione (o gamma di versioni) di PHP, è facile da configurare. I risultati migliori si ottengono eseguendo un testVersion, per esempio 8.0+ (dalla 8.0 in poi), all’interno di PHPCompatibility.
Dovreste fare attenzione alle funzioni deprecate o eliminate, ai valori predefiniti dei parametri delle funzioni, all’uso di concat senza parentesi, all’uso di match come nome di funzione (dato che è riservato da PHP 8.0), ecc.
Psalm e PHPStan sono delle buone aggiunte e possono aiutarvi a eseguire ulteriori controlli relativi ai tipi di variabili. L’aspetto negativo di questi strumenti è che richiedono molte configurazioni per ottenere i rapporti su PHP 8.0 e 8.1. Anche se hanno successo, è possibile che i risultati siano inferiori a quelli attesi. Anche se hanno successo, potete aspettarvi molti falsi positivi. I falsi positivi sono notifiche errate, causate dai limiti dell’analisi statica.
È necessaria una buona conoscenza per interpretare correttamente i risultati di questi due strumenti, ma questa conoscenza può aiutarvi a identificare ulteriori incompatibilità che PHPCompatibility non può trovare. Consultate la documentazione di Psalm e PHPStan se volete saperne di più.
Riepilogo:
- Eseguire l’analisi statica con PHPCompatibility, Psalm e PHPStan
- Risolvere tutti i problemi legittimi
Unit Testing
La fase successiva del processo è lo unit testing. Questo è un metodo per testare pezzi di codice singolarmente. Negli unit testing si sviluppano test specifici e mirati per ogni unità. Questo comporta l’esecuzione di diversi scenari. Preferibilmente, ogni scenario viene testato separatamente dagli altri in modo che i test siano indipendenti l’uno dall’altro.
Gli unit testing da soli, ovviamente, non bastano. Devono anche essere eseguiti. Il modo migliore per automatizzare gli unit testing è usare strumenti di CI (continuous integration) come Jenkins, GitHub Actions o Travis.
Supportare Più Versioni di PHP
Se vi occupate di costruire plugin e volete supportare più versioni di PHP, assicuratevi che i test in CI vengano eseguiti su tutte le versioni di PHP supportate.
Naturalmente, potete anche supportare solo le versioni più recenti: la scelta spetta solo a voi.
I test con più versioni di PHP richiedono l’utilizzo di più versioni di PHPUnit, a seconda della versione di PHP. Poiché PHPUnit ha introdotto diversi cambiamenti nel corso degli anni che influenzano il modo in cui vengono scritti i test, questa parte può essere complicata.
Per ovviare a questo problema, potete usare i PHPUnit Polyfills (scritti da Juliette e sponsorizzati da Yoast). Questo vi permette di scrivere test che non sono ufficialmente supportati da PHPUnit 9 (e quindi possono essere eseguiti su PHP 8.x). I Polyfill fanno sì che i vostri test funzionino con PHPUnit 4.x fino a 9.x e con PHP 5.4 fino a PHP 8.1 (per ora).
Ora che i test sono in esecuzione, il passo successivo è assicurarsi che i problemi riscontrati nei test siano risolti.
Copertura del Codice
L’esecuzione di questi test è il modo più affidabile per trovare le incompatibilità tra le versioni.
Nel farlo, prestate attenzione alla copertura del codice dei vostri 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 della funzione.
- Il test per la funzione A è stato scritto per testare la logica della funzione A, ma durante il test chiamerà anche le funzioni B, C e D. Per quanto riguarda le funzioni B, C e D, di solito si testa solo il “percorso senza errori” – la situazione in cui tutto va bene – e quindi anche queste funzioni non sono ancora completamente testate, anche se (parte del) codice di queste funzioni viene eseguito durante il test della funzione A.
- Per ognuno dei test, indicare qual è il codice che viene testato nello specifico assegnando ad ogni test un @covers. In questo modo, B, C e D non sono “contati” nel calcolo della copertura del codice, cosa che consente di vedere quale parte del codice è coperta dai test.
Spesso gli sviluppatori scrivono e testano – a volte anche inconsapevolmente – solo per il “percorso senza errori”. In questi casi, è necessario verificare cosa succede quando vengono passati dati inaspettati a una funzione. I test con i soli valori/tipi attesi non sono sufficienti.
La seconda parte della citazione precedente viene spesso dimenticata, mentre è forse ancora più importante della prima. Cosa succede se si passa un tipo non corretto? Viene visualizzato un messaggio di errore? Oppure la variabile viene lanciata e la funzione continua normalmente? E se viene passato un valore inaspettato alla funzione?
Assicuratevi di testare le vostre funzioni con variabili, tipi e valori inaspettati. Solo così potrete fare affidamento sui vostri test per individuare i problemi che una nuova versione di PHP potrebbe causare.
Il PHP Sta Diventando Più Rigoroso
PHP sta diventando più preciso (e rigoroso) nel modo in cui gestisce i “tipi” per le funzioni di PHP stesso, ma anche le proprietà dinamiche. Questi cambiamenti hanno lo scopo di aiutare gli sviluppatori a creare codice privo di errori (o meglio, 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 della ricerca di messaggi di errore più utili in PHP, è possibile notare che rendere il codice esistente adatto alle nuove versioni di PHP richiede sempre più tempo. Nella maggior parte dei casi, rendere il codice che funzionava con PHP 5.6 adatto a PHP 7.0 richiedeva solo una frazione del tempo rispetto all’aggiornamento del codice per renderlo adatto a PHP 8.1. E questo nonostante il fatto che PHP 7.0 sia una versione “major”, mentre PHP 8.1 è una “minor”.
In molti casi, i test sono ancora l’unico modo affidabile per determinare cosa deve essere modificato per supportare una nuova versione.
Gli unit testing sono possibili con diversi strumenti, tra cui:
Molti di questi strumenti si basano su PHPUnit o si combinano con esso.
In definitiva, non importa quali strumenti usate. La cosa più importante è fare dei test e farli funzionare sulle nuove versioni di PHP. Questo passaggio può essere a volte molto complicato, ma per fortuna, come già detto, esistono degli strumenti appositi, come i PHPUnit Polyfills.
Test di Integrazione
I test di integrazione sono la fase successiva all’analisi statica e agli unit testing. Un test di integrazione consiste nel testare situazioni reali in un contesto più ampio rispetto alla semplice “unità di codice”. Tra questi ci sono i test con un database attivo (di prova) o i 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 (scritto sempre da Juliette e sponsorizzato da Yoast) è uno strumento eccellente per i test di integrazione. WP Test Utils fornisce strumenti per scrivere unit test e test di integrazione, in cui WordPress viene “simulato” utilizzando Brainmonkey e Mockery, dove le funzioni di WordPress comunemente utilizzate vengono “falsificate” in modo da testare il vostro codice e non quello di WordPress.
I test di integrazione con WordPress sono più complicati perché implicano 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, dovete considerare quali versioni di PHPUnit sono supportate da WordPress stesso per eseguire i test su diverse versioni di PHP.
Per esempio, WordPress dalla 5.6 alla 5.8 usa PHPUnit dalla 5 alla 7 per testare PHP dalla 5.6 alla 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.
Volete saperne di più su come eseguire test di integrazione su più versioni di WordPress, tra cui WordPress 5.9 e successive? Allora leggete l’articolo sul sito web di WordPress.
Test Manuali
Ora che avete eseguito gli unit testing e i test di integrazione e avete risolto tutti i problemi riscontrati, è il momento di eseguire i test manuali. Il vostro sito funziona e il vostro codice funziona, ma state utilizzando anche i plugin A, B e C. Sapete se questi plugin sono compatibili?
Per esempio, verificate con gli autori del plugin e cercate un’indicazione sulla compatibilità con PHP 8.x. La domanda da porsi, ovviamente, è come è stato testato il plugin. Spesso la risposta è: in isolamento. Di solito le funzioni del plugin sono state testate solo con WordPress, senza altri plugin attivi. E anche se in questi test sono stati utilizzati altri plugin, è probabile che non tutti i plugin da voi utilizzati abbiano preso parte ai test, quindi prendete con le molle questa dichiarazione di compatibilità.
Per esempio, prendiamo un sito WordPress con 3 plugin (A, B e C). È possibile che il plugin B, per esempio, restituisca un tipo di variabile errato tramite un filtro, che il plugin C, utilizzando lo stesso filtro, vuole utilizzare. Questo può causare un errore fatale perché il tipo non è più quello previsto. Il plugin C viene quindi visto come il colpevole del messaggio di errore, anche se il plugin B è il vero colpevole.
L’interoperabilità e l’incompatibilità dei plugin sono impossibili da scoprire quando si eseguono test isolati. Più sono i plugin attivi, più è probabile che qualcosa vada storto. Per esempio, sarebbe molto utile passare le richieste di pagina da un sito web live a un ambiente di staging (con la registrazione degli errori attivata) per scoprire cosa effettivamente non va.
Con questo tipo di problema, il proprietario del sito di solito vedrà solo un messaggio che segnala un errore nell’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, è necessario un lavoro manuale e umano e una buona dose di olio di gomito per individuare e risolvere questi problemi. Tutto ciò potrebbe essere automatizzato utilizzando i test end-to-end, ma non ci risulta che questo avvenga spesso in WordPress.
Disponibilità di Test per i Plugin Utilizzati
Per gli sviluppatori e i team di sviluppo: accettate il codice solo se i test sono disponibili. In questo modo, vi assicurate che siano necessari meno test manuali, con un notevole risparmio di tempo.
Mettete in discussione la sua strategia di test se volete acquistare un plugin o un tema commerciale. In questo modo, creiamo una consapevolezza collettiva tra gli sviluppatori e i team di sviluppo della comunità di WordPress per far sì che i test vengano messi in cima all’agenda e ne beneficiamo tutti.
I test sono spesso visti – ingiustamente – come un costo quando, in realtà, fanno risparmiare denaro. L’investimento extra richiesto per scrivere i test si ripaga sotto forma di un numero significativamente inferiore di segnalazioni di bug e di tempo speso per correggerli. Inoltre, con i test automatizzati del software, le estensioni e le modifiche possono essere effettuate più velocemente perché i test possono confermare rapidamente che le funzionalità esistenti continuano a funzionare.
Il Ruolo degli Host WordPress e di PHP 8.x
Per chi possiede un sito medio, una guida da parte del vostro host è auspicabile. Considerate quanto segue:
- Documentazione e aggiornamenti per i clienti che sanno che WordPress Core, i plugin e/o i temi non sono (in alcuni casi) compatibili con le versioni incrociate di PHP.
- Opzioni per effettuare test (come per esempio lavorare con un ambiente di staging).
- Metodi per segnalare gli errori e contattare l’assistenza.
Questo va a vantaggio anche dell’host web, in quanto i proprietari dei siti spesso contattano l’host per chiedere aiuto quando si verificano dei problemi. Nel caso di un passaggio a PHP 8.0, 8.1 o 8.2, il proprietario del sito è responsabile dei potenziali problemi e più informazioni ha per prepararsi adeguatamente al passaggio, meglio è.
Mettere a disposizione dei clienti PHP 8.1 o 8.2 come host web è una cosa, ma nel farlo deve assicurarsi di sensibilizzare i clienti in modo che siano consapevoli che potrebbero emergere dei problemi. È consigliabile testare il sito in un ambiente di staging con una versione diversa da quella live. (La selezione delle versioni di PHP è disponibile per impostazione predefinita su Kinsta).
Versione PHP Minima per WordPress
Oltre il 15% di tutti i siti web usa attualmente la versione PHP 7.0 o inferiore. Questo dato è riportato nelle statistiche ufficiali di WordPress. Circa l’83% di tutti i siti WordPress utilizza attualmente la versione PHP 7.4 o inferiore. Ricordate che qualsiasi versione inferiore o uguale alla 8.0 non è più supportata da PHP. L’utilizzo di versioni di PHP a fine vita può causare problemi perché gli aggiornamenti di sicurezza non vengono più rilasciati.
Per evitare problemi, è importante che i proprietari di siti WordPress conoscano e si informino sulla versione minima di PHP che consente al loro sito di funzionare in modo sicuro. Da parte loro, i proprietari dei siti possono modificare autonomamente la versione di PHP (possibile presso Kinsta per tutti i pacchetti) o chiedere al proprio host di aggiornare il sito a una versione PHP più recente. In casi estremi, è possibile 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 loro siti. E questo nonostante il fatto che PHP 7.4 abbia raggiunto il suo termine di vita nel novembre 2022.
Se WordPress dovesse aumentare la versione minima di PHP, ciò potrebbe significare che molti siti non saranno più compatibili con l’aggiornamento all’ultima versione di WordPress. Tuttavia, gli aggiornamenti di sicurezza continueranno a essere rilasciati per queste versioni obsolete per un bel po’ di tempo.
Riepilogo
Per passare a PHP 8.0 o versione superiore con il vostro sito web, ci sono diversi passaggi che voi o il vostro team di sviluppo dovete eseguire. I passi più importanti sono:
- Analisi statica
- Unit testing
- Test di integrazione
- Test manuali
Quando passate a PHP 8.x, assicuratevi che tutto sia stato testato correttamente. Questo è l’unico modo per garantire che il vostro sito funzioni correttamente, velocemente e in modo sicuro su una versione PHP più recente.
Ringraziamo immensamente Juliette per aver partecipato a questo articolo e per il suo lavoro sugli strumenti citati!
Foto di Juliette, scattata da Jip Moors e utilizzata con il suo permesso.
Lascia un commento