Skip to content

Tudo para WordPress, desenvolvimento web — e não só

O limite de carregamento de ficheiros no WordPress: quanto e onde alterar

Indique o tamanho dos ficheiros que precisa de carregar — a ferramenta calcula um conjunto coerente de valores e mostra que método funciona no seu tipo de servidor. Tudo é calculado no navegador, nada é enviado para lado nenhum.

Qual deve ser o tamanho do maior ficheiro que pretende carregar.
A biblioteca de multimédia do WordPress envia os ficheiros um a um. Os formulários personalizados com vários campos enviam-nos num único pedido.
Se não souber, veja o phpinfo(), a linha Server API: Apache 2.0 Handler = mod_php, FPM/FastCGI = PHP-FPM, LiteSpeed = LSAPI.
DiretivaPorquê exatamente este valorValor
 


    

      
    

  


  

  

  

  

  

    Porque é que não funcionou: lista de verificação
    Os valores estão escritos, mas o limite ficou igual — quase sempre é um dos nove pontos abaixo.
    

      
Limite rígido do alojamento. Um valor acima do permitido pelo plano é cortado silenciosamente: no ficheiro 512M, no phpinfo() — 64M. Só se resolve contactando o suporte.

      
Editou o php.ini errado. O ficheiro ativo é indicado no phpinfo() na linha Loaded Configuration File; ao lado está Additional .ini files parsed — esses também são lidos e podem redefinir os seus valores.

      
LimitRequestBody no Apache. É o limite do próprio servidor web, em bytes, no vhost ou no .htaccess. Corta o corpo do pedido antes do PHP — o utilizador vê 413 e os registos do PHP ficam vazios.

      
O processo PHP não foi reiniciado. O php.ini é lido uma vez no arranque. Com PHP-FPM é preciso reiniciar o próprio FPM — reiniciar o nginx ou o Apache não relê a pool.

      
.user.ini não é aplicado de imediato. O PHP guarda-o em cache durante user_ini.cache_ttl segundos (300 por omissão). Aguarde 5 minutos ou reinicie o FPM.

      
OPcache. Não guarda em cache o próprio php.ini, mas guarda o seu wp-config.php com @ini_set. Após a alteração: opcache_reset() ou reinício do processo.

      
Um proxy à frente. O Cloudflare, no plano gratuito, corta os envios aos 100 MB; um balanceador, o Engintron ou o nginx à frente do Apache têm o seu próprio client_max_body_size.

      
Um limite imposto pelo WordPress. Multisite: Rede → Definições → Tamanho máximo do ficheiro (em KB). Mais o filtro upload_size_limit, que alguns temas e plugins de segurança definem.

      
Pasta temporária. Se upload_tmp_dir não permitir escrita ou a partição ficar sem espaço, o ficheiro não chega e não surge um erro claro. Verifique sys_get_temp_dir() e o espaço livre.

    

  


  
O cálculo é feito no seu navegador — nenhum dado sobre o servidor é enviado para lado nenhum.


Porque alterar apenas o upload_max_filesize quase nunca chega
O tamanho do carregamento é limitado por, pelo menos, quatro valores independentes, e vale o menor deles.

upload_max_filesize — o tamanho de um único ficheiro.
post_max_size — o tamanho de todo o pedido POST. Tem de ser maior do que upload_max_filesize, caso contrário o ficheiro é cortado ainda antes de o primeiro limite ser verificado.
memory_limit — tem de comportar o pedido inteiro; para o WordPress, 256M no mínimo.
client_max_body_size — o limite do nginx. É o mais esquecido: o PHP já permite tudo, mas o nginx devolve 413 Request Entity Too Large.

O método é uma armadilha à parte. As diretivas php_value no .htaccess funcionam SÓ quando o PHP está ligado como módulo do Apache (mod_php). Nos alojamentos modernos o PHP corre quase sempre como FPM e, nesse caso, essa linha ou é ignorada em silêncio ou dá um 500 Internal Server Error. É precisamente por isso que a ferramenta pergunta o tipo de servidor e mostra qual o bloco que o vai ajudar de facto.
Perguntas frequentes