Como Corrigir o Erro “O Link Que Você Seguiu Expirou” no WordPress

O erro "The link you followed has expired" no WordPress é acionado quando um upload de ficheiro ou envio de formulário excede um ou mais limites de tempo de execução PHP — especificamente upload_max_filesize, post_max_size, max_execution_time, ou memory_limit. O WordPress não consegue recuperar graciosamente destas rejeições do lado do servidor, pelo que apresenta esta mensagem genérica em vez de um erro PHP específico.

A correção requer aumentar os valores dessas diretivas PHP através da camada de configuração que o seu ambiente de alojamento expõe: php.ini, .htaccess, wp-config.php, ou uma interface de painel de controlo. O método que funciona depende inteiramente do seu nível de acesso ao servidor — acesso root SSH, cPanel gerido, ou um ambiente partilhado restrito requerem cada um uma abordagem diferente.

Por Que Este Erro Ocorre Realmente

Compreender a causa raiz evita que aplique a correção errada. Quando o WordPress processa um upload, o navegador envia um pedido POST multipart para wp-admin/async-upload.php ou wp-admin/update.php. O PHP avalia o pedido em relação a quatro limites independentes antes de o WordPress executar uma única linha de código de aplicação:

• upload_max_filesize — limite máximo para qualquer ficheiro carregado individualmente
• post_max_size — limite para todo o corpo POST, que deve ser *maior* que upload_max_filesize
• max_execution_time — segundos máximos de tempo real que um processo PHP pode executar
• memory_limit — RAM disponível para o processo PHP; o processamento de imagens e a instalação de temas consomem muita memória

Se qualquer um destes for ultrapassado, o PHP termina silenciosamente o pedido. O WordPress recebe uma resposta vazia ou malformada e apresenta "The link you followed has expired." O erro não é um bug do WordPress — é o PHP a aplicar a política do servidor.

Causas comuns na prática:

• Instalar um tema premium (frequentemente 5–30 MB) num servidor partilhado com um limite de upload padrão de 2 MB
• Carregar um ficheiro CSV de importação de produtos WooCommerce
• Instalar um pacote de plugin que inclui recursos agrupados
• Restaurar um site a partir de um arquivo de backup através do painel do WordPress
• Executar um script de importação de longa duração que atinge o limite de tempo de execução

Tabela de Referência Rápida de Diretivas PHP

Regra crítica: post_max_size deve ser sempre definido com um valor superior a upload_max_filesize. Se definir upload_max_filesize = 128M mas deixar post_max_size = 8M, os uploads continuarão a falhar porque o limite do corpo POST é atingido primeiro.

Método 1: Editar php.ini (Recomendado para VPS e Servidores Dedicados)

Este é o método mais fiável e permanente. Num ambiente de Alojamento VPS ou Servidor Dedicado onde tem acesso root ou sudo, controla diretamente a configuração PHP.

Localizar o ficheiro php.ini ativo:

php --ini | grep "Loaded Configuration File"

Ou a partir de um site WordPress, crie um ficheiro temporário:

<?php phpinfo(); ?>

Procure a linha Loaded Configuration File no resultado e, em seguida, elimine o ficheiro imediatamente.

Editar as diretivas:

upload_max_filesize = 128M
post_max_size = 256M
max_execution_time = 300
max_input_time = 300
memory_limit = 256M

Após guardar, reinicie o PHP-FPM ou o Apache para aplicar as alterações:

# For PHP-FPM (most common on modern stacks)
sudo systemctl restart php8.2-fpm

# For Apache with mod_php
sudo systemctl restart apache2

# For Nginx + PHP-FPM
sudo systemctl restart nginx php8.2-fpm

Verificar se os novos valores entraram em vigor:

php -r "echo ini_get('upload_max_filesize');"

Caso especial a conhecer: Em servidores que executam múltiplas versões PHP (uma configuração comum no cPanel), existe um php.ini separado para cada versão. Editar o errado não tem qualquer efeito. Confirme qual a versão PHP que o WordPress está a utilizar antes de editar.

Método 2: Utilizar .htaccess (Alojamento Partilhado Apache)

Se estiver em alojamento partilhado sem acesso direto a php.ini, e o seu servidor executar Apache com mod_php ou suPHP, pode substituir diretivas PHP por diretório utilizando .htaccess.

Aceda ao diretório raiz do WordPress via FTP, SFTP, ou o gestor de ficheiros do seu alojamento. Abra .htaccess e acrescente o seguinte bloco:

<IfModule mod_php.c>
    php_value upload_max_filesize 128M
    php_value post_max_size 256M
    php_value max_execution_time 300
    php_value max_input_time 300
    php_value memory_limit 256M
</IfModule>

Guarde e carregue o ficheiro, depois teste o seu upload.

Advertências importantes:

• Este método não funciona em servidores que executam PHP-FPM, CGI, ou FastCGI. Nessas configurações, as diretivas php_value em .htaccess causarão um Erro Interno do Servidor 500 porque o módulo Apache que gere o PHP não é mod_php. Se vir um erro 500 após guardar, remova essas linhas imediatamente.
• Em servidores Nginx, .htaccess é completamente ignorado. Utilize php.ini ou um ficheiro de substituição de utilizador php.ini em vez disso.
• Alguns alojamentos geridos desativam explicitamente AllowOverride para diretivas PHP, tornando este método ineficaz mesmo no Apache.

Método 3: Adicionar Diretivas a wp-config.php

Este método utiliza a função ini_set() do PHP para substituir diretivas em tempo de execução. Funciona independentemente do tipo de servidor web, mas está sujeito às restrições open_basedir e disable_functions do alojamento — alguns alojamentos bloqueiam ini_set() por razões de segurança.

Abra wp-config.php no seu diretório raiz do WordPress e adicione as seguintes linhas antes do comentário /* That's all, stop editing! Happy publishing. */:

@ini_set( 'upload_max_size',    '128M' );
@ini_set( 'post_max_size',      '256M' );
@ini_set( 'max_execution_time', '300'  );
@ini_set( 'max_input_time',     '300'  );
@ini_set( 'memory_limit',       '256M' );

O @ suprime erros se ini_set() estiver desativado, evitando um ecrã branco. No entanto, se o alojamento tiver bloqueado estes valores ao nível do servidor utilizando php_admin_value, as chamadas ini_set() são silenciosamente ignoradas — os valores não serão alterados.

Como verificar se realmente funcionou:

Instale o plugin gratuito Query Monitor e verifique o separador de ambiente PHP, ou adicione uma chamada temporária phpinfo(). Se os valores ainda mostrarem os limites antigos, ini_set() está a ser substituído a um nível superior e precisa de utilizar um método diferente.

Método 4: Ajustar as Definições PHP no cPanel

Para ambientes de alojamento geridos através do cPanel — incluindo VPS com cPanel — pode modificar os limites PHP através da interface gráfica sem tocar em nenhum ficheiro.

Passos:

1. Inicie sessão no cPanel.
2. Navegue até Software e clique em MultiPHP INI Editor.
3. Selecione a raiz do documento do seu site WordPress no menu suspenso.
4. Localize e atualize os seguintes campos:

• upload_max_filesize → 128M
• post_max_size → 256M
• max_execution_time → 300
• memory_limit → 256M

1. Clique em Aplicar.

Em alternativa, utilize Select PHP Version (PHP Selector) se o seu alojamento utilizar CloudLinux. No separador Options, as mesmas diretivas estão disponíveis como controlos deslizantes ou campos de entrada.

O que o cPanel faz nos bastidores: Escreve um ficheiro .user.ini (para PHP-FPM) ou modifica .htaccess (para mod_php) no seu diretório raiz do documento. Se posteriormente editar manualmente esses ficheiros, pode sobrescrever as alterações do cPanel — esteja ciente deste conflito.

Método 5: Criar ou Editar um Ficheiro .user.ini (Ambientes PHP-FPM)

Este é o método que a maioria dos tutoriais omite, mas é a abordagem correta para PHP-FPM — que é o handler PHP padrão em praticamente todas as configurações de alojamento modernas, incluindo ambientes baseados em Nginx.

Crie um ficheiro chamado .user.ini no diretório raiz do WordPress com o seguinte conteúdo:

upload_max_filesize = 128M
post_max_size = 256M
max_execution_time = 300
max_input_time = 300
memory_limit = 256M

Carregue-o para o mesmo diretório que wp-config.php. O PHP-FPM verifica periodicamente os ficheiros .user.ini — o TTL da cache é controlado por user_ini.cache_ttl, que tem como padrão 300 segundos (5 minutos). As alterações não são instantâneas. Se precisar de efeito imediato, reinicie o PHP-FPM.

sudo systemctl restart php8.2-fpm

Nota de segurança: O ficheiro .user.ini não deve ser acessível pela web. Adicione isto ao seu .htaccess se estiver no Apache:

<Files ".user.ini">
    Require all denied
</Files>

No Nginx, adicione um bloco de localização para negar o acesso:

location ~ /.user.ini {
    deny all;
}

Método 6: Contactar o Seu Fornecedor de Alojamento

Se nenhum dos métodos acima produzir uma alteração nos valores PHP que verificou com phpinfo() ou Query Monitor, o alojamento está a aplicar limites ao nível do pool PHP-FPM ou através de diretivas php_admin_value na configuração do servidor — ambas as quais não podem ser substituídas por nenhum ficheiro acessível ao utilizador.

Neste caso, contacte o suporte e solicite aumentos específicos. Forneça os nomes exatos das diretivas e os valores pretendidos. Se o alojamento recusar ou impuser um limite máximo que não satisfaz os seus requisitos, considere migrar para um plano de Alojamento VPS onde controla totalmente a configuração PHP.

Diagnosticar Qual o Limite que Está Realmente a Causar o Erro

Em vez de adivinhar, utilize estes passos de diagnóstico antes de aplicar qualquer correção:

Verificar os limites PHP atuais a partir da linha de comandos:

php -r "echo 'upload_max_filesize: ' . ini_get('upload_max_filesize') . PHP_EOL;
echo 'post_max_size: ' . ini_get('post_max_size') . PHP_EOL;
echo 'max_execution_time: ' . ini_get('max_execution_time') . PHP_EOL;
echo 'memory_limit: ' . ini_get('memory_limit') . PHP_EOL;"

Verificar o registo de erros PHP para a falha real:

tail -n 50 /var/log/php/error.log
# or
tail -n 50 /var/log/apache2/error.log

Procure linhas que contenham Allowed memory size, Maximum execution time, ou POST Content-Length. A mensagem específica indica-lhe exatamente qual a diretiva a corrigir.

Verifique o tamanho do ficheiro que está a carregar em relação ao upload_max_filesize atual. Se o ficheiro tiver 45 MB e o limite for 64 MB, o limite de upload não é o problema — procure em post_max_size ou memory_limit.

Escolher o Método Correto: Matriz de Decisão

Lista de Verificação Técnica Antes de Considerar o Problema Resolvido

• post_max_size está definido acima de upload_max_filesize — esta é a configuração incorreta mais comum
• As alterações foram verificadas com phpinfo() ou php -r "echo ini_get(...)" — não apenas assumidas
• O PHP-FPM foi reiniciado se .user.ini ou php.ini foi editado diretamente
• O .user.ini ou php.ini que está a ser editado corresponde à versão PHP que está realmente a servir o site WordPress
• memory_limit é pelo menos 256M se estiver a instalar temas grandes ou a executar operações com muitas imagens
• O registo de erros foi verificado para confirmar qual o limite específico que causou a terminação
• Se estiver num plano de Alojamento Web Partilhado, o limite máximo do alojamento foi confirmado — alguns fornecedores limitam upload_max_filesize a 64M independentemente das definições do utilizador
• Após corrigir o erro de upload, verifique se os seus Certificados SSL são válidos se estiver a aceder ao wp-admin via HTTPS, pois erros de conteúdo misto ou de certificado podem produzir falhas de redirecionamento superficialmente semelhantes

FAQ

Por que o erro aparece mesmo depois de ter aumentado upload_max_filesize em .htaccess?

O servidor está provavelmente a executar PHP via FastCGI ou PHP-FPM em vez de mod_php. A diretiva php_value em .htaccess só é processada pelo handler mod_php do Apache. Em configurações PHP-FPM, utilize um ficheiro .user.ini no diretório raiz do WordPress.

Qual é a diferença entre upload_max_filesize e post_max_size, e por que ambos são importantes?

upload_max_filesize limita o tamanho de cada ficheiro individual num upload multipart. post_max_size limita o tamanho total de todo o corpo do pedido POST, que inclui os dados do ficheiro mais os campos do formulário e os delimitadores. Se post_max_size for menor que upload_max_filesize, o limite do corpo POST é atingido primeiro e o PHP descarta todo o pedido antes de o WordPress poder avaliar o tamanho do ficheiro.

As minhas chamadas ini_set() em wp-config.php estão a ser ignoradas. Porquê?

O alojamento está a utilizar php_admin_value na configuração do pool PHP-FPM ou no bloco do virtual host Apache. php_admin_value define uma diretiva como apenas de leitura da perspetiva da aplicação — as chamadas ini_set() para essas diretivas são silenciosamente descartadas. Apenas o fornecedor de alojamento pode alterar os valores definidos desta forma.

Como verifico se as minhas alterações de configuração PHP realmente entraram em vigor?

Crie um ficheiro temporário no diretório raiz do WordPress contendo <?php phpinfo(); ?>, aceda-lhe num navegador e procure o nome da diretiva. A coluna Local Value mostra o valor efetivo para esse diretório. Elimine o ficheiro imediatamente após verificar — deixar o resultado de phpinfo() publicamente acessível é um risco de segurança.

Este erro pode ser causado por algo diferente dos limites de upload PHP?

Sim. A expiração de um nonce do WordPress pode produzir a mesma mensagem. Os nonces do WordPress são válidos por 24 horas por padrão. Se um utilizador abrir a página de upload de plugins, a deixar inativa por mais de 24 horas e depois enviar o formulário, a validação do nonce falha e o WordPress apresenta "The link you followed has expired." Neste caso, simplesmente atualizar a página gera um novo nonce e o upload prossegue normalmente — não são necessárias alterações de configuração PHP.