Imagine: lançou um portal corporativo em WordPress, criou um custom post type chamado «Equipment» e preencheu-o com documentação interna. Uma semana depois, descobre que todas essas páginas estão a ser indexadas pelos motores de busca e visíveis para qualquer pessoa. O acesso deveria ser limitado a funcionários autorizados, mas o seu está completamente aberto.

As ferramentas nativas do WordPress não permitem restringir seletivamente um custom post type específico a utilizadores não registados. Existem funções e capacidades, mas a ligação «os visitantes não podem ver o CPT X» não está disponível de raiz. A solução consiste em três componentes: registo do CPT, configuração de funções e um plugin de restrição de leitura. O quarto componente (opcional) é o login social, para que os funcionários não tenham de introduzir uma palavra-passe sempre.

Abaixo encontra um detalhe passo a passo de cada componente, com plugins e configurações específicos. Todas as ferramentas são gratuitas, estão disponíveis no diretório oficial do WordPress.org e não exigem programação, embora uma abordagem puramente baseada em código seja abordada no final para quem quiser evitar plugins.

💡 Visão geral rápida:

• Registar um custom post type através do Custom Post Type UI sem escrever uma única linha de código
• Criar uma função personalizada no PublishPress Capabilities e atribuí-la aos funcionários
• Restringir o acesso ao CPT a visitantes usando o plugin WP Access Areas: os visitantes não autorizados são redirecionados para a página de login
• Opcionalmente, ativar o login social através do Super Socializer para um início de sessão sem palavra-passe com a conta Google

Passo 1: Registar um custom post type

A primeira etapa, e a mais simples, é criar o próprio CPT. Não precisa de mexer no functions.php para isso: o plugin Custom Post Type UI no WordPress.org fornece uma interface gráfica para registar quaisquer post types e taxonomias.

A instalação é a padrão: «Plugins → Adicionar novo», pesquisar pelo nome, ativar. Após a ativação, aparece um novo item de menu na barra lateral: «CPT UI → Add/Edit Post Types». Preencha os campos: slug (por exemplo, equipment), nomes no plural e singular, etiquetas e clique em «Add Post Type».

O plugin chama o register_post_type() com os parâmetros corretos automaticamente. Não é necessário código manual: obtém um post type totalmente funcional com suporte de editor, arquivos e API REST. Se mais tarde precisar de mover o registo para o functions.php, o CPT UI exibe o código PHP gerado no separador «Tools».

Durante o registo, preste atenção a duas opções críticas relacionadas com a segurança. No bloco de «Settings» do CPT UI, existe um indicador «Publicly Queryable» que determina se os artigos podem ser abertos através de links diretos. O valor predefinido é verdadeiro e, mesmo depois de restringir a leitura através de um plugin, deve deixar esta opção ativada; caso contrário, o WordPress devolverá um erro 404 em vez de redirecionar para a página de login, e os utilizadores não perceberão o que aconteceu. O segundo parâmetro, «Has Archive», ativa uma página de arquivo que lista todos os artigos do CPT. Se não precisar de um arquivo, desative-o para que os motores de busca não indexem uma página de serviço com pré-visualizações de documentos restritos.

Passo 2: Criar uma função personalizada

Simplesmente restringir o acesso ao CPT a visitantes não é suficiente: precisa de um perfil que tenha acesso. Por predefinição, o WordPress oferece um conjunto fixo: Administrador, Editor, Autor, Colaborador, Subscritor. Vamos criar um novo perfil usando o plugin PublishPress Capabilities (anteriormente chamado Capability Manager Enhanced, mesmo slug, mesma funcionalidade, apenas mudou de nome).

Após a ativação, vá a «Capabilities → Roles». No lado direito do ecrã, encontrará o bloco «Create New Role»:

Introduza um nome (por exemplo, «Equipment Reader»), selecione um perfil base para clonar (o de Subscritor é o melhor, pois tem permissões mínimas) e clique em «Create». O novo perfil passa a existir e pode preenchê-lo com capacidades. Para ler um CPT, a combinação padrão de read + read_equipment (a capacidade registada pelo CPT UI) é suficiente.

Atribua o perfil criado aos colaboradores que precisam de aceder ao conteúdo restrito. Depois disto, pode desativar o plugin: os perfis e capacidades permanecem na base de dados do WordPress e não dependem de o PublishPress Capabilities estar ativo.

Passo 3: Restringir o acesso de leitura ao CPT

Este é o passo fundamental. O plugin WP Access Areas permite definir com precisão quem pode ler, editar e comentar publicações de cada tipo, até ao nível de páginas individuais. Tem um número modesto de 400 instalações ativas e não recebe atualizações significativas há algum tempo, mas para a tarefa de «restringir o CPT a visitantes», funciona de forma previsível e sem conflitos.

