Flexible Content não salva no ACF PRO: como corrigir

Tipo Page Builders

Nome do erro Flexible Content do ACF PRO não salva layouts EN: ACF PRO Flexible Content not saving layouts

Severidade Grave

Descrição O Flexible Content que não salva no ACF PRO acontece quando os layouts e seus subcampos viram tantos campos no formulário que o POST ultrapassa o limite max_input_vars do PHP: o WordPress descarta o excedente, o nonce ou os dados não chegam e a atualização do post perde os layouts. A correção é elevar max_input_vars para 10000.

O que é o Flexible Content que não salva no ACF PRO?

O Flexible Content do ACF PRO é um campo que monta blocos de conteúdo a partir de layouts, e cada layout pode conter vários subcampos. Cada subcampo de cada linha vira uma entrada própria no formulário enviado quando você atualiza o post. Quando a página tem muitos layouts adicionados (ou layouts com muitos subcampos), o número de variáveis enviadas no POST passa do limite max_input_vars do PHP, que por padrão fica em 1000. O PHP corta tudo o que excede esse limite de forma silenciosa, sem erro fatal. O resultado é que parte dos dados, e às vezes o próprio nonce de validação do ACF, nunca chega ao servidor: o ACF não consegue validar o envio e os layouts somem ou voltam ao estado anterior depois de salvar. A partir da versão 6.3.12 o ACF passou a avisar explicitamente sobre essa falha, em vez de só perder os dados em silêncio.

Como identificar

Mensagem “ACF was unable to perform validation because no nonce was received by the server.” ao clicar em Atualizar, no topo da tela de edição do post (ACF 6.3.12 ou superior).
Mensagem “ACF was unable to perform validation because the provided nonce failed verification.” também no topo do editor ao salvar.
Os layouts do Flexible Content somem ou voltam ao conteúdo antigo logo depois de a página recarregar com a barra verde de “Post atualizado”.
Só os PRIMEIROS layouts são salvos e os últimos que você adicionou desaparecem, sinal clássico de corte do POST a partir de certo ponto.
Em Ferramentas -> Saúde do site -> Informações -> Servidor, o valor de max_input_vars aparece em 1000 (ou menor) num post que tem dezenas de subcampos.
Nenhum aviso quando há poucos layouts; a falha só aparece nas páginas mais cheias, o que confirma a relação com a quantidade de campos.

Antes de começar: Faça backup do .htaccess e do wp-config.php antes de editar: um erro de sintaxe no .htaccess derruba o site inteiro com erro 500. Edite uma linha por vez e teste o front-end após cada alteração.

Como prevenir

Deixe max_input_vars em 10000 desde a configuração inicial do servidor em sites que usam ACF PRO com Flexible Content.
Quando um layout precisar de muitos subcampos, prefira quebrar o conteúdo em vários posts ou usar o Repeater com paginação, para não inflar o POST de uma única tela.
Mantenha o ACF PRO sempre na última versão: a partir da 6.3.12 ele avisa o problema de nonce em vez de perder os dados em silêncio.
Teste o salvamento de uma página cheia em homologação antes de o cliente montar dezenas de layouts em produção.

Causa

max_input_vars do PHP em 1000 (valor padrão) enquanto o post tem mais de 1000 variáveis somando todos os layouts e subcampos do Flexible Content; o PHP descarta o excedente e o ACF perde os dados ou o nonce.
Página com muitos layouts repetidos ou layouts com muitos subcampos (Repeater dentro do Flexible Content, galerias, grupos), multiplicando o número de variáveis enviadas no POST muito além do esperado.
Erro de JavaScript de outro plugin ou do tema travando a interface do ACF, que é movida a JS; com o JS quebrado o campo não monta o valor a enviar e o Atualizar salva vazio.
Plugin de segurança ou WAF (como mod_security no servidor) bloqueando ou truncando requisições POST grandes, o que derruba parte dos campos do Flexible Content antes de chegarem ao PHP.
Field group do Flexible Content sincronizado por JSON local e fora de sincronia com o banco, fazendo o ACF gravar com uma definição de campo diferente da que está sendo editada na tela.

Como resolver

