PHP 8 e compatibilità WordPress: cosa rompe, come testare e quando forzare l'upgrade

PHP 8 è un salto reale di prestazioni — i benchmark parlano di un 10-30% di velocità in più sullo stesso hardware, senza toccare una riga di codice. Per un sito WordPress, passare da PHP 7.4 a PHP 8.x significa spesso un TTFB più basso e un admin più reattivo, gratis. Il problema è che "gratis" vale solo se plugin e temi sono compatibili. E non tutti lo sono.

Lo vediamo regolarmente: un cliente chiede l'upgrade a PHP 8, lo attiviamo, e un plugin critico smette di funzionare perché usa una funzione deprecata o un pattern che PHP 8 ha reso più severo. Il risultato va dal warning innocuo al sito bianco. La differenza tra un upgrade tranquillo e un disastro è tutta nel test preliminare — che troppi saltano perché "PHP 8 è solo più veloce, no?"

Cosa cambia davvero in PHP 8 (e cosa rompe)

PHP 8 ha introdotto cambiamenti che non sono retrocompatibili. I più frequenti che vediamo rompere plugin WordPress: la funzione `create_function()` è stata rimossa (era deprecata da PHP 7.2, ma molti plugin vecchi la usano ancora); le stringhe numeriche ora sono più rigorose nella comparazione; i parametri con valori di default null si comportano diversamente; e match() sostituisce switch() con una sintassi più rigida.

Il caso più insidioso è quello silenzioso: un plugin non dà errore fatale, ma smette di comportarsi come prima perché una comparazione tra stringhe ora restituisce un risultato diverso. Il sito non si rompe visibilmente, ma una logica di business (uno sconto applicato, un ruolo utente verificato) smette di funzionare. È il tipo di bug che emerge settimane dopo l'upgrade, quando nessuno collega più il problema al cambio di PHP.

// Esempio di codice che rompe su PHP 8

// ❌ create_function() — rimosso in PHP 8
add_filter( 'the_content', create_function( '$c', 'return $c;' ) );

// ✅ Sostituto corretto con closure
add_filter( 'the_content', function( $c ) {
    return $c;
});

// ❌ Comparazione debole — comportamento diverso in PHP 8
if ( 0 == strpos( $haystack, $needle ) ) { /* ... */ }
// Quando $needle non è trovato, strpos restituisce false.
// In PHP 7: 0 == false era true. In PHP 8: false non è più == 0.

// ✅ Comparazione esplicita
if ( false !== strpos( $haystack, $needle ) ) { /* ... */ }

Testare in staging prima di toccare la produzione

La regola è non testare mai un upgrade di PHP direttamente in produzione. Il workflow corretto: clona il sito in un ambiente di staging con la stessa versione di PHP che vuoi attivare, attiva il debug per vedere warning e notice, e scorri le pagine critiche — home, checkout se è un e-commerce, area account, pagine con form. Se il staging non è disponibile, almeno attiva WP_DEBUG_LOG su produzione per qualche giorno prima dell'upgrade, così vedi i warning che preannunciano i problemi.

// wp-config.php — attiva il logging degli errori prima dell'upgrade
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );   // scrive in wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // non mostrare errori a schermo
@ini_set( 'display_errors', 0 );

// Dopo qualche giorno, leggi wp-content/debug.log e cerca:
// - Deprecated:  (funzioni rimosse o cambiate in PHP 8)
// - Fatal error:  (rotture immediate)
// - Warning:     (comportamenti cambiati)

Quando forzare l'upgrade (e quando aspettare)

Non tutti i plugin incompatibili vanno sostituiti. La decisione dipende da quanto il plugin è critico e da quanto è mantenuto. Se il plugin è fondamentale per il business (un gateway di pagamento, un plugin di membership) e non è aggiornato da due anni, l'upgrade a PHP 8 è il momento di valutare un'alternativa mantenuta — non di tenerlo forzato su PHP 7.4 per sempre, perché PHP 7.4 ha perso il supporto di sicurezza.

Se invece il plugin incompatibile è periferico (un widget decorativo, un plugin di analytics non critico) e il resto del sito è compatibile, si può forzare l'upgrade disabilitando il plugin problematico e cercando un'alternativa, oppure accettando un warning non fatale se il comportamento non è compromesso. Il punto è decidere consapevolmente, non scoprire il problema dopo.

PHP 8 vale l'upgrade per quasi tutti i siti WordPress, a patto di testare. La differenza tra un'agenzia che lo fa bene e una che manda in tilt i siti dei clienti è tutta nel test preliminare in staging — che richiede mezz'ora e risparmia ore di ripristino di emergenza.