JetEngine Dynamic Visibility cache: corrigir no WordPress

Tipo Page Builders

Nome do erro Dynamic Visibility do JetEngine não funciona com cache EN: JetEngine Dynamic Visibility not working with cache

Severidade Atenção

Descrição O JetEngine Dynamic Visibility e o cache entram em conflito porque a visibilidade dinâmica e avaliada no servidor a cada carregamento, enquanto o cache de página inteira congela a primeira versão do HTML e serve a mesma copia a todos os visitantes, ignorando o papel, o login e as condicoes de cada um.

O que é Dynamic Visibility do JetEngine com cache?

O Dynamic Visibility do JetEngine controla, no servidor, se um widget ou bloco aparece ou some conforme condicoes como papel do usuário, usuário logado ou deslogado, valor de um campo meta, variavel de query, data ou hora. O JetEngine avalia essas condicoes em PHP a cada requisicao e decide se imprime ou não a marcacao do elemento no HTML final. Por isso a visibilidade so e correta quando o PHP roda de verdade para aquele visitante específico.

O conflito com cache surge quando um plugin de cache de página inteira, como WP Rocket, LiteSpeed Cache ou WP Super Cache, ou um cache de borda como o Cloudflare, salva o HTML já renderizado de uma visita e o entrega aos visitantes seguintes sem executar o PHP. A condicao avaliada uma única vez fica congelada na copia em cache: se a página foi cacheada para um visitante deslogado, todos passam a ver a versão do deslogado, mesmo logados. O elemento que deveria aparecer ou sumir conforme cada usuário passa a se comportar igual para todo mundo, até o cache daquela URL ser limpo.

Como identificar

Um elemento controlado por Dynamic Visibility aparece para quem não deveria ve-lo, ou some para quem deveria, sem padrão claro entre visitantes.
A visibilidade fica correta logo após limpar o cache, mas volta a ficar errada nas proximas visitas a mesma URL.
Condicoes baseadas em usuário logado e deslogado mostram sempre a mesma versão da página para os dois estados.
Blocos condicionados por papel do usuário (administrador, assinante, cliente) exibem o conteúdo do papel da primeira visita cacheada para todos os demais.
Condicoes por data ou hora continuam mostrando o conteúdo de um momento anterior porque a página foi cacheada antes da virada do horario.

Antes de começar: Antes de mexer em regras de cache do plugin ou do Cloudflare em producao, anote a configuração atual e, se possível, teste em staging. Excluir páginas do cache aumenta o uso de PHP e pode pesar no servidor, entao exclua apenas as rotas com conteúdo realmente dinâmico.

Como prevenir

Reserve o Dynamic Visibility por usuário, papel ou login para páginas já excluidas do cache de página inteira, mantendo o restante do site cacheado para desempenho.
Mantenha o cache desativado para usuários logados sempre que houver conteúdo personalizado por papel, evitando servir a mesma copia a estados de login diferentes.
Documente quais URLs tem conteúdo dinâmico e mantenha-as na lista de exclusão de cache do plugin e do Cloudflare para não serem cacheadas por engano em uma futura mudanca.
Para condicoes por data ou hora, prefira conteúdo carregado via requisicao a cada visita em vez de depender do HTML estático, ou alinhe o tempo de vida do cache a virada esperada.

Causa

O cache de página inteira (WP Rocket, LiteSpeed Cache, WP Super Cache) salva o HTML já renderizado de uma visita e o serve aos demais sem rodar o PHP, congelando a condicao do Dynamic Visibility avaliada uma única vez.
O cache esta ativo para usuários logados, entao a página cacheada para um papel ou para o deslogado e entregue também aos logados, quebrando condicoes por papel e por estado de login.
Um cache de borda do Cloudflare (Cache Everything ou regra de página) guarda o HTML antes do WordPress, de modo que o PHP do JetEngine nem chega a ser executado para o visitante seguinte.
Condicoes por variavel de query, como UTM ou parametro de URL, são ignoradas porque o cache serve a mesma copia independente da query string, a menos que essa variavel seja incluida na chave de cache.
Condicoes por data ou hora ficam defasadas porque o HTML foi gerado e cacheado antes da virada do horario e o cache so expira após o tempo de vida configurado.

Como resolver

