Entendendo como configurar campos de título e conteúdo no WordPress
A maioria dos plugins e temas que eu já manipulei ao longo dos anos expõe campos de título e conteúdo de formas diferentes. Às vezes é simples, às vezes é uma dor de cabeça. Vou explicar direto o que isso significa na prática, sem rodeio. Título e conteúdo são opções de configurações que determinam quais campos aparecem em uma entrada do seu site — seja um post padrão, uma página, ou um custom post type que você criou. Isso não é algo exclusivo do WordPress puro; quase qualquer CMS ou construtor de páginas segue essa lógica básica.
Onde você encontra essas opções
No editor clássico do WordPress, título e conteúdo já vêm habilitados por padrão em posts e páginas. Se você está usando o Gutenberg, esses campos aparecem automaticamente no topo do bloco de artigo. O problema começa quando você trabalha com custom post types ou builders como Elementor, Divi ou JetEngine. Quando criei meu primeiro custom post type com suporte limitado, esqueci de adicionar supports => ['title', 'editor'] na hora de registrar. O resultado? Um post que não tinha campo de título nem de conteúdo. Levei uns dez minutos pra entender o que tinha errado. Basta verificar no código de registro se o argumento supports está presente e contém ambos os valores.
Em plugins de campos personalizados como Advanced Custom Fields ou Meta Box, o título e o conteúdo precisam ser declarados explicitamente. Se você não fizer isso, os campos nativos do WordPress simplesmente somem da tela de edição. Já vi gente reclamando disso nos fóruns achando que era um bug. Não é. É configuração.
Edge case que todo mundo ignora
Aqui vai algo que não ensinam em lugar nenhum: quando você desativa o conteúdo (editor) de um custom post type mas mantém o título, o WordPress ainda reserva espaço para o conteúdo no banco de dados. Isso significa que cada registro desse post type vai ter uma coluna post_content existindo com valor vazio ou com o conteúdo padrão. Em um site com milhares de registros, isso pode acumular megabytes desnecessários no banco. A solução? Se você realmente não precisa de conteúdo nesse tipo de post, remova completamente o suporte. Use supports => ['title'] ao registrar. Simples assim. Se precisar de campos extras, use meta boxes ou campos personalizados — não force o editor a existir só porque o post type padrão sempre teve.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Como verificar o que está ativo no seu tema
Se você quer saber quais opções de título e conteúdo estão habilitadas em algum post type específico, dá pra fazer sem plugin. Abra o arquivo functions.php do seu tema ou do plugin de funcionalidades e busque por register_post_type. Dentro desse registro, olhe o array supports. Se ele existir, os campos estarão disponíveis no admin. Se não existir, o WordPress herda os valores padrão do post type, que incluem título e editor por padrão. Outra forma rápida: acesse o admin, abra a tela de edição de qualquer item do seu post type e veja se os campos aparecem. Se não aparecerem, verifique também se algum plugin está removendo suporte via remove_post_type_support. Esse é outro cenário comum — algum plugin desativa o editor e você fica sem entender por quê.
Plugins que gerenciam essas opções
Se você não quer mexer com código, existem soluções prontas. O Custom Post Type UI permite criar e editar campos visuais sem tocar em PHP. O ACF oferece a opção de ativar ou desativar título e conteúdo durante a criação de campos. O JetEngine (para Elementor) tem controles finos de exatamente quais campos aparecem em cada formulário de edição. Nenhum desses é perfeito. O CPT UI é bom mas limita a granularidade — você não consegue desativar só o conteúdo e manter o título dinamicamente dependendo da categoria. O ACF é mais flexível mas cobra licença para recursos avançados. O JetEngine exige Elementor Pro, então já é um custo duplo.
Performance e boas práticas
Ter títulos e conteúdos habilitados onde não são necessários tem um impacto real. Cada campo extra no editor carrega JavaScript adicional na admin area. Em sites com muitos usuários editando simultaneamente, isso gera lentidão perceptível — especialmente em servidores compartilhados. Um cliente meu tinha um post type de "agenda de eventos" com mais de 8 mil registros e o editor estava carregando devagar porque o conteúdo rich text estava habilitado mesmo sendo irrelevante para o uso. Removi o suporte ao editor e o tempo de carga da lista de administração caiu de cerca de 4 segundos para menos de 1 segundo. Se seu post type só precisa de um título e talvez um campo de data ou imagem, desative o editor. Use supports => ['title', 'thumbnail'] e salve o resto em meta fields. O resultado é um admin mais leve e um banco de dados mais organizado.
Resumo prático
Título e conteúdo são opções configuráveis no WordPress que determinam quais campos aparecem na tela de edição. Elas podem ser ativadas ou desativadas manualmente no registro do custom post type, e plugins de terceiros oferecem interfaces visuais para o mesmo propósito. A decisão de manter ou remover esses campos deve ser baseada na necessidade real do tipo de conteúdo — não no padrão do sistema. Manter campos desnecessários gera overhead no banco e na interface admin. Remover campos essenciais gera frustração. Teste sempre após fazer alterações, verificando tanto a exibição no admin quanto a persistência dos dados no banco.
