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.