Confirme que o cache e a causa: Abra a página em uma janela anonima e em uma sessao logada e compare. Se a visibilidade ficar correta logo após limpar o cache e voltar a falhar depois, o conflito e com o cache de página, não com a configuração da condicao no JetEngine.
```
Painel WP -> abra o plugin de cache -> Limpar cache (Clear cache)
Recarregue a página logado e anonimo e compare a visibilidade do elemento
```
Desative o cache para usuários logados: Se as condicoes dependem de papel ou de login, garanta que páginas para usuários logados não sejam cacheadas. No WP Rocket isso e o padrão recomendado quando ha conteúdo por usuário; no LiteSpeed Cache existe a opção equivalente.
```
WP Rocket -> Cache -> deixe 'Cache para usuários logados' (User Cache) DESmarcado
LiteSpeed Cache -> Cache -> Cache Logged-in Users -> OFF
```
Exclua a URL da página do cache: Para condicoes por usuário, query string, data ou hora, adicione a URL da página (ou um padrão com curinga) na lista de URLs que nunca devem ser cacheadas, forçando o PHP do JetEngine a rodar a cada visita.
```
WP Rocket -> Avancado (Advanced Rules) -> Never Cache URL(s) -> adicione o caminho da página
Exemplo de padrão com curinga: /minha-área(.*)
LiteSpeed Cache -> Cache -> Excludes -> Do Not Cache URIs -> adicione o caminho
```
Ajuste o cache de borda do Cloudflare: Se o Cloudflare estiver com Cache Everything ou uma Page Rule cacheando HTML, crie uma regra para não cachear a URL com conteúdo dinâmico, ou desative o Cache Everything nessa rota, para o WordPress voltar a executar o JetEngine.
```
Cloudflare -> Rules -> crie uma regra Bypass Cache para o caminho da página dinâmica
Ou em Cache Rules defina 'Bypass cache' quando o URI casar com a página
```
Limpe todos os caches e revalide: Após as exclusoes, limpe o cache do plugin, do servidor e do Cloudflare para descartar copias antigas e teste novamente em sessoes diferentes (logado, deslogado, papeis distintos) até a visibilidade casar com cada condicao.
```
Limpe o cache do plugin (WP Rocket -> Clear cache / LiteSpeed -> Purge All)
Cloudflare -> Caching -> Purge Everything
Teste a página como deslogado, logado e em cada papel relevante
```

PHP

<?php
/**
 * Forca o cache do WP Rocket a NUNCA armazenar a pagina atual
 * quando ela contem conteudo do JetEngine Dynamic Visibility por usuario.
 * Coloque em um plugin de site ou no functions.php do tema filho.
 */
add_filter( 'rocket_cache_reject_uri', 'full_jetengine_dv_reject_cache' );
function full_jetengine_dv_reject_cache( $uris ) {
    // Caminhos (sem dominio) que dependem de Dynamic Visibility por usuario.
    $uris[] = '/minha-area(.*)';
    $uris[] = '/area-do-cliente(.*)';
    return $uris;
}

// Garante que paginas para usuarios logados nao sejam cacheadas.
add_filter( 'rocket_cache_mandatory_cookies', '__return_empty_array' );

Perguntas frequentes

Por que o Dynamic Visibility do JetEngine funciona até o cache encher

Porque a condicao e avaliada no servidor a cada carregamento, mas o cache de página salva o primeiro HTML gerado e o serve a todos sem rodar o PHP. A visibilidade fica correta logo após limpar o cache e volta a falhar quando a copia cacheada e reutilizada.

Como faço o Dynamic Visibility funcionar com WP Rocket

Desative o cache para usuários logados e adicione a URL da página dinâmica em Never Cache URLs, dentro das regras avancadas do WP Rocket. Assim o PHP do JetEngine roda a cada visita e avalia a condicao para o usuário correto.

Preciso excluir a página inteira do cache

Para condicoes por usuário, papel, query string, data ou hora, sim, a forma mais segura e excluir a URL do cache. Para o resto do site você mantem o cache ligado, excluindo apenas as rotas com conteúdo realmente dinâmico para não perder desempenho.

O Cloudflare também quebra o Dynamic Visibility

