Como corrigir o Flexible Content que não salva layouts no ACF PRO
Perguntas frequentes
Por que o Flexible Content do ACF PRO não salva os layouts?
Na grande maioria dos casos é o max_input_vars do PHP baixo demais. Cada subcampo de cada layout vira uma variável no POST; quando o total passa do limite (padrão 1000), o PHP corta o excedente e o ACF perde os dados ou o nonce de validação. Elevar max_input_vars para 10000 resolve.
O que significa a mensagem de nonce não recebido no ACF?
É o ACF avisando que o envio do formulário chegou incompleto. O nonce é o token de segurança que valida o salvamento; quando o max_input_vars corta o POST, o nonce não chega ao servidor e o ACF mostra esse aviso em vez de gravar dados pela metade. A causa raiz costuma ser o mesmo limite de variáveis.
Para quanto devo aumentar o max_input_vars?
A documentação do ACF recomenda no mínimo 10000 para páginas com muitos campos. Esse valor cobre folgadamente um Flexible Content com dezenas de layouts e subcampos. Não há ganho em exagerar muito além disso, então 10000 é o alvo recomendado.
Onde eu mudo o max_input_vars no WordPress?
O lugar ideal é o php.ini. Se você não tem acesso a ele, use o .htaccess em servidores Apache com PHP como módulo, ou o arquivo .user.ini quando o host roda PHP-FPM. Em hospedagem gerenciada, muitas vezes é mais rápido pedir ao suporte para subir o limite.
Por que só os últimos layouts somem e os primeiros ficam?
Porque o PHP corta o POST a partir do ponto em que o limite é atingido. Os campos enviados antes do corte são gravados; os que vêm depois são descartados. Por isso os primeiros layouts persistem e os últimos que você adicionou desaparecem ao salvar.
Aumentei o max_input_vars e o problema continua. E agora?
Confirme em Saúde do site que o novo valor realmente entrou em vigor, pois em PHP-FPM o .htaccess não funciona e o ajuste precisa ir no .user.ini ou no php.ini. Se o valor já estiver em 10000 e a falha persistir, investigue erro de JavaScript de outro plugin ligando o SCRIPT_DEBUG e olhando o console do navegador.
Esse erro corrompe os dados que já estavam salvos?
Não costuma corromper o que já estava gravado, mas a tentativa de salvar pode sobrescrever o registro com a versão truncada, fazendo parecer que os layouts antigos sumiram. Por isso vale fazer backup do banco antes de editar páginas grandes enquanto o limite ainda estiver baixo.
Um WAF ou plugin de segurança pode causar o mesmo sintoma?
Pode. Regras de mod_security ou de plugins de firewall às vezes bloqueiam ou truncam requisições POST grandes, derrubando parte dos campos antes de chegarem ao PHP. Se o max_input_vars já está em 10000 e o salvamento continua falhando só em páginas grandes, peça ao host para revisar as regras de WAF para a tela de edição.














