Configurou o seu tema, adicionou uma dúzia de plugins, configurou campos personalizados e, de repente, o WordPress deixa de guardar as definições dos menus. Clica em «Guardar», mas alguns itens do menu simplesmente desaparecem.

Isto não é uma falha do painel de administração nem um problema de um plugin. O PHP no servidor atingiu o limite da variável de entrada max_input_vars e está a truncar silenciosamente os dados provenientes do formulário. Por predefinição, o limite é 1000, o que é claramente insuficiente para uma configuração moderna do WordPress com alguns plugins pesados.

Abaixo estão três formas de aumentar o limite: desde uma edição rápida do.htaccess até às definições do painel de alojamento. Todos os métodos foram testados no Apache e no PHP-FPM e funcionam do PHP 7.4 ao 8.4.

O que é o max_input_vars e como se manifesta o erro

max_input_vars é uma diretiva do PHP que limita o número de variáveis aceites nos pedidos GET, POST e COOKIE. A restrição aplica-se a cada array superglobal separadamente: as variáveis POST são contabilizadas independentemente das GET e COOKIE.

Para um website simples de cartão de visita, mil variáveis são mais do que suficientes. Mas o painel de administração do WordPress gera dezenas de campos para cada entidade: itens de menu, widgets, opções do personalizador, metaboxes de plugins. Quando um formulário de menu contém 80 itens, cada um a transmitir 12 a 15 variáveis, o limite é excedido de forma invisível e parte dos dados perde-se durante a gravação.

Sintomas que indicam este problema específico:

• Os itens do menu não são guardados ou são guardados apenas parcialmente.
• Os widgets repõem-se espontaneamente como inativos.
• Um plugin (como um plugin de SEO ou um construtor de páginas) perde algumas definições após a gravação.
• Na Saúde do Site (Ferramentas → Saúde do Site → Informação → Servidor), o valor PHP max input variables é igual a 1000 ou menos.

A recomendação padrão da comunidade WordPress é aumentar o limite para 3000. Isto é suficiente para a maioria das configurações. Sites com painéis de administração particularmente pesados (menus de vários níveis com mais de 100 itens, Mega Menu, dezenas de campos ACF) podem definir com segurança 5000 ou até 10000, uma vez que isto praticamente não tem impacto no desempenho do servidor.

💡 Resumo rápido:

• Verifique o limite atual: phpinfo() ou a Saúde do Site no painel do WordPress.
• Método 1: adicione php_value max_input_vars 3000 ao seu ficheiro.htaccess, funciona com o Apache a usar mod_php.
• Método 2: adicione max_input_vars = 3000 ao php.ini ou.user.ini, adequado para PHP-FPM.
• Método 3: altere o valor através do painel de alojamento, uma opção para quem não tem acesso direto aos ficheiros do servidor.

Método 1: editar o.htaccess

Este método funciona quando o PHP é executado como um módulo do Apache (mod_php). Pode determinar isto em Ferramentas → Saúde do Site → Informação → Servidor: a linha Server architecture contém Apache e o gestor de PHP está listado como um módulo, não como FPM/FastCGI.

Antes de editar, faça uma cópia de segurança do.htaccess: transfira o ficheiro via FTP ou através do gestor de ficheiros do seu alojamento para o seu computador. As edições neste ficheiro são sensíveis à sintaxe; um espaço extra ou uma quebra de linha podem deitar o site abaixo com um erro 500.

Abra o.htaccess (localizado na raiz do site, ao lado do wp-config.php) e adicione a linha:

1
php_value max_input_vars 3000

Se o servidor tiver a extensão Suhosin instalada (raro em 2026, mas ainda presente em alojamentos partilhados mais antigos), uma linha não é suficiente. Adicione três diretivas:

1
php_value suhosin.request.max_vars 3000
2
php_value suhosin.post.max_vars 3000
3
php_value suhosin.get.max_vars 3000

O Suhosin interceta as variáveis antes do PHP e trunca-as independentemente do max_input_vars, daí o conjunto adicional de linhas.

