Editor do WordPress vs. Função de Administrador: Um Guia Técnico Completo
O WordPress inclui um sistema granular de controlo de acesso baseado em funções (RBAC) integrado diretamente no seu núcleo. De todas as funções predefinidas, Administrador e Editor são as duas mais relevantes — e as mais frequentemente atribuídas de forma incorreta. O Administrador possui capacidade irrestrita sobre todos os objetos do WordPress, enquanto o Editor opera com ampla autoridade sobre conteúdo, mas sem qualquer acesso a controlos ao nível da infraestrutura, como temas, plugins ou definições do site.
Confundir esta distinção não é um mero inconveniente. Conceder acesso de Administrador a um redator de conteúdo num site em produção é uma superfície de ataque direta: uma conta comprometida pode instalar um plugin malicioso, exfiltrar a base de dados ou bloquear todos os outros utilizadores. Este guia fornece-lhe a profundidade técnica necessária para tomar a decisão certa em todas as situações.
Como Funcionam Realmente as Funções e Capacidades do WordPress
Antes de comparar as duas funções, vale a pena compreender a arquitetura subjacente. O WordPress não armazena funções como uma propriedade fixa de uma conta de utilizador. Em vez disso, armazena um array serializado de capacidades na tabela wp_usermeta sob a chave wp_capabilities (onde wp_ é o prefixo da sua tabela). Cada função é simplesmente um conjunto nomeado de capacidades registadas na classe WP_Roles.
Quando um utilizador tenta executar uma ação — publicar um post, eliminar um plugin, editar o perfil de outro utilizador — o WordPress chama current_user_can(), que resolve as capacidades armazenadas do utilizador em relação à primitiva solicitada. Isto significa que as capacidades são aditivas e, de forma importante, podem ser personalizadas por utilizador independentemente da sua função, utilizando plugins como Members ou User Role Editor.
A implicação prática: se precisar de um utilizador que possa fazer *quase* tudo o que um Editor pode fazer, mas também gerir um plugin específico, não precisa de o elevar a Administrador. Pode conceder uma única capacidade adicional. Compreender isto evita o erro de sobre-provisionamento mais comum na gestão de equipas WordPress.
Função de Administrador: Análise Completa das Capacidades
A função de Administrador mapeia praticamente todas as capacidades primitivas que o WordPress expõe. Numa instalação de site único, isto inclui, entre outras:
Capacidades de gestão central do site:
manage_options — ler e escrever todas as definições via wp-admin/options-general.php, incluindo URL do site, email de administrador, estrutura de permalinks e fuso horário
install_plugins, activate_plugins, update_plugins, delete_plugins — controlo total do ciclo de vida dos plugins
install_themes, switch_themes, edit_themes, delete_themes — controlo total do ciclo de vida dos temas, incluindo edição direta de ficheiros através do editor de temas integrado (um vetor de ataque significativo)
edit_files — acesso ao editor de código integrado para temas e plugins (esta capacidade é desativada quando DISALLOW_FILE_EDIT está definido como true em wp-config.php)
Capacidades de gestão de utilizadores:
create_users, edit_users, delete_users, promote_users, list_users — autoridade total sobre todas as contas de utilizador no site, incluindo a capacidade de rebaixar ou eliminar outros Administradores
remove_users — remover utilizadores de uma rede Multisite
Capacidades de conteúdo:
edit_others_posts, edit_published_posts, delete_others_posts, delete_published_posts, delete_private_postspublish_posts, publish_pages, edit_pages, delete_pages, edit_others_pagesCapacidades avançadas:
import — importar conteúdo através do importador do WordPress (pode ser utilizado para injetar conteúdo arbitrário em grande escala)
export — exportar todo o conteúdo do site como ficheiro XML, incluindo todos os dados de utilizadores
update_core — acionar atualizações do núcleo do WordPress
manage_categories, moderate_comments, unfiltered_html — publicar HTML em bruto incluindo tags <script> sem sanitização
A capacidade unfiltered_html merece atenção especial. Numa instalação padrão de site único, tanto Administradores como Editores a recebem. No WordPress Multisite, apenas os Super Admins a mantêm. Esta é uma fronteira de segurança significativa: sem unfiltered_html, o filtro wp_kses_post() remove JavaScript e outras marcações potencialmente perigosas do conteúdo guardado.
Quando Atribuir a Função de Administrador
A pessoa que é proprietária da conta de alojamento e é responsável pela integridade técnica do site
Um programador ou engenheiro DevOps verificado que realiza desenvolvimento de temas, configuração de plugins ou trabalho de integração do lado do servidor
Um especialista em migração durante uma operação pontual de importação/exportação (considere revogar a função posteriormente)
Nota operacional crítica: Nunca atribua a função de Administrador a uma conta partilhada ou genérica. Cada Administrador deve ser um indivíduo identificado com uma palavra-passe única e forte e autenticação de dois fatores ativada. Se estiver a executar o WordPress num ambiente de Alojamento VPS, combine a higiene de Administrador ao nível do WordPress com separação de utilizadores ao nível do sistema operativo — o processo do seu servidor web nunca deve ser executado como root, e a propriedade dos ficheiros WordPress deve ser distinta do utilizador do servidor web.
Função de Editor: Análise das Capacidades
A função de Editor foi criada especificamente para operações de conteúdo. Concede ampla autoridade sobre posts, páginas, media, comentários e taxonomia — mas exclui deliberadamente todas as capacidades ao nível da infraestrutura.
Capacidades de conteúdo que um Editor possui:
edit_posts, edit_others_posts, edit_published_posts, edit_private_postsdelete_posts, delete_others_posts, delete_published_posts, delete_private_postspublish_posts, publish_pagesedit_pages, edit_others_pages, edit_published_pages, edit_private_pagesdelete_pages, delete_others_pages, delete_published_pages, delete_private_pagesmanage_categories — criar, renomear e eliminar categorias e etiquetasmoderate_comments — aprovar, reprovar, marcar como spam ou eliminar permanentemente comentáriosupload_files — adicionar media à biblioteca; editar metadados de imagens e texto alternativoread_private_posts, read_private_pages — ver conteúdo que não está acessível publicamenteunfiltered_html — em instalações de site único, os Editores podem publicar HTML em bruto (ver a ressalva do Multisite acima)O que um Editor explicitamente não pode fazer:
- Aceder a
wp-admin/options-general.phpou a qualquer ecrã de definições - Instalar, ativar, desativar ou eliminar plugins ou temas
- Ver ou modificar qualquer conta de utilizador que não seja o seu próprio perfil
- Executar atualizações do núcleo do WordPress
- Aceder aos editores de ficheiros de temas ou plugins integrados
- Alterar estruturas de permalinks, o que quebraria todos os URLs existentes em todo o site
- Exportar ou importar dados do site
Quando Atribuir a Função de Editor
- Um editor-chefe ou diretor de conteúdo que gere o calendário editorial e aprova rascunhos de vários colaboradores
- Um especialista em SEO que precisa de publicar, agendar e otimizar posts, mas não tem qualquer necessidade de aceder às definições de plugins
- Um gestor de redes sociais ou de marketing responsável por manter o blog ativo
- Um cliente que precisa de atualizar as suas próprias páginas sem o risco de quebrar acidentalmente o site
Administrador vs. Editor: Comparação Lado a Lado
| Área de Capacidade | Administrador | Editor |
|---|---|---|
| Instalar / atualizar / eliminar plugins | Sim | Não |
| Instalar / atualizar / eliminar temas | Sim | Não |
| Editar ficheiros de temas / plugins (editor de código) | Sim (exceto se DISALLOW_FILE_EDIT) | Não |
| Gerir atualizações do núcleo do WordPress | Sim | Não |
| Aceder às definições do site (opções) | Sim | Não |
| Alterar estrutura de permalinks | Sim | Não |
| Criar / editar / eliminar outros utilizadores | Sim | Não |
| Atribuir ou alterar funções de utilizadores | Sim | Não |
| Publicar e editar os próprios posts | Sim | Sim |
| Editar e eliminar posts de outros utilizadores | Sim | Sim |
| Gerir categorias e etiquetas | Sim | Sim |
| Moderar comentários | Sim | Sim |
| Carregar e gerir media | Sim | Sim |
| Ler posts e páginas privados | Sim | Sim |
| Publicar HTML não filtrado (site único) | Sim | Sim |
| Exportar conteúdo do site | Sim | Não |
| Importar conteúdo | Sim | Não |
| Aceder ao painel de administração da rede Multisite | Apenas Super Admin | Não |
Implicações de Segurança da Atribuição Incorreta de Funções
O Problema do Editor com Privilégios Excessivos
Um padrão comum em agências: um redator de conteúdo recebe acesso de Administrador porque "é mais fácil." Isto cria vários riscos concretos:
- Instalação de plugins como vetor de execução de código. Qualquer Administrador pode instalar um plugin. Um plugin é código PHP que é executado no seu servidor. Uma conta de Administrador comprometida equivale a execução remota de código.
- Recolha de credenciais através de exportação. A ferramenta de exportação do WordPress produz um ficheiro XML contendo todo o conteúdo de posts, comentários e metadados de autores. Um Administrador pode acionar isto silenciosamente.
- Persistência de escalada de privilégios. Um atacante que obtém acesso de Administrador pode criar uma nova conta de Administrador e depois eliminar os vestígios — bloqueando o proprietário legítimo.
- Abuso de
unfiltered_html. Mesmo sem acesso a plugins, um Administrador pode injetar tags<script>diretamente no conteúdo de posts, permitindo ataques XSS armazenados contra os visitantes do site.
Reforço da Função de Administrador
Além da atribuição de funções, aplique estes controlos ao nível do WordPress em qualquer site em produção:
Adicione o seguinte a wp-config.php para desativar o editor de ficheiros integrado:
define( 'DISALLOW_FILE_EDIT', true );
define( 'DISALLOW_FILE_MODS', true ); // Also blocks plugin/theme installationRestrinja a área de administração do WordPress por IP ao nível do servidor. Para Nginx:
location /wp-admin/ {
allow 203.0.113.0/24;
deny all;
}Para Apache, adicione a .htaccess:
<Files "wp-login.php">
Require ip 203.0.113.0/24
</Files>Imponha palavras-passe fortes e autenticação de dois fatores utilizando um plugin como WP 2FA ou Wordfence Login Security. Se o seu site for executado num Servidor Dedicado, considere colocar o painel de administração do WordPress atrás de uma VPN ou túnel SSH em vez de o expor à internet pública.
Proteção da Função de Editor contra Abusos
A função de Editor é significativamente mais segura do que a de Administrador, mas não está isenta de riscos:
- Um Editor com
unfiltered_htmlpode injetar pixels de rastreamento, redirecionamentos de afiliados ou scripts maliciosos no conteúdo de posts. No Multisite, esta capacidade é removida — um argumento forte para executar uma rede Multisite quando tem muitos colaboradores de conteúdo. - Um Editor pode eliminar permanentemente qualquer post ou página, incluindo os que não foram por si criados. Não existe uma reciclagem integrada para páginas. Utilize uma estratégia de revisão ou cópia de segurança para mitigar isto.
- Um Editor pode aprovar comentários, incluindo os que contêm links de spam, o que afeta o SEO e a reputação do seu site.
WordPress Multisite: Como as Funções Mudam
Numa rede WordPress Multisite, a hierarquia de funções ganha um nível adicional: Super Administrador. O Super Admin situa-se acima de todos os Administradores ao nível do site e controla as definições de toda a rede, a ativação de plugins em todos os sites e a criação de utilizadores ao nível da rede.
No Multisite, um Administrador ao nível do site perde várias capacidades que existem em instalações de site único, incluindo a capacidade de instalar plugins (apenas os Super Admins podem fazê-lo em toda a rede) e a capacidade unfiltered_html. Isto torna o Multisite uma arquitetura mais defensável para agências que gerem sites de clientes ou editoras que gerem múltiplas propriedades editoriais.
Se estiver a construir uma plataforma de publicação multi-inquilino, um VPS com cPanel pode simplificar a camada de gestão do lado do servidor, enquanto o WordPress Multisite trata da separação de funções ao nível da aplicação.
Funções Personalizadas: Quando Nem Administrador Nem Editor se Adequam
As funções add_role() e add_cap() do WordPress permitem-lhe definir funções com precisamente as capacidades que o seu fluxo de trabalho requer. Por exemplo, um Editor Sénior que pode fazer tudo o que um Editor pode fazer, mais gerir utilizadores (mas não plugins), pode ser criado programaticamente:
add_role(
'senior_editor',
'Senior Editor',
array(
// Inherit all standard Editor capabilities
'read' => true,
'edit_posts' => true,
'edit_others_posts' => true,
'edit_published_posts' => true,
'publish_posts' => true,
'delete_posts' => true,
'delete_others_posts' => true,
'delete_published_posts' => true,
'edit_pages' => true,
'edit_others_pages' => true,
'edit_published_pages' => true,
'publish_pages' => true,
'delete_pages' => true,
'manage_categories' => true,
'moderate_comments' => true,
'upload_files' => true,
// Extended capability
'list_users' => true,
'edit_users' => true,
)
);Coloque este código num plugin específico do site (não no functions.php de um tema) para que a função persista entre alterações de tema. As funções são armazenadas na base de dados após o primeiro registo, pelo que add_role() só precisa de ser executado uma vez — envolva-o num hook de ativação de plugin usando register_activation_hook().
Matriz de Decisão Prática para Atribuição de Funções
Utilize esta lista de verificação antes de atribuir qualquer função:
Atribua Administrador apenas se o utilizador:
- For proprietário do site ou tiver responsabilidade contratual pela sua operação técnica
- Precisar de instalar, configurar ou atualizar plugins e temas
- Tiver de gerir outras contas de utilizador ou alterar funções de utilizadores
- Necessitar de acesso às definições do WordPress, estrutura de permalinks ou URL do site
- Tiver a autenticação de dois fatores ativada e utilizar uma conta única e não partilhada
- Compreender que
DISALLOW_FILE_MODSserá definido comotrueem produção
Atribua Editor se o utilizador:
- For responsável pela qualidade do conteúdo, calendários de publicação ou revisão editorial
- Precisar de gerir posts e páginas criados por outros membros da equipa
- Dever ser capaz de moderar comentários e gerir media
- Não precisar — e não dever ter — acesso a qualquer plugin, tema ou ecrã de definições
- Puder ser um cliente, freelancer ou contratado cuja segurança de conta não pode controlar totalmente
Considere uma função personalizada se:
- O Editor integrado for demasiado restritivo (por exemplo, o utilizador precisa de
list_userspara um plugin de fluxo de trabalho editorial) - O Administrador integrado for demasiado permissivo (por exemplo, um programador que precisa de acesso a plugins, mas não deve tocar nas contas de utilizadores)
- Estiver a executar uma rede Multisite com responsabilidades diferenciadas entre sites
Para equipas que gerem o WordPress juntamente com email transacional, considere combinar a sua estratégia de funções com uma configuração dedicada de Alojamento de Email para que os emails de notificação do WordPress (reposições de palavra-passe, novos registos de utilizadores, alertas de comentários) sejam encaminhados através de um servidor de correio fiável e autenticado, em vez do sendmail predefinido do servidor de alojamento — um ponto de falha de entregabilidade comum que afeta o fluxo de trabalho de todas as funções.
Se o seu site WordPress lida com comércio eletrónico, membros ou quaisquer dados de utilizadores, certifique-se de que os seus Certificados SSL estão atualizados e corretamente configurados. Um certificado expirado não afeta apenas o SEO — quebra o contexto de segurança do navegador que protege as credenciais de início de sessão do Administrador em trânsito.
Principais Conclusões Técnicas
- As capacidades do WordPress são armazenadas por utilizador em
wp_usermeta, não codificadas de forma fixa — podem ser personalizadas sem alterar a função apresentada de um utilizador. DISALLOW_FILE_EDITeDISALLOW_FILE_MODSemwp-config.phpsão inegociáveis em qualquer site em produção com múltiplos Administradores.- A capacidade
unfiltered_htmlexiste tanto para Administradores como para Editores em instalações de site único. O Multisite remove-a de todos os utilizadores abaixo do Super Admin. - Um Editor pode eliminar permanentemente qualquer post ou página, incluindo conteúdo de outros utilizadores. Implemente uma estratégia de cópia de segurança ou revisão antes de conceder esta função a qualquer pessoa fora da sua equipa principal.
- Nunca utilize uma conta de Administrador partilhada. Uma conta por pessoa, autenticação de dois fatores obrigatória e registos de auditoria ativados através de um plugin como WP Activity Log.
- As funções personalizadas via
add_role()são a solução correta quando nenhuma função predefinida se adequa — não sobre-provisione para compensar uma capacidade em falta. - No Multisite, os Administradores ao nível do site não podem instalar plugins. Isto é uma funcionalidade, não uma limitação — é a arquitetura correta para ambientes multi-inquilino geridos.
Perguntas Frequentes
Um Editor pode eliminar posts de outro utilizador no WordPress?
Sim. A função de Editor inclui delete_others_posts e delete_others_pages. Um Editor pode eliminar permanentemente qualquer post ou página no site, independentemente de quem o criou. Não existe um passo de confirmação integrado nem uma reciclagem para páginas, pelo que esta ação é irreversível sem uma cópia de segurança.
Qual é a diferença entre Administrador e Super Administrador no WordPress?
Numa instalação WordPress de site único, o Administrador é a função mais elevada. Numa rede WordPress Multisite, o Super Administrador situa-se acima de todos os Administradores ao nível do site e controla as definições de toda a rede, a instalação de plugins em todos os sites e a capacidade de adicionar ou remover sites da rede. Um Administrador ao nível do site no Multisite não pode instalar plugins nem utilizar unfiltered_html.
Posso dar a um Editor acesso às definições de um plugin específico sem o tornar Administrador?
Sim. Utilize add_cap() para conceder uma capacidade específica a um utilizador individual, ou crie uma função personalizada que inclua as capacidades predefinidas do Editor mais a capacidade específica que o plugin regista. A maioria dos plugins bem codificados utiliza current_user_can( 'manage_options' ) ou uma capacidade personalizada para as suas páginas de definições — verifique o código-fonte do plugin para identificar a capacidade exata necessária.
É seguro ter múltiplos Administradores num site WordPress?
Depende inteiramente dos seus controlos operacionais. Múltiplos Administradores multiplicam a superfície de ataque — cada conta é um potencial ponto de entrada. Se múltiplos Administradores forem necessários, imponha a autenticação de dois fatores para todos eles, restrinja o acesso a /wp-admin/ por IP ao nível do servidor, defina DISALLOW_FILE_MODS como true e utilize um plugin de registo de atividade para auditar todas as ações administrativas.
Como posso auditar quais as capacidades que um utilizador WordPress específico realmente possui?
Consulte a base de dados diretamente ou utilize um plugin como Members ou User Role Editor. Para uma verificação programática, utilize get_user_meta( $user_id, $wpdb->prefix . 'capabilities', true ) num script personalizado ou no WordPress CLI:
wp user get <user_id> --field=roles
wp user list-caps <user_id>O comando wp user list-caps apresenta todas as capacidades que o utilizador possui, incluindo as que foram concedidas individualmente fora da sua função atribuída — o que é a forma mais fiável de auditar contas com sobre-provisionamento.
