PHP 8.4 e WordPress: cosa cambia, cosa rompe e come preparare il sito senza incidenti

Ogni major release di PHP è un momento di attenzione per chi gestisce WordPress. PHP 8.4 non fa eccezione: porta migliorimenti di performance reali, nuove funzioni del linguaggio che semplificano il codice, e un set di deprecazioni che possono rompere plugin e temi non aggiornati. La domanda operativa è sempre la stessa: quando conviene salire di versione e come farlo senza rompere il sito in produzione.

La risposta breve è: non si aggiorna PHP in produzione senza prima testare in staging. Mai. La risposta lunga è che il test non è complicato, ma richiede metodo — e richiede di conoscere quali sono i cambiamenti che effettivamente rompono il codice WordPress, perché non tutte le deprecazioni di PHP 8.4 sono ugualmente pericolose.

I cambiamenti breaking che toccano WordPress

PHP 8.4 depreca alcune pratiche comuni nel codice WordPress legacy. La più impattante è la deprecazione dell'uso di valori costanti come parametri nullable impliciti — un pattern che molti plugin più vecchi usano senza saperlo. Un'altra è il cambiamento nel comportamento di alcune funzioni di array quando ricevono tipi inattesi: dove prima PHP restituiva null o false, ora può lanciare warning o comportarsi diversamente.

La buona notizia è che WordPress core, nelle versioni recenti, è testato contro PHP 8.4 e compatibile. Il rischio è quasi sempre nei plugin: un plugin non aggiornato da due anni ha buone probabilità di usare un pattern deprecato. Il problema non è che il plugin smette di funzionare immediatamente — i warning di deprecazione non bloccano l'esecuzione — ma su hosting con error reporting stretto, i warning possono riempire i log, saturare il disco, o in casi estremi rompere output JSON.

# Test di compatibilità PHP 8.4 su un sito WordPress in staging

# 1. Clona il sito in staging (copia file + database)
# 2. Cambia la versione PHP del staging a 8.4 (dal pannello hosting)

# 3. Esegui un check di compatibilità con WP-CLI
wp plugin list --fields=name,version,status --format=csv \
  | tail -n +2 | while IFS=, read name version status; do
    echo "=== $name $version ==="
    # Verifica la versione minima PHP dichiarata dal plugin
    grep -i 'Requires PHP' wp-content/plugins/$name/$name.php 2>/dev/null
  done

# 4. Abilita il log degli errori PHP in staging
# Aggiungi a wp-config.php:
# define( 'WP_DEBUG', true );
# define( 'WP_DEBUG_LOG', true );
# define( 'WP_DEBUG_DISPLAY', false );

# 5. Naviga le pagine critiche e controlla il log
tail -f wp-content/debug.log | grep -i 'deprecated'

# 6. Conta i warning di deprecazione dopo un test completo
grep -c 'Deprecated' wp-content/debug.log
# Se il numero è alto (>100), c'è un plugin da aggiornare
# o da sostituire prima di passare a PHP 8.4 in produzione.

Quando forzare l'upgrade (e quando aspettare)

Forzare l'upgrade a PHP 8.4 ha senso quando il sito trae beneficio misurabile dalle performance: siti ad alto traffico, WooCommerce con molti ordini, siti editoriali con query complesse. PHP 8.4 porta migliorimenti nel JIT compiler e nella gestione della memoria che, su carichi reali, si traducono in TTFB più basso e minor consumo di risorse.

Aspettare ha senso quando il sito è stabile, ha traffico moderato, e uno o più plugin critici non sono ancora dichiarati compatibili con PHP 8.4. In questo caso, restare su PHP 8.3 o 8.2 è la scelta prudente — le versioni precedenti ricevono ancora aggiornamenti di sicurezza. La regola è: la versione di PHP deve essere la più recente che è compatibile con tutti i plugin critici del sito, non la più recente in assoluto.

Un check-up dell'infrastruttura include sempre la verifica della versione di PHP, dello stato di compatibilità dei plugin, e della raccomandazione sul momento giusto per l'upgrade. Aggiornare PHP non è un'operazione da fare a memoria: è un'operazione da testare, misurare e pianificare.