Pular para o conteúdo
Configuração

Aumentar o limite de upload de arquivos no WordPress

Três configurações controlam o limite de upload do seu WordPress, e todas precisam estar de acordo. O limite efetivo é o menor entre upload_max_filesize, post_max_size,

Publicado

Três configurações controlam o limite de upload do seu WordPress, e todas precisam estar de acordo. O limite efetivo é o menor entre upload_max_filesize, post_max_size e o limite de requisição do seu servidor web. Aumente um, deixe os outros dois baixos, e nada muda — que é exatamente o motivo de a maioria das pessoas concluir que a correção “não funcionou”. Verifique primeiro os seus números atuais com a ferramenta de limite de upload do WordPress; ela lê os mesmos valores que o WordPress reporta e mostra qual deles está te travando.

Por que o limite existe e onde ele fica

O WordPress não define o limite de upload. Ele apenas o reporta. Quando você vê “The uploaded file exceeds the upload_max_filesize directive in php.ini”, essa mensagem vem direto do PHP.

Três valores separados controlam um upload, e o teto real é o mais baixo entre eles:

  • upload_max_filesize (PHP) — o maior arquivo individual que o PHP vai aceitar.
  • post_max_size (PHP) — o maior corpo total de POST. Seu arquivo trafega dentro da requisição POST junto com outros campos do formulário, então este valor precisa ser maior que upload_max_filesize.
  • O limite de corpo do servidor webclient_max_body_size no Nginx, ou LimitRequestBody no Apache. Este fica totalmente fora do PHP, e é por isso que correções só no PHP falham silenciosamente por trás do Nginx.

Um quarto valor, max_execution_time, não limita o tamanho, mas vai abortar um upload grande e lento no meio da transferência em uma conexão ruim. É um sintoma à parte, não faz parte do teto de tamanho.

A armadilha: você define upload_max_filesize = 256M, recarrega, e ainda não consegue enviar um arquivo de 100 MB — porque post_max_size continua em 8M. O PHP rejeita a requisição pelo corpo total antes mesmo de inspecionar o arquivo. O limite não te ignorou. Um limite diferente pegou o arquivo primeiro.

Como corrigir, na ordem certa

Vá do que tem mais chance de resolver até o último recurso.

1. Edite o php.ini (o lugar correto). Encontre o arquivo que o seu site realmente carrega — execute uma página com <?php phpinfo(); e leia “Loaded Configuration File”, ou pergunte à sua hospedagem. Defina os dois valores do PHP e mantenha post_max_size maior que upload_max_filesize:

upload_max_filesize = 256M
post_max_size = 260M
max_execution_time = 300

Reinicie o PHP-FPM (sudo systemctl restart php8.2-fpm) ou o Apache. As mudanças não têm efeito até o processo do PHP reiniciar.

2. Sem acesso ao php.ini? Use o .htaccess (apenas Apache + mod_php). Adicione ao .htaccess na raiz do seu WordPress:

php_value upload_max_filesize 256M
php_value post_max_size 260M
php_value max_execution_time 300

Isso só funciona quando o PHP roda como módulo do Apache. Sob PHP-FPM, CGI ou FastCGI, php_value gera um erro 500 — essa falha significa que você está no caminho errado, não que o número está errado. Mude para o .user.ini:

upload_max_filesize = 256M
post_max_size = 260M

3. Aumente o limite do servidor web — o passo que todo mundo esquece. No Nginx, o PHP nem chega a ver uma requisição grande demais; o Nginx retorna 413 Request Entity Too Large primeiro. No seu bloco de servidor:

client_max_body_size 256M;

Recarregue com sudo nginx -t && sudo systemctl reload nginx. Se você está no Nginx e suas edições no PHP “não fizeram nada”, quase sempre é por isso.

Depois de qualquer mudança, verifique novamente os valores reportados. A ferramenta de limite de upload vai te dizer o novo teto efetivo e gerar o trecho exato para a sua configuração, para você não ficar adivinhando qual dos três ainda está baixo.

O que não fazer

Não edite o wp-config.php esperando que ele levante o limite. A linha amplamente copiada não faz o que os posts de blog afirmam:

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

upload_max_filesize é PHP_INI_PERDIR. Ele não pode ser alterado pelo PHP em tempo de execução com ini_set(). Ele só aceita novos valores do php.ini, .htaccess ou .user.ini — nunca do código da aplicação. A linha roda sem erro e não faz nada, o que a torna um dos conselhos errados mais repetidos com confiança no mundo WordPress.

Também não cole @ini_set('post_max_size', ...) — mesma restrição, mesma inutilidade silenciosa.

Não defina WP_MEMORY_LIMIT achando que é o limite de upload. Isso controla o teto de memória do PHP para executar código. Não tem relação com o tamanho de arquivo que o servidor aceita.

Não pare em um único arquivo. A falha mais comum de todas é alterar só o upload_max_filesize e declarar que a correção está quebrada. Altere os três, e mantenha post_max_size acima de upload_max_filesize.

Não defina limites absurdamente altos “por segurança”. Um limite de 2 GB convida a problemas de esgotamento de recursos e não ajuda — se você realmente precisa de arquivos de vários gigabytes, envie-os fora do navegador (SFTP, ou um plugin de upload em blocos) em vez de forçá-los por um único POST do PHP.

Ainda travado?

Se os três valores foram aumentados e você ainda bate numa parede, a requisição está sendo limitada em algum ponto antes do seu servidor: um CDN ou proxy (o painel da Cloudflare limita o tamanho do corpo de upload por conta própria), um limite de plataforma de uma hospedagem gerenciada que ignora o seu php.ini, ou um .user.ini que ainda não atualizou — ele respeita o user_ini.cache_ttl do PHP, então pode demorar alguns minutos depois de você salvar. Confirme o que o servidor realmente reporta, não o que você escreveu num arquivo, e corrija a camada que ainda está baixa. Quando o número reportado finalmente bater com a sua meta, o upload funciona.