Depois de guardar o.htaccess, abra o painel do WordPress → Ferramentas → Saúde do Site → Informação → Servidor e verifique se PHP max input variables mostra o novo valor. Se não tiver mudado, leia a secção «O que fazer se o limite continuar a não mudar» abaixo.

Método 2: editar o php.ini ou.user.ini

Em servidores modernos, o PHP é executado mais frequentemente através do PHP-FPM, e as diretivas php_value no.htaccess são ignoradas. A ferramenta funcional aqui é o php.ini ou.user.ini.

O .user.ini é processado pelo PHP-FPM por diretório: o ficheiro é colocado na raiz do site e aplica-se recursivamente a todas as subpastas. Ao contrário do .htaccess, que o Apache lê em cada pedido, este é o mecanismo padrão do PHP, suportado desde a versão 5.3.

Crie (ou edite um existente) ficheiro .user.ini na raiz do site e adicione:

1
max_input_vars = 3000

Se tiver acesso ao php.ini global (VPS/servidor dedicado), altere o valor também aí. O caminho exato para o php.ini pode ser encontrado através do phpinfo(): procure a linha Loaded Configuration File. Após editar o php.ini, é necessário reiniciar o PHP-FPM:

1
sudo systemctl restart php8.2-fpm

Substitua o número da versão no comando pela sua (8.1, 8.2, 8.3, 8.4). Verifique o novo valor através da Saúde do Site; deve ser atualizado imediatamente.

Se o ficheiro .user.ini não existir, basta criá-lo num editor de texto. O nome começa com um ponto, pelo que poderá ter de ativar a visualização de ficheiros ocultos no gestor de ficheiros do seu alojamento.

Método 3: alterar o limite através do painel de alojamento

Para alojamento partilhado (cPanel, ISPmanager, DirectAdmin), a abordagem mais simples é alterar o valor através da interface gráfica, sem mexer manualmente nos ficheiros.

cPanel: vá a Select PHP Version → mude para o separador Options. Encontre a linha max_input_vars, altere o valor de 1000 para 3000 e clique em Save. A alteração é aplicada instantaneamente; não é necessário reiniciar.

ISPmanager: secção PHP → definições → parâmetros adicionais → max_input_vars.

DirectAdmin: PHP Settings → encontre a diretiva na lista → altere → guarde.

Se o painel não tiver um campo max_input_vars, o alojamento usa um php.ini fixo, sem direitos de edição. Neste caso, só o contacto com o suporte ajudará: envie um ticket a solicitar o aumento de max_input_vars para 3000 (ou o valor específico de que necessita). A maioria dos alojamentos altera o limite ao primeiro pedido; esta é uma operação de rotina.

O que fazer se o limite continuar a não mudar

Situação: as linhas no.htaccess e.user.ini estão no lugar, o painel de alojamento mostra o novo valor, mas a Saúde do Site mostra teimosamente 1000. Causas e as suas soluções:

Método errado para a alteração. O max_input_vars pertence ao modo PHP_INI_PERDIR: a diretiva só pode ser alterada no php.ini,.htaccess,.user.ini ou httpd.conf. A função ini_set() no wp-config.php não tem qualquer efeito sobre ela; o código @ini_set('max_input_vars', 3000) executa a operação, mas o PHP ignora-a silenciosamente. Não perca tempo com este método.

Cache de configuração do PHP. Alguns painéis (especialmente o cPanel com PHP-FPM) armazenam em cache os ficheiros ini. Após editar o.user.ini, aguarde 5 minutos; este é o tempo que o PHP-FPM, por predefinição, mantém a cache de configuração para um diretório específico. Pode acelerar o processo reiniciando o PHP-FPM a partir do painel de alojamento.

Dois ficheiros php.ini. Em alojamento partilhado, há frequentemente um php.ini global numa pasta e um local noutra. O PHP carrega o primeiro que encontra no arranque. Verifique o caminho para Loaded Configuration File via phpinfo() e edite esse ficheiro específico. A pasta adicional Scan this directory for additional .ini files também pode conter o limite; verifique esta pasta também.