Após a instalação, vá a «Settings → Access Areas». Na secção «Default Behaviour», selecione:

«If not logged in, redirect to login. Otherwise redirect to the fallback page.»

Esta configuração envia os utilizadores não autorizados para o wp-login.php quando tentam abrir qualquer página protegida do CPT.

A seguir, há uma tabela com todos os tipos de publicações registados. Para o seu CPT, na coluna «Reading», selecione «Logged in Users» no menu suspenso. É tudo: a partir deste momento, qualquer visitante que siga um link direto para uma página do CPT é redirecionado para o formulário de autenticação.

Nota importante: as configurações feitas através da tabela aplicam-se apenas a novas publicações. Para páginas já criadas, precisa de definir manualmente as permissões na barra lateral do editor, onde aparece um bloco «Access Areas». Após a configuração, não se esqueça de verificar o resultado no modo de navegação anónima do seu browser: abrir um link direto para uma página protegida do CPT deve mostrar-lhe o wp-login.php, e não o conteúdo.

Alternativas ao WP Access Areas se precisar de uma solução com manutenção mais ativa: PublishPress Permissions (a versão gratuita cobre CPT e funções) ou ContentGate (um plugin leve com regras baseadas no estado de início de sessão e nas funções).

Passo 4: Início de sessão social (opcional)

Introduzir constantemente um nome de utilizador e uma palavra-passe num portal corporativo gera atrito desnecessário. A solução lógica: início de sessão com um clique através da conta Google. O plugin Super Socializer trata desta tarefa, com mais de 20.000 instalações ativas e suporte para Google, Facebook, X (Twitter) e uma dúzia de outros fornecedores.

Após a ativação, vá a «Super Socializer → Social Login»:

Configurações básicas: ative a caixa de seleção «Disable user registration via social networks». Isto é importante para que apenas as contas existentes possam iniciar sessão através das redes sociais, em vez de criar novas. Depois, selecione o fornecedor (Google) e introduza o Client ID e o Client Secret. Onde os obter:

• Abra a Google Cloud Console, crie um projeto (ou selecione um existente)
• Na secção «APIs & Services → Credentials», clique em «Create Credentials → OAuth client ID»
• O tipo de aplicação é Web application; em Authorized redirect URIs, cole o URL de callback das definições do Super Socializer
• Guarde para obter o seu Client ID e Client Secret

Copie as chaves para os campos do plugin:

Ponto crítico: o campo Authorized redirect URIs não deve ter uma barra final, ou obterá um erro redirect_uri_mismatch. Depois de guardar, aparece um botão «Sign in with Google» na página de início de sessão.

Importante: a versão original deste artigo (2020) descrevia a integração com o Google+, que foi descontinuado em abril de 2019. O Super Socializer moderno utiliza o protocolo padrão Google OAuth 2.0 através dos Google Identity Services. A interface da Google Cloud Console foi atualizada desde então, mas a lógica dos passos (projeto → Credentials → OAuth client ID → redirect URI) mantém-se a mesma.

Abordagem alternativa: tudo em código

Se plugins adicionais forem indesejáveis, a tarefa pode ser resolvida no functions.php do tema ou de um tema filho. O código regista o CPT, cria um perfil e liga uma verificação de autorização ao modelo:

1
// Registering a custom post type
2
function register_equipment_cpt() {
3
    register_post_type('equipment', [
4
        'labels'      => ['name' => 'Equipment', 'singular_name' => 'Equipment'],
5
        'public'      => true,
6
        'has_archive' => true,
7
        'supports'    => ['title', 'editor', 'thumbnail'],
8
        'capability_type' => 'equipment',
9
        'map_meta_cap' => true,
10
    ]);
11
}
12
add_action('init', 'register_equipment_cpt');
13
 
14
// Creating a role on theme activation
15
function add_equipment_reader_role() {
16
    add_role('equipment_reader', 'Equipment Reader', ['read' => true, 'read_equipment' => true]);
17
}
18
add_action('after_switch_theme', 'add_equipment_reader_role');
19
 
20
// Redirecting guests from CPT to login page
21
function restrict_equipment_to_logged_in() {
22
    if (is_singular('equipment') && !is_user_logged_in()) {
23
        wp_redirect(wp_login_url(get_permalink()));
24
        exit;
25
    }
26
}
27
add_action('template_redirect', 'restrict_equipment_to_logged_in');