Confirme o valor atual de max_input_vars: veja o limite que o servidor aplica hoje. Abra a tela de Saúde do site e procure o valor na seção do servidor:
```
Painel WP -> Ferramentas -> Saúde do site -> Informações -> Servidor -> PHP max input variables
```
Eleve max_input_vars para pelo menos 10000: a documentação do ACF recomenda no mínimo 10000 para páginas com muitos campos. Ajuste no php.ini (caminho ideal); se não tiver acesso a ele, peça ao seu host para alterar:
```
max_input_vars = 10000
```
Se não houver acesso ao php.ini, use o .htaccess (Apache): em hospedagem Apache com PHP como módulo, dá para definir o limite pelo .htaccess da raiz do site. Adicione a linha e salve:
```
php_value max_input_vars 10000
```
Em PHP-FPM ou CGI, ajuste pelo .user.ini: quando o host roda PHP-FPM (a maioria hoje), o .htaccess não aceita php_value. Crie ou edite o arquivo .user.ini na raiz do site com a linha abaixo e aguarde alguns minutos para o PHP reler:
```
.user.ini
max_input_vars = 10000
```
Recarregue, confirme o novo valor e teste o salvamento: volte à Saúde do site e confirme que o valor agora é 10000. Reabra o post, adicione novamente os layouts que sumiram e clique em Atualizar. Os dados devem persistir e os avisos de nonce do ACF devem desaparecer:
```
Painel WP -> Ferramentas -> Saúde do site -> Informações -> Servidor -> PHP max input variables
```
Se o aviso persistir, isole conflito de JavaScript: se o salvamento ainda falhar com o limite já em 10000, ligue o modo de scripts não minificados e abra o console do navegador na tela de edição para ver qual plugin trava o JS do ACF. No wp-config.php, ligue:
```
define( 'SCRIPT_DEBUG', true );
```

APACHE

# .htaccess (Apache com PHP como modulo) ou php.ini do site
# Eleva o limite de variaveis de POST para o ACF Flexible Content nao perder layouts.
# A doc do ACF recomenda no minimo 10000 em paginas com muitos campos.
php_value max_input_vars 10000
php_value max_input_time 600
php_value max_execution_time 600

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.

Atenção

Como corrigir o erro de cores no Global Color Palette do Astra Pro no WordPress

O Global Color Palette do Astra Pro não aplica quando o CSS dinâmico do tema fica preso em cache, quando a cor foi fixada manualmente no page builder ou em CSS adicional, ou quando um tema filho sobrescreve as variaveis de cor da paleta. Limpar o cache do Astra e remover os valores fixos restaura as cores em todo o site.

Atenção

Como corrigir o erro de JavaScript no JetSmartFilters no WordPress

O erro de JavaScript no JetSmartFilters acontece quando o script de filtragem trava no navegador por conflito de scripts, provider mal configurado ou cache servindo um arquivo antigo, fazendo os filtros pararem de aplicar e o console exibir mensagens de erro.

Atenção

Como corrigir o Modal Popup do Ultimate Addons que não abre no WordPress

O modal popup do Ultimate Addons não abre quando o tipo de gatilho está mal configurado, quando o elemento de clique não recebe a classe ou ID que dispara o modal, ou quando um conflito de JavaScript interrompe o script do widget antes de o popup ser acionado.

Atenção

Como corrigir o erro de CORS de fontes no Elementor

O erro de CORS de fontes no Elementor ocorre quando o arquivo de fonte (woff2, woff ou ttf) e servido de um domínio diferente do site (CDN, subdominio ou proxy) sem o cabeçalho Access-Control-Allow-Origin. O navegador bloqueia a fonte por origem cruzada e o texto cai numa fonte de fallback, mesmo a fonte existindo e respondendo 200.

Atenção

Como corrigir a Conditional Logic que não funciona no ACF PRO

A Conditional Logic do ACF PRO que não funciona quase sempre vem do campo de gatilho que não guarda um valor comparável (Repeater, Group, Mensagem) ou do JavaScript do ACF que não carregou na tela. A lógica condicional só controla a exibição no editor, não impede que o valor oculto seja salvo ou exibido no frontend.

Atenção

Como corrigir o Page Title que não oculta no Astra Pro com Elementor

No Astra com Elementor, o titulo da página não oculta quando a opção por página e sobrescrita por um ajuste global do Personalizar, quando o template do Elementor não e o esperado, ou quando o CSS antigo em cache continua exibindo o cabeçalho. A visibilidade do titulo no Astra e definida em camadas, e a camada errada vence.

Setores

Extensões

Integrações

Como corrigir o Flexible Content que não salva layouts no ACF PRO

O que é o Flexible Content que não salva no ACF PRO?

Como identificar

Como prevenir

Causa

Como resolver

Perguntas frequentes

Itens relacionados

Como corrigir o erro de cores no Global Color Palette do Astra Pro no WordPress

Como corrigir o erro de JavaScript no JetSmartFilters no WordPress

Como corrigir o Modal Popup do Ultimate Addons que não abre no WordPress

Como corrigir o erro de CORS de fontes no Elementor

Como corrigir a Conditional Logic que não funciona no ACF PRO

Como corrigir o Page Title que não oculta no Astra Pro com Elementor

Setores

Extensões

Integrações

Extensões

Hero Sections

Seções de CTA

Login

Blog

Cabeçalhos

Seções de FAQ

Cadastro

Blog individual

Rodapés

Seções de contato

Seções de preços

Faixas

Portfólio

Seções de equipe

Números

Logotipos