Una vecchia versione di PHP è più lenta e, appena esce dal supporto di sicurezza, smette di ricevere correzioni per problemi ormai pubblici. Aggiornare di solito è indolore; il rischio viene dal passare senza controllare, e il controllo richiede dieci minuti.

Prima scopra che cosa si romperà

composer require --dev php-parallel-lint/php-parallel-lint
vendor/bin/parallel-lint --exclude vendor .

Questo analizza ogni file contro la versione in esecuzione e nomina tutto ciò che non compilerà. Non coglie i cambiamenti di comportamento, ma coglie quelli di sintassi, che sono la maggior parte.

Provi su una copia

  1. Copi il sito su un sottodominio di staging
  2. Passi QUELLO alla nuova versione — In EGPNL, sito per sito.
  3. Accenda gli errori solo sullo staging — display_errors lì, e mai in produzione.
  4. Percorra le strade che contano — Acceda, invii un modulo, arrivi alla cassa, esegua a mano lo script del cron.

Che cosa si rompe di solito

  • Un plugin o una libreria abbandonati che usano qualcosa rimosso anni fa.
  • Passare null dove ci si aspetta una stringa - una deprecazione dalla 8.1 che diventa rumore nel log invece che un errore, ma tanto rumore.
  • Un'estensione non installata per la nuova versione - ogni versione ha il suo insieme, ed è la sorpresa più comune.
php -m   # under the new version, compare against the old

Tornare indietro

Rimettere la versione dal pannello è istantaneo e non cambia nient'altro, quindi il caso peggiore sono pochi minuti. È questo a rendere il tentativo poco costoso.

Dopo il passaggio guardi il log, non soltanto le pagine. Una deprecazione scrive a ogni richiesta e può riempire un disco in un giorno anche se non sembra rotto nulla.
Avanzi di una versione per volta. Dalla 7.4 alla 8.3 in un solo salto le consegna tutti i cambiamenti insieme, senza modo di capire quale abbia rotto che cosa.