Aumentare la dimensione massima di caricamento file in WordPress

Tre impostazioni controllano il limite di upload di WordPress, e devono andare tutte d’accordo. Il limite effettivo è il più piccolo tra upload_max_filesize, post_max_size e il tetto sulle richieste del tuo web server. Ne alzi uno, lasci gli altri due bassi, e non cambia niente — ed è esattamente per questo che la maggior parte delle persone conclude che la propria correzione “non ha funzionato”. Controlla prima i tuoi valori attuali con lo strumento per la dimensione massima di upload di WordPress; legge gli stessi valori che WordPress riporta e ti mostra quale sta facendo da collo di bottiglia.

Perché esiste il limite e dove si trova

WordPress non imposta il limite di upload. Si limita a riportarlo. Quando vedi “The uploaded file exceeds the upload_max_filesize directive in php.ini”, quel messaggio arriva direttamente da PHP.

Tre valori distinti regolano un upload, e il tetto reale è quello più basso:

• upload_max_filesize (PHP) — il file singolo più grande che PHP accetterà.
• post_max_size (PHP) — il corpo POST totale più grande. Il tuo file viaggia dentro la richiesta POST insieme agli altri campi del form, quindi questo valore deve essere più grande di upload_max_filesize.
• Il limite sul corpo della richiesta del web server — client_max_body_size su Nginx, oppure LimitRequestBody su Apache. Questo vive completamente al di fuori di PHP, ed è il motivo per cui le correzioni limitate a PHP falliscono silenziosamente dietro Nginx.

Un quarto valore, max_execution_time, non limita la dimensione ma interromperà a metà trasferimento un upload lento e pesante su una connessione scadente. È un sintomo a parte, non fa parte del tetto sulla dimensione.

La trappola: imposti upload_max_filesize = 256M, ricarichi, e ancora non riesci a caricare un file da 100 MB — perché post_max_size è ancora 8M. PHP rifiuta la richiesta sul corpo totale prima ancora di ispezionare il file. Il limite non ti ha ignorato. Un limite diverso l’ha bloccato prima.

Come risolvere, nell’ordine giusto

Procedi da ciò che ha più probabilità di funzionare fino all’ultima spiaggia.

1. Modifica php.ini (il posto giusto). Trova il file che il tuo sito carica davvero — esegui una pagina con <?php phpinfo(); e leggi “Loaded Configuration File”, oppure chiedi al tuo host. Imposta entrambi i valori PHP, e tieni post_max_size più grande di upload_max_filesize:

upload_max_filesize = 256M
post_max_size = 260M
max_execution_time = 300

Riavvia PHP-FPM (sudo systemctl restart php8.2-fpm) o Apache. Le modifiche non hanno alcun effetto finché il processo PHP non viene riavviato.

2. Nessun accesso a php.ini? Usa .htaccess (solo Apache + mod_php). Aggiungi al .htaccess nella root di WordPress:

php_value upload_max_filesize 256M
php_value post_max_size 260M
php_value max_execution_time 300

Questo funziona solo quando PHP gira come modulo Apache. Sotto PHP-FPM, CGI o FastCGI, php_value genera un errore 500 — quel fallimento significa che sei sulla strada sbagliata, non che il numero è sbagliato. Passa a .user.ini:

upload_max_filesize = 256M
post_max_size = 260M

3. Alza il limite del web server — il passaggio che tutti dimenticano. Su Nginx, PHP non vede nemmeno una richiesta troppo grande; Nginx restituisce 413 Request Entity Too Large prima. Nel tuo server block:

client_max_body_size 256M;

Ricarica con sudo nginx -t && sudo systemctl reload nginx. Se sei su Nginx e le tue modifiche a PHP “non hanno fatto niente”, quasi sempre il motivo è questo.

Dopo ogni modifica, ricontrolla i valori riportati. Lo strumento per la dimensione massima di upload ti dirà il nuovo tetto effettivo e genererà lo snippet esatto per la tua configurazione, così non tiri a indovinare quale dei tre è ancora troppo basso.

Cosa non fare

Non modificare wp-config.php aspettandoti che alzi il limite. La riga copiata ovunque non fa ciò che i blog sostengono:

@ini_set( 'upload_max_filesize' , '256M' );

upload_max_filesize è PHP_INI_PERDIR. Non può essere modificato da PHP a runtime con ini_set(). Accetta nuovi valori solo da php.ini, .htaccess o .user.ini — mai dal codice dell’applicazione. La riga viene eseguita senza errori e non fa nulla, il che la rende uno dei consigli sbagliati ripetuti con più sicurezza in tutto il mondo WordPress.

Non incollare nemmeno @ini_set('post_max_size', ...) — stessa restrizione, stesso silenzioso non-effetto.

Non impostare WP_MEMORY_LIMIT pensando che sia il limite di upload. Quello controlla il tetto di memoria di PHP per l’esecuzione del codice. Non ha nulla a che vedere con quanto grande può essere un file accettato dal server.

Non fermarti a un solo file. Il fallimento più comune in assoluto è cambiare solo upload_max_filesize e dichiarare la correzione difettosa. Cambia tutti e tre, e tieni post_max_size sopra upload_max_filesize.

Non impostare limiti assurdamente alti “per sicurezza”. Un limite da 2 GB invita problemi di esaurimento delle risorse e non aiuta — se ti servono davvero file da diversi gigabyte, caricali al di fuori del browser (SFTP, o un plugin di upload a blocchi) invece di forzarli attraverso una singola POST PHP.

Ancora bloccato?

Se tutti e tre i valori sono stati alzati e continui a sbattere contro un muro, la richiesta viene limitata da qualche parte a monte del tuo server: un CDN o un proxy (la dashboard di Cloudflare limita autonomamente la dimensione del corpo di upload), il limite di piattaforma di un host gestito che ignora il tuo php.ini, oppure un .user.ini che non si è ancora aggiornato — rispetta il user_ini.cache_ttl di PHP, quindi può restare indietro di qualche minuto dopo che salvi. Verifica ciò che il server riporta davvero, non ciò che hai scritto in un file, e correggi il livello che è ancora troppo basso. Quando il numero riportato finalmente coincide con il tuo obiettivo, l’upload funziona.