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

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.

Erros relacionados

- [Como corrigir conflitos entre o Elementor e plugins de cache](https://full.services/wp-fixer/corrigir-conflito-elementor-cache/)
- [Como corrigir o erro de conexão entre JetEngine e Elementor](https://full.services/wp-fixer/corrigir-conexao-jetengine-elementor/)
- [Como corrigir o Listing Grid vazio no JetEngine](https://full.services/wp-fixer/corrigir-listing-grid-vazio-jetengine/)

## 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

1. 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
```

2. 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
```

3. 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
```

4. 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
```

5. 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
```


## Código

```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.

**Fonte:** [Crocoblock — Base de Conhecimento do JetEngine (Dynamic Visibility)](https://crocoblock.com/knowledge-base/)