Você entrega o site, o cliente pede acesso para publicar posts e, na semana seguinte, recebe uma ligação porque ele instalou um plugin de slider que quebrou o layout. Montar um painel para cliente WordPress é exatamente isso: dar a ele o que precisa para tocar o dia a dia sem que ele veja, ou possa mexer, no que não deveria. O problema quase nunca é o acesso em si, e sim o escopo dele.
Os três sintomas que aparecem antes do pedido
Na prática, a agência percebe que precisa de um painel restrito por três caminhos diferentes. O primeiro é o cliente que some do painel e passa a mandar tudo por WhatsApp, porque acha a tela confusa. O segundo é o cliente que mexe demais: instala plugin, troca tema, edita o functions.php e derruba o site. O terceiro é o mais silencioso: o cliente continua com login de administrador e você só descobre o risco quando algo acontece.
Nos três casos, a saída não é esconder o painel. É desenhar uma área do cliente WordPress que faça sentido para quem não é técnico. Antes de escolher a ferramenta, vale alinhar o que está dentro e fora do escopo, como em escopo de projeto WordPress: como filtrar pedidos do cliente.
Antes de restringir: a ordem de teste que evita perder o próprio acesso
Quase todo tutorial pula esta parte. Restringir menu é fácil; o difícil é não se trancar do lado de fora. Siga esta ordem, sem inverter:
- Crie um usuário de teste com o papel que você pretende entregar ao cliente.
- Faça login nesse usuário em uma janela anônima, mantendo o admin logado em outra.
- Aplique a restrição de menu e recarregue a janela do usuário de teste.
- Confirme que o admin continua vendo tudo na outra janela.
- Só então aplique a mesma configuração ao usuário real do cliente.
Se você aplicar direto no admin e a regra estiver errada, o caminho de volta costuma ser renomear a pasta de plugins ou editar o banco. Ou seja, um erro de cinco minutos vira uma tarde de recuperação. Ter um segundo administrador ativo antes de qualquer mudança é o seguro mais barato que existe.
As três saídas reais para montar um painel para cliente WordPress
Existem três caminhos concretos para montar um dashboard personalizado WordPress. Eles não são equivalentes: cada um sobrevive a um cenário diferente.
| Saída | Funciona bem quando | Quebra quando | Esforço por site |
|---|---|---|---|
| Plugin de painel | Um site, cliente único, prazo curto | Você repete em 10 sites com clientes diferentes | Baixo no primeiro, alto na repetição |
| Função no tema (child theme) | Você controla o tema e quer regra sob medida | O cliente troca de tema e a regra evapora | Médio, mas replicável por snippet |
| Papel de usuário ajustado | Você quer o mínimo de código e o máximo de previsibilidade | Precisa esconder menus nativos que o papel não cobre | Baixo e estável |
Na maioria dos casos de agência, a resposta é combinar papel ajustado com um snippet de menu. Plugin de painel resolve o primeiro cliente, mas vira dívida quando você tem dez sites para manter. O critério é simples: se a configuração vai ser repetida, ela precisa ser replicável sem depender de um plugin específico estar atualizado.
Passo a passo: papel de usuário ajustado
O WordPress já traz papéis prontos. Para a maioria dos clientes, Editor resolve: ele publica e edita posts e páginas, inclusive de outros autores, mas não mexe em plugins, temas, usuários ou configurações. Author é mais restrito: publica só o que é dele. A documentação oficial de papéis e capacidades está em Roles and Capabilities.
O problema é que Editor ainda vê menus que confundem: Comentários, Ferramentas, alguns itens de Aparência dependendo do tema. Por isso o ajuste fino vem depois, com um snippet no child theme.
add_action( 'admin_menu', function() {
if ( ! current_user_can( 'manage_options' ) ) {
remove_menu_page( 'tools.php' );
remove_menu_page( 'edit-comments.php' );
remove_menu_page( 'themes.php' );
}
} );
Esse código remove Ferramentas, Comentários e Aparência para quem não é administrador. Note a condição: ela protege o admin. Sem o if, você remove os menus para todo mundo, inclusive para você. É o erro mais comum de quem copia snippet de fórum.
Para esconder o que não é menu, como widgets do dashboard, o caminho é remove_meta_box() ou remove_action() no mesmo gancho. Vá removendo um item por vez e testando no usuário de teste. A pressa aqui custa caro.
Passo a passo: função no tema (child theme)
Se você precisa de uma área do cliente WordPress com boas-vindas, atalhos para o que ele usa e esconder o resto, o child theme é o lugar. Nunca edite o tema pai: a próxima atualização apaga tudo.
Crie um arquivo no child theme e registre um widget de dashboard com as instruções do cliente. O gancho é wp_dashboard_setup. A vantagem é que o painel fica com a cara da agência. A desvantagem é que, se o cliente trocar de tema, a personalização vai junto. Por isso, trate o child theme como parte do contrato de manutenção, não como um extra.
Esse caminho também é o mais indicado quando você quer incluir um link direto para o manual de uso. Se ainda não montou esse material, veja manual para cliente WordPress: o que entregar na entrega.
Passo a passo: plugin de painel
Plugins de personalização de admin resolvem em minutos: você marca os menus que quer esconder, define cores e pronto. Para um site único, é a via mais rápida. O problema aparece na escala: cada plugin tem sua própria forma de salvar configuração, e replicar em dez sites vira trabalho manual.
Além disso, todo plugin a mais é uma superfície de atualização. Se ele quebrar depois de um update, o painel do cliente pode voltar ao padrão sem aviso. Por isso, se usar plugin, prefira um que exporte e importe configuração. Assim você replica o mesmo painel para cliente WordPress em vários sites sem refazer clique por clique.
Quando NÃO usar cada saída
Não use papel de usuário ajustado se o cliente precisa de algo que só o administrador faz, como gerenciar usuários ou aprovar comentários em massa. Nesse caso, o papel vai te limitar e você vai acabar voltando atrás.
Não use função no tema se o site está em um tema que o cliente troca com frequência ou se você não controla o child theme. A regra some na primeira troca.
Não use plugin de painel se a agência administra vários sites com clientes diferentes e quer padronizar. A repetição consome tempo e a consistência se perde.
Erros comuns ao restringir o painel
- Remover menu sem condição de administrador e perder o próprio acesso.
- Entregar Editor achando que ele não mexe em plugins. Ele não mexe, mas vê e pode instalar se a capacidade estiver liberada.
- Esconder menu sem esconder a URL direta. O cliente ainda acessa
/wp-admin/plugins.phpse digitar. - Esquecer de testar em janela anônima. O cache do navegador mostra o menu antigo e você acha que funcionou.
- Aplicar a restrição no admin antes de ter um segundo administrador ativo.
O terceiro item é o mais ignorado. Esconder menu é cosmético: quem sabe a URL chega lá. Se a intenção é bloquear de verdade, é preciso remover a capacidade, não só o link. Para isso, estude map_meta_cap ou use um plugin de controle de acesso. E lembre que bloquear demais pode trancar o próprio cliente fora de algo que ele precisa.
Como isso se comporta quando o cliente tem vários sites
Uma agência que administra dez sites costuma repetir a mesma configuração dez vezes. Se cada uma foi feita por plugin, a manutenção vira uma colcha de retalhos: um site com menu escondido, outro sem, outro com plugin desatualizado. A padronização importa mais do que a ferramenta escolhida.
Por isso, o critério de decisão do começo do artigo volta aqui: escolha a saída que você consegue replicar. Papel ajustado mais um snippet versionado no child theme costuma ser o que sobrevive. Quando o cliente tem vários domínios, relatórios e acessos separados também precisam de organização, como em relatório separado por site: quando o cliente tem vários domínios.
Se a agência gerencia muitos sites, um painel para cliente WordPress centralizado ajuda a aplicar as mesmas regras de acesso e acompanhar atualizações sem repetir a configuração site a site. É o tipo de tarefa que o 100% WP resolve ao concentrar atualizações, backups e monitoramento em um lugar só, sem que você precise entrar em cada admin.
Prevenção: o que deixar documentado
Depois de montar o painel, registre em texto: qual papel o cliente tem, quais menus foram removidos, qual snippet está no child theme e onde ele está. Isso evita que, seis meses depois, outro dev mexa no site e desfaça o que você fez. Também ajuda na hora de renovar contrato e mostrar valor, como em cliente de longo prazo em WordPress: como renovar contratos.
Vale ainda revisar o acesso do próprio cliente: se ele tem senha fraca ou compartilha login, o painel restrito não protege nada. Veja proteger senha admin WordPress sem perder o acesso para os cuidados básicos.
Quando chamar alguém
Se você não tem acesso a SSH nem ao gerenciador de arquivos da hospedagem, mexer em child theme e snippet fica arriscado. Nesse caso, comece pelo papel de usuário ajustado, que é feito só pelo painel, e deixe a parte de código para quem tem acesso ao servidor. Se o site já está com o acesso quebrado, o caminho é recuperar primeiro, como em senha do WordPress não funciona: como recuperar o acesso ao painel, e só depois restringir.
Em resumo: defina o papel, teste em janela anônima, esconda o que não é rotina e documente. O painel para cliente WordPress não precisa ser bonito. Precisa ser previsível, para o cliente e para você.