O que este código faz: o primeiro bloco regista o CPT equipment com o seu próprio tipo de capacidade (capability_type). O segundo bloco cria o perfil Equipment Reader com permissões para ler este CPT quando o tema é ativado. O terceiro bloco verifica a autorização no gancho template_redirect e envia os visitantes para wp-login.php.

A vantagem da abordagem por código: zero plugins adicionais, controlo total. A desvantagem: o início de sessão social continuará a exigir um plugin (escrever integração OAuth manualmente é demorado e inseguro), e cada alteração aos perfis implica editar código.

⁉️🤔 Perguntas frequentes

Posso restringir um CPT sem plugins, apenas através do functions.php?

Sim. A combinação de register_post_type() + add_role() + o gancho template_redirect com uma verificação is_user_logged_in() é uma solução totalmente funcional. O código é fornecido na secção acima. O início de sessão social sem um plugin é significativamente mais difícil de implementar: a integração OAuth manual exige o tratamento de tokens, estado e segurança.

Porquê o WP Access Areas em vez de um plugin mais recente como o ContentGate?

O WP Access Areas é uma ferramenta minimalista para uma tarefa específica: «restringir um tipo de publicação a visitantes». Não traz consigo um construtor de regras, editores visuais ou subscrições. Se precisar de lógica mais complexa (por exemplo, diferentes níveis de acesso para diferentes perfis no mesmo CPT), utilize o ContentGate ou o PublishPress Permissions, que são ativamente atualizados. Para o cenário básico deste guia, o WP Access Areas é suficiente.

O que devo fazer se os visitantes ainda conseguirem ver as páginas do CPT após a configuração?

Três causas típicas. Primeira: a definição «Logged in Users» na tabela do WP Access Areas só se aplica a novos artigos; para páginas existentes, precisa de definir as permissões manualmente através da barra lateral do editor. Segunda: um plugin de cache está a servir uma versão em cache da página aos visitantes; limpe a cache e configure exclusões para o CPT protegido. Terceira: o CPT está registado com 'publicly_queryable' => true e o slug entra em conflito com uma página pública; verifique colisões.

Posso usar o Super Socializer apenas para início de sessão, sem partilha e comentários?

Sim, os módulos do plugin são independentes. No separador «Social Sharing», desmarque todas as caixas e os botões «Share» desaparecerão. No separador «Social Commenting», desative a integração. Deixe apenas «Social Login» com os fornecedores de que precisa. O plugin é leve e desativar módulos desnecessários não afeta o desempenho.

É seguro desativar o PublishPress Capabilities depois de criar um perfil?

Sim. Os perfis e capacidades do WordPress são armazenados na tabela wp_options (a opção wp_user_roles) e não dependem do plugin que os criou. Após desativar o PublishPress Capabilities, todos os perfis criados e permissões concedidas são preservados. Pode reativar o plugin se precisar de modificar permissões mais tarde.

Deve escrever código ou manter-se nos plugins

A escolha entre plugins e o functions.php resume-se a dois fatores: o número de CPTs a proteger e a frequência com que as permissões mudam.

Se tiver apenas um CPT (como o exemplo do equipamento), os perfis forem estáveis e estiver disposto a escrever 30 linhas de código uma vez, a abordagem do functions.php é mais limpa: não gera plugins, não depende de atualizações de terceiros e é completamente transparente. Pode manter o Super Socializer para o início de sessão social, uma vez que resolve uma tarefa restrita e não entra em conflito com código personalizado.

Se tiver vários CPTs, as permissões forem revistas com frequência ou o site for gerido por alguém que não é programador, opte pela combinação de plugins. CPT UI + PublishPress Capabilities + WP Access Areas (ou ContentGate) podem ser configurados a partir do painel de administração em 15 minutos sem tocar em código. Além disso, o PublishPress Capabilities faz automaticamente cópias de segurança dos perfis a cada alteração, permitindo o retrocesso em dois cliques.

Em qualquer cenário, siga o princípio: uma ferramenta para uma tarefa. Não instale uma solução tudo-em-um poderosa para uma única caixa de verificação e não reinvente a roda se um plugin existente faz exatamente o mesmo de forma mais rápida e segura.

O controlo de versões merece uma consideração à parte. O código do functions.php reside no repositório do tema, as alterações são rastreadas através do Git e, ao migrar o site, os perfis são automaticamente recriados no gancho after_switch_theme. A abordagem por plugins não oferece esta transparência: os perfis são armazenados na base de dados e, ao implementar uma cópia de testes ou transferir para um novo domínio, precisam de ser recriados manualmente ou através de um script de migração. Este fator torna-se frequentemente decisivo a favor do código para equipas que praticam CI/CD e implementação baseada em Git.