Skip to content

Tutto per WordPress, lo sviluppo web — e non solo

Il limite di caricamento file in WordPress: quanto e dove cambiarlo

Indica la dimensione dei file da caricare: lo strumento calcolerà un insieme coerente di valori e mostrerà quale metodo funzionerà sul tuo tipo di server. Tutto viene calcolato nel browser, nulla viene inviato da nessuna parte.

Quanto deve pesare il file più grande che intendi caricare.
La libreria media di WordPress invia i file uno alla volta. I moduli personalizzati con più campi li inviano in un'unica richiesta.
Se non lo sai, guarda phpinfo(), la riga Server API: Apache 2.0 Handler = mod_php, FPM/FastCGI = PHP-FPM, LiteSpeed = LSAPI.
DirettivaPerché proprio questo valoreValore


    
Perché non ha funzionato: checklist I valori sono scritti, ma il limite è rimasto quello di prima: quasi sempre è uno dei nove punti qui sotto.

Limite rigido dell'hosting. Un valore superiore a quello consentito dal piano viene tagliato in silenzio: nel file 512M, in phpinfo()64M. Si risolve solo aprendo un ticket al supporto.

Hai modificato il php.ini sbagliato. Il file attivo è indicato in phpinfo() alla riga Loaded Configuration File; accanto c'è Additional .ini files parsed: anche questi vengono letti e possono ridefinire i tuoi valori.

LimitRequestBody in Apache. È il limite del server web stesso, in byte, nel vhost o in .htaccess. Taglia il corpo della richiesta prima di PHP: l'utente vede 413 e nei log di PHP non c'è nulla.

Il processo PHP non è stato riavviato. php.ini viene letto una sola volta all'avvio. Con PHP-FPM va riavviato FPM stesso: riavviare nginx o Apache non rilegge il pool.

.user.ini non viene recepito subito. PHP lo tiene in cache per user_ini.cache_ttl secondi (300 per impostazione predefinita). Aspetta 5 minuti oppure riavvia FPM.

OPcache. Non mette in cache php.ini, ma mette in cache il tuo wp-config.php con @ini_set. Dopo la modifica: opcache_reset() oppure riavvio del processo.

Un proxy davanti. Cloudflare nel piano gratuito taglia i caricamenti a 100 MB; un bilanciatore, Engintron o nginx davanti ad Apache ha un proprio client_max_body_size.

Un limite imposto da WordPress. Multisite: Rete → Impostazioni → Dimensione massima del file (in KB). In più il filtro upload_size_limit, che alcuni temi e plugin di sicurezza impostano.

Cartella temporanea. Se upload_tmp_dir non è scrivibile o la partizione ha esaurito lo spazio, il file non arriva e non compare un errore chiaro. Controlla sys_get_temp_dir() e lo spazio libero.

Il calcolo viene eseguito nel tuo browser: nessun dato sul server viene inviato da nessuna parte.

Perché cambiare solo upload_max_filesize non basta quasi mai

La dimensione del caricamento è limitata da almeno quattro valori indipendenti, e vale il più piccolo di essi. upload_max_filesize — la dimensione di un singolo file. post_max_size — la dimensione dell'intera richiesta POST. Deve essere maggiore di upload_max_filesize, altrimenti il file viene tagliato ancor prima del controllo del primo limite. memory_limit — deve contenere l'intera richiesta; per WordPress almeno 256M. client_max_body_size — il limite di nginx. È quello che si dimentica più spesso: PHP consente già tutto, ma nginx restituisce 413 Request Entity Too Large. Una trappola a parte è il metodo. Le direttive php_value in .htaccess funzionano SOLO quando PHP è caricato come modulo Apache (mod_php). Sugli hosting moderni PHP gira quasi sempre come FPM, e allora una riga del genere viene ignorata in silenzio oppure produce un 500 Internal Server Error. Proprio per questo lo strumento chiede il tipo di server e mostra quale blocco ti sarà davvero utile.

Domande frequenti