Pode quebrar quando esta com Cache Everything ou uma Page Rule cacheando o HTML, porque o WordPress nem chega a executar o JetEngine. Crie uma regra de Bypass Cache para a URL dinâmica e faça Purge Everything após a mudanca.

Condicoes por papel de usuário são seguras de esconder conteúdo com cache

Não confie no cache para esconder conteúdo sensivel por papel. Com o cache de página, a copia gerada para um estado pode vazar para outro. Para conteúdo restrito, exclua a página do cache e valide a permissão no servidor a cada visita.

Por que a condicao por data ou hora mostra o conteúdo errado

Porque a página foi gerada e cacheada antes da virada do horario, e o cache so expira após o tempo de vida configurado. Exclua essa página do cache ou alinhe o tempo de vida do cache ao momento exato em que o conteúdo deve mudar.

O Dynamic Visibility usa JavaScript ou PHP

O Dynamic Visibility do JetEngine e avaliado no servidor em PHP, decidindo se imprime ou não a marcacao do elemento no HTML. Por isso depende do PHP rodar de verdade naquela visita, o que o cache de página inteira impede ao servir HTML pronto.

Excluir páginas do cache deixa o site mais lento

As páginas excluidas passam a rodar o PHP a cada visita, o que consome mais recursos do que servir HTML cacheado. Por isso exclua apenas as rotas com conteúdo dinâmico real e mantenha o cache ligado no restante do site.

Grave

Como corrigir layout quebrado no mobile após atualizar o Elementor

O layout mobile do Elementor quebra depois de atualizar quando os novos breakpoints do plugin deslocam onde os estilos responsivos são aplicados e o CSS antigo de cada página não e regenerado. No desktop o site parece normal, mas no celular o conteúdo aparece sobreposto, com colunas empilhadas erradas ou fora de largura.

Crítico

Como corrigir erro 500 ao editar com Elementor

O erro 500 ao editar com Elementor é um Internal Server Error que derruba o editor ao abrir ou salvar a página, geralmente com tela branca ou aviso de erro. A causa quase sempre é memória PHP esgotada, um limite de servidor estourado (max_input_vars/tempo) ou um conflito de plugin que dispara um erro fatal no PHP.

Atenção

Como corrigir os estilos conflitantes entre Happy Addons e Astra Pro no WordPress

O conflito de CSS entre Happy Addons e Astra Pro ocorre quando o CSS do tema vence o do widget por especificidade ou ordem de carregamento, deixando fonte, cor e espaçamento dos widgets do Happy Addons diferentes do que foi definido no Elementor.

Grave

Como corrigir Custom Fields que não exibem no frontend no ACF PRO

Quando os ACF custom fields não aparecem no frontend, o valor existe no banco mas o tema chama o campo de forma incorreta: nome errado, fora do Loop, sem post ID ou com Location Rules que não casam com a tela atual. A correção é alinhar a chamada the_field() ou get_field() ao contexto real do template.

Atenção

Como corrigir o erro de loop em Repeater aninhado no ACF PRO

O erro de loop em Repeater aninhado no ACF PRO acontece quando um have_rows de um Repeater filho e percorrido sem chamar the_row, ou quando o nome do sub campo não casa, gerando loop infinito com tela branca ou nenhuma linha exibida.

Informativo

Como corrigir o Color Picker que não aplica a cor no frontend no ACF PRO

O ACF color picker não aplica cor no frontend quando o template não imprime o valor do campo, quando o nome do campo está errado ou quando a transparência muda o retorno para RGBA e o código espera HEX. O Color Picker do ACF PRO guarda a cor, mas só aparece se o tema a imprimir no HTML ou no CSS.

Setores

Extensões

Integrações

Como corrigir o Dynamic Visibility do JetEngine que não funciona com cache no WordPress

O que é Dynamic Visibility do JetEngine com cache?

Como identificar

Como prevenir

Causa

Como resolver

Perguntas frequentes

Itens relacionados

Como corrigir layout quebrado no mobile após atualizar o Elementor

Como corrigir erro 500 ao editar com Elementor

Como corrigir os estilos conflitantes entre Happy Addons e Astra Pro no WordPress

Como corrigir Custom Fields que não exibem no frontend no ACF PRO

Como corrigir o erro de loop em Repeater aninhado no ACF PRO

Como corrigir o Color Picker que não aplica a cor no frontend no ACF PRO

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