Come risolvere l'errore "Allowed Memory Size Exhausted" in WordPress

Se il tuo sito mostra Fatal error: Allowed memory size of 268435456 bytes exhausted, aggiungi questa riga a wp-config.php sopra il commento /* That's all, stop editing! */: define( 'WP_MEMORY_LIMIT', '256M' );. Nella maggior parte dei casi questo rimette online il sito in meno di un minuto. Ma prima di andartene leggi il resto di questa pagina, perché alzare il limite è una diagnosi, non una cura. Se il crash ricompare a un valore più alto, il vero problema è del codice che consuma memoria senza limiti, e un tetto più alto gli dà solo più corda.

Cosa significa davvero l’errore

PHP tiene traccia di quanta memoria ha allocato ogni richiesta. Quando una singola richiesta prova ad allocare oltre il memory_limit impostato in php.ini (o sovrascritto da WordPress), PHP interrompe la richiesta immediatamente con un errore critico e stampa il numero di byte a cui si è fermato. 268435456 bytes sono 256M. 134217728 sono 128M. 536870912 sono 512M. Il numero dopo “tried to allocate” ti dice la dimensione della goccia che ha fatto traboccare il vaso, non la dimensione del problema.

WordPress aggiunge i propri limiti sopra quelli di PHP. WP_MEMORY_LIMIT (predefinito 40M, o il limite di PHP se più alto) governa il front end. WP_MAX_MEMORY_LIMIT (predefinito 256M) governa le operazioni lato amministrazione come la libreria multimediale e gli aggiornamenti dei plugin, che legittimamente hanno bisogno di più memoria. WordPress chiama ini_set('memory_limit', ...) al caricamento in base a queste costanti, ma solo se il tuo host consente ini_set e solo fino al limite massimo imposto dal tuo host. Proprio quest’ultimo punto è il motivo per cui a volte modificare wp-config.php sembra non avere alcun effetto.

Come risolvere, in ordine

1. Alza il limite di WordPress in wp-config.php. È la prima cosa da provare perché è reversibile e non tocca nient’altro.

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Se non sai bene dove vanno queste righe o vuoi impostare correttamente allo stesso tempo le altre costanti più comuni, il nostro generatore di wp-config scrive un blocco pulito che puoi incollare. La posizione conta: tutto ciò che sta sotto la riga “stop editing” viene ignorato.

2. Se questo non cambia nulla, è il tuo host che limita PHP. Alza memory_limit a livello di PHP. In php.ini:

memory_limit = 256M

Su molti hosting condivisi non puoi modificare direttamente php.ini. Prova invece un file .user.ini nella root del sito, oppure impostalo tramite .htaccess su una configurazione Apache/mod_php:

php_value memory_limit 256M

Attenzione: php_value in .htaccess genera un errore 500 su nginx o su configurazioni PHP-FPM, perché è una direttiva Apache/mod_php. Se dopo averla aggiunta ottieni un errore 500, ecco il motivo: rimuovila e usa .user.ini.

3. Verifica il valore realmente attivo. Non fidarti di ciò che hai modificato; fidati di ciò che PHP riporta. Metti un file di una sola riga nella root del sito:

<?php echo ini_get('memory_limit');

Caricalo in un browser, leggi il valore, poi elimina il file. Se dice ancora 128M dopo che hai impostato 256M, il tuo host sta sovrascrivendo la tua impostazione e devi contattarlo o usare l’impostazione del loro pannello di controllo.

La parte che la maggior parte delle guide salta

Alzare il limite è diagnosi. Ecco come interpretare il risultato.

Se imposti 256M e il sito rimane online con il traffico normale, avevi un tetto legittimo ma troppo basso, cosa comune sui siti con librerie multimediali grandi, WooCommerce o page builder. Hai finito.

Se imposti 256M e va di nuovo in crash, poi 512M e va ancora in crash, smetti di alzarlo. Una normale richiesta WordPress non ha bisogno di 512M. Quando l’uso della memoria sale senza un tetto, qualcosa sta andando in loop o si sta accumulando: un plugin che carica un’intera tabella del database in un array, un add_action che si attiva ricorsivamente da solo, una routine di importazione che tiene ogni riga in memoria contemporaneamente, o due plugin che si scontrano dentro lo stesso hook. Alzare il limite non risolve un loop senza limiti: sposta solo il crash di qualche secondo e lo rende più difficile da riprodurre.

Per trovare il colpevole, disattiva tutti i plugin e passa a un tema predefinito come Twenty Twenty-Four. Se l’errore sparisce, riattiva i plugin uno alla volta finché non ricompare. Attiva il log di debug per capire dove muore:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

La riga dell’errore critico in wp-content/debug.log indica il file e il numero di riga che ha allocato l’ultimo blocco. Di solito è lì il loop, o a una chiamata di funzione di distanza.

Cosa non fare

Non impostare WP_MEMORY_LIMIT a -1 o 1024M e dimenticartene. La memoria illimitata non risolve una perdita; permette a una richiesta impazzita di divorare l’intero server, cosa che può mandare giù tutti gli altri siti sulla stessa macchina e farti arrivare una chiamata dal tuo host. Un tetto è una misura di sicurezza. Tienine uno.

Non incollare ini_set('memory_limit', '512M') in functions.php come soluzione principale. Viene eseguito troppo tardi per alcuni errori: se il crash avviene durante il caricamento del core di WordPress, prima che il functions.php del tuo tema venga eseguito, quella riga non viene mai eseguita. wp-config.php viene caricato prima ed è il posto giusto.

Non dare per scontato che sia un problema di hosting e passare a un piano superiore. A volte l’hosting è davvero sottodimensionato. Spesso però lo stesso identico crash ti segue anche sul piano più grande, perché la causa è arrivata insieme ai tuoi plugin. Escludi prima il loop; è gratis.

Non alzare memory_limit per risolvere un errore di max_execution_time. Sono limiti diversi con messaggi diversi. L’esaurimento di memoria dice “Allowed memory size … exhausted.” Un timeout dice “Maximum execution time … exceeded.” Alzare quello sbagliato ti fa perdere un pomeriggio.

Ancora bloccato?

Se hai confermato che il limite attivo è davvero 256M o più, hai fatto delle prove con tutti i plugin disattivati e un tema predefinito, e continua a esaurire la memoria, allora hai una vera perdita da inseguire nel log di debug, non un tetto da alzare. Cattura la riga dell’errore critico, annota in quale directory di quale plugin punta, e questo è il tuo bug report. Per prima cosa metti a posto le costanti di base del tuo wp-config.php con il generatore di wp-config, così sai che i limiti sono impostati dove pensi che siano, poi vai a leggere il log.