Como corrigir os Custom Post Types do JetEngine que não aparecem no frontend
O que é CPT JetEngine que não aparece?
JetEngine registra cada Custom Post Type (CPT) chamando a função register_post_type do WordPress por baixo dos panos. Quando você cria o post type pelo painel mas os itens não abrem no site (single retorna 404, ou o arquivo do post type não existe), o problema está nos argumentos que o JetEngine passou para essa função ou nas regras de reescrita (rewrite rules) do WordPress, que ficaram em cache desatualizado depois de criar ou renomear o post type.
Como identificar
- Ao abrir um item do CPT no site aparece a mensagem ‘Página não encontrada’ ou erro 404, mesmo com o post publicado e visível no painel.
- A URL do arquivo do post type (por exemplo /imoveis/) retorna 404 ou cai na home, em vez de listar os itens.
- O Listing Grid montado no Elementor exibe os itens corretamente, mas clicar no item leva a uma página 404.
- No menu do JetEngine em JetEngine -> Post Types o post type aparece, mas a coluna de visibilidade ou o link ‘Ver’ não abre nada no frontend.
Como prevenir
- Ao criar um post type novo, já marque Public, Has archive e Has single page antes de cadastrar conteúdo, para nunca publicar itens sem URL no frontend.
- Sempre regrave os permalinks em Configurações -> Links permanentes logo após criar ou renomear um post type ou seu slug de reescrita.
- Reserve slugs de reescrita exclusivos para os CPTs e evite reaproveitar o slug de páginas institucionais como /serviços/ ou /produtos/.
- Depois de migrar o site ou trocar de host, abra Links permanentes e salve para reconstruir as regras de reescrita dos post types do JetEngine.
Causa
- A opção Public está desmarcada nas configurações do Post Type no JetEngine. Sem ela o WordPress define publicly_queryable como false e nenhuma URL do single ou do arquivo é resolvida no frontend.
- A opção Has archive está desligada, então a página de arquivo do post type (a listagem em /slug/) simplesmente não é registrada e retorna 404.
- As regras de reescrita (rewrite rules) ficaram em cache antigo: o post type foi criado ou teve o slug alterado, mas os permalinks não foram regravados, então o WordPress ainda não conhece a rota nova.
- O slug de reescrita do post type colide com o slug de uma página, post ou categoria já existente (por exemplo um CPT com slug serviços e uma página /serviços/), e o WordPress resolve a URL para a página, não para o CPT.
- A opção Has single page está desligada no post type, então os itens individuais não têm URL própria e qualquer link para o single cai em 404.
Como resolver
- Abra as configurações do Post Type no JetEngine: No painel do WordPress acesse o menu do JetEngine e abra o post type que não aparece para revisar as opções de visibilidade que vão para o register_post_type.
JetEngine -> Post Types -> (clique no post type) -> aba Advanced settings - Ative Public, Has archive e Has single page: Nas configurações avançadas do post type marque as três opções que liberam a navegação no frontend e salve. Public libera as queries públicas, Has archive cria a página de listagem e Has single page dá URL própria a cada item.
Public: Yes Has archive: Yes Has single page: Yes - Confira que o slug de reescrita é único: Ainda nas configurações avançadas verifique o campo Rewrite slug do post type e garanta que ele não é igual ao slug de nenhuma página, post ou categoria existente. Se houver colisão, troque o slug do post type por um valor exclusivo e salve.
Rewrite slug: imoveis-cpt - Regrave os permalinks para limpar as regras de reescrita: Depois de salvar o post type vá às configurações de Links permanentes e clique em Salvar alterações sem mudar nada. Isso força o WordPress a executar flush_rewrite_rules e registrar a rota nova do CPT.
Configurações -> Links permanentes -> Salvar alterações - Limpe o cache e teste a URL do item: Limpe qualquer cache de página (plugin de cache, CDN ou host) e abra novamente um item publicado do post type e a URL do arquivo. O single e o arquivo devem carregar sem 404.
https://seusite.com.br/imoveis-cpt/
add_action( 'init', function () {
// Diagnóstico: confirme como o JetEngine registrou o CPT.
// Se 'public' ou 'has_archive' vierem false, a correção é na UI (passos 2).
$pt = get_post_type_object( 'imoveis' ); // troque pelo slug do seu CPT
if ( $pt ) {
error_log( 'public: ' . var_export( $pt->public, true ) );
error_log( 'has_archive: ' . var_export( $pt->has_archive, true ) );
error_log( 'publicly_queryable: ' . var_export( $pt->publicly_queryable, true ) );
error_log( 'rewrite slug: ' . var_export( $pt->rewrite['slug'] ?? null, true ) );
}
}, 99 );Perguntas frequentes
Por que meu CPT do JetEngine retorna 404 só no frontend
Preciso regravar os permalinks toda vez que crio um post type
Qual a diferença entre Has archive e Has single page no JetEngine
O Listing Grid mostra os itens mas o clique leva a 404, por quê
Meu CPT cai numa página existente em vez do conteúdo certo
Mudei o slug do post type e tudo quebrou, como recuperar
Onde fica a opção Public nas configurações do JetEngine
Como corrigir o widget Data Table que não carrega dados no Essential Addons
O Essential Addons Data Table não carrega dados quando o widget está desativado em Essential Addons > Elements, quando a integração externa (Google Sheets, TablePress ou Ninja Tables) está mal configurada, ou quando o cache serve uma versão antiga da tabela sem o conteúdo.
Como corrigir o Maps Listing do JetEngine que não exibe marcadores no WordPress
O JetEngine não exibe marcadores no Maps Listing quando falta uma API key válida do provedor de mapas, quando o campo de endereço não tem coordenadas geocodificadas, ou quando a fonte de endereço do widget aponta para o campo errado. Sem latitude e longitude armazenadas, o mapa carrega mas nenhum pino é desenhado.
Como corrigir o conflito entre Elementor e WP Rocket no WordPress
O conflito entre Elementor e WP Rocket aparece quando a otimização de JavaScript e CSS do cache atinge os arquivos do construtor: o editor do Elementor não abre, o layout quebra no frontend ou widgets e icones somem ao limpar o cache. A causa não e bug de nenhum dos dois, e otimização agressiva sobre o que o Elementor precisa.
Como corrigir o Gallery Field do ACF PRO quando o lightbox não funciona
O lightbox do Gallery Field do ACF PRO não funciona porque o ACF não inclui lightbox próprio: ele só entrega os dados das imagens, e o efeito de ampliar ao clicar depende de o seu template renderizar o link para a imagem cheia com o atributo que a biblioteca de lightbox do tema ou plugin reconhece.
Como corrigir custom fields do ACF PRO que não exibem em cursos do Tutor LMS no WordPress
Os custom fields do ACF PRO não aparecem em cursos do Tutor LMS quando a regra de localizacao do grupo de campos não casa com o tipo de post courses, quando o template do curso chama os campos fora do loop sem informar o ID do curso, ou quando o nome do campo no código não bate com o registrado no ACF.
Como corrigir Elementor que não salva alterações
O Elementor que não salva alterações deixa o botão Atualizar girando para sempre ou retorna erro, e o trabalho se perde ao recarregar. A causa quase sempre é o max_input_vars do PHP baixo demais para a página, ou uma regra de mod_security/WAF bloqueando a requisição de salvamento (admin-ajax.php).