Limite rígido do alojamento. Alguns fornecedores bloqueiam as alterações ao max_input_vars ao nível do contentor (limites do CloudLinux com PHP Selector). No phpinfo(), a diretiva está marcada como no value ou nem sequer aparece. Isto significa que o alojamento definiu um teto acima das edições do utilizador; só um ticket de suporte ou uma atualização de plano resolverá.

⁉️🤔 Perguntas frequentes

Quanto devo definir exatamente: 3000 ou mais?

Para a grande maioria dos sites WordPress, 3000 é suficiente. Este valor cobre menus até 120 itens, painéis de administração com uma dúzia de plugins ativos e páginas do personalizador com dez secções. Defina 5000 se usar o Mega Menu com mais de 150 itens, um construtor como o Elementor com centenas de campos por página, ou ACF com layouts flexíveis. Acima de 10000, apenas se o criador do plugin o especificar explicitamente na documentação.

Porque é que o limite voltou a 1000 após uma atualização do PHP?

A atualização da versão do PHP através do painel de alojamento muitas vezes carrega o php.ini padrão. Verifique o.user.ini e o painel; muito provavelmente o ficheiro ainda está lá, mas o alojamento mudou o pool para uma nova configuração sem as suas edições.

Posso definir o limite através do wp-config.php?

Não. A diretiva max_input_vars tem o modo PHP_INI_PERDIR e não pode ser alterada via ini_set(); o PHP irá ignorar silenciosamente tal chamada. Apenas o.htaccess (no Apache com mod_php),.user.ini / php.ini e o painel de alojamento funcionam.

Como posso saber se o problema é especificamente o max_input_vars e não outra coisa?

O indicador mais preciso são os logs do PHP. Ative o WP_DEBUG no wp-config.php: define('WP_DEBUG', true);. Após uma gravação de formulário falhada, verifique /wp-content/debug.log: se houver uma entrada Warning: Input variables exceeded 1000, o diagnóstico está confirmado.

O que devo fazer se o meu alojamento não me permitir alterar o limite?

Contacte o suporte com um número específico (por exemplo, «aumentar o max_input_vars para 3000»). Este é um pedido padrão; o suporte satisfá-lo gratuitamente na maioria dos fornecedores. Recusam em dois casos: um plano extremamente barato com limites estritamente fixos (então só uma atualização ajuda) ou um site em alojamento partilhado com centenas de vizinhos onde os limites individuais não são arquitetonicamente suportados.

Resumo: qual o método a escolher para a sua situação

Ordem de ações, da mais simples para a mais complexa.

Se estiver num alojamento partilhado com cPanel, comece com o método 3 (painel). São três cliques e, na maioria dos casos, o problema fica resolvido. Se o valor não mudar na Saúde do Site, experimente o método 2 via.user.ini: o ficheiro é colocado na raiz do site e é carregado pelo PHP-FPM automaticamente.

Se tiver um VPS ou servidor dedicado com Apache e mod_php, o método 1 (.htaccess) dá resultados instantâneos e não requer o reinício de serviços. Para uma configuração Apache + PHP-FPM, use o método 2 (php.ini ou.user.ini).

Se o painel não permitir a edição, o suporte não responder e o limite estiver bloqueado nos 1000, poderá ter ultrapassado o seu plano atual. As configurações do WordPress tornam-se mais pesadas a cada ano: mais campos, mais dados, requisitos mais elevados do ambiente de servidor. Mudar de alojamento para um plano mais flexível resolve o problema de forma radical e também melhora o desempenho geral do site.

Comece por verificar a Saúde do Site agora mesmo: Ferramentas → Saúde do Site → Informação → Servidor → PHP max input variables. Se mostrar 1000 ou menos, qualquer uma das três soluções acima irá restaurar o seu controlo sobre o painel de administração em 5 minutos.