Funções de usuários e Capacidades do WordPress – Parte 1: O básico

Este artigo é parte de um tutorial dividido em três partes abordando o tópico dos usuários (users), funções (roles) e capacidades (capabilities) no WordPress. Esta série irá abordar a arquitetura e design dos user roles no WordPress; ressaltar as funções mais importantes para interação com usuários e gestão de roles e capabilities; e no último tutorial, iremos construir um exemplo prático que demonstra a utilização desta API.

• Funções de usuários e Capacidades do WordPress – Parte 1: O básico
• Funções de usuários e Capacidades no WordPress – Parte 2: Funções interessantes
• Funções de usuários e Capacidades no WordPress – Parte 3: Um exemplo prático

Introdução

Esta primeira parte é um passo-a-passo sobre os fundamentos e o funcionamento interno do sistema de usuários (users), funções (roles) e capacidades (capabilities) presente no WordPress. Não serão apresentados códigos ou funções nesta parte, então se você estiver interessado apenas em escrever código que  interaja com este sistema, pode pular para a próxima parte. Entretanto, recomendo fortemente a leitura deste artigo para obter uma noção básica dos fundamentos do sistema de users e roles do WordPress.

A partir da versão 2.0, o WordPress apresentou um novo sistema de roles e capabilities que substituiu o sistema antigo. Não iremos discutir aqui o sistema antigo; ele está totalmente obsoleto agora (a partir da versão 3.0) e não deve mais ser utilizado.

O novo sistema é mais avançado e flexível. Agora é possível criar permissões personalizadas (custom permissions) e designá-las separadamente por usuário. Esta atualização veio para corrigir as deficiências do modelo antigo e permitir aos desenvolvedores construir temas e plugins mais poderosos e personalizados.

Arquitetura do banco de dados para usuários

1. Diagrama da tabela de usuários

O WordPress armazena os dados dos usuários em duas tabelas: wp_users e wp_usermeta (nesta série vamos assumir que a sua instalação usa o prefixo wp_ que é o prefixo padrão). A segunda tabela é criada como extensão da primeira e possibilita aos desenvolvedores anexar dados adicionais a cada usuário.

Se só houvesse uma tabela, não seria possível associar novos dados aos usuários, ou então precisaríamos manter toda esta informação serializada em uma só coluna, o que não é nada bom em termos de performance e escalabilidade. (Imagine um cenário onde 50 plugins adicionem cada um 2 ou 3 novos campos por usuário).

O diagrama abaixo representa a estrutura das duas tabelas. A relação entre elas é de “um para muitos”. De fato, podemos ter tantos registros quanto for preciso na tabela wp_usermeta com o mesmo user_id (que é a chave estrangeira deste relacionamento e representa a coluna de ID em wp_users).

2. Por dentro das tabelas

Examinando a estrutura destas duas tabelas, podemos concluir que wp_users é utilizada para armazenar uma quantidade limitada e finita de dados sobre cada usuário. Alguns destes dados são obrigatórios e usados principalmente pelo core do WordPress, por temas ou por plugins: como por exemplo login, senha, email e nice name (e também nickname). Mas não é o caso do campo user_url, por exemplo. Por não ser obrigatório, este campo poderia pertencer à tabela wp_usermeta.

Alguns campos obrigatórios são armazenados em wp_usermeta, como por exemplo o apelido (nickname). Na verdade, só tenho conhecimento deste único campo. Entretanto, algumas informações críticas como as capabilities do usuário, o user level e modo SSL são também armazenadas na tabela wp_usermeta. O que a torna não menos importante que a tabela wp_users (principalmente com a importância de segurança e permissionamento em um projeto).

Com isto em mente, você deve ser cuidadoso ao lidar com ambas as tabelas. Recomendo que você se atenha às funções nativas do WordPress ao interagir com o sistema de users e capabilities.

Funções de usuários e Capacidades no WordPress

Como qualquer outro CMS, o WordPress possui um sistema de permissões que concede ou restringe privilégios para cada usuário. Nesta seção, irei explicar o conceito por trás das funções e capacidades no WordPress. Por isso, se você já penou para compreender as explicações do Codex, espero que tudo se esclareça ao abordar o conceito de forma diferente.

1. Uma visão geral sobre as capacidades (capabilities)

Esqueça as funções. Vamos assumir por alguns instantes que eles não existam.

Visualize o cenário a seguir: Você tem um blog WordPress recém-criado, do qual é administrador (o que garante a você todo o poder possível). Decidindo acrescentar um novo usuário para contribuir com posts para seu blog, você conclui que seria bom permitir a ele criar comentários e personalizar seu nome de exibição (display name).

A imagem abaixo mostra nosso usuário hipotético com as capabilities que foram designadas para ele.

É simples assim: você designa uma capacidade (capabilities) a seus usuários, e é livre para nomeá-las como quiser. Por exemplo, você pode chamar de “write_new_post” o slug de escrever um novo post.

O seu blog vai ter uma lista de capabilities onde cada uma garante, apenas aos usuários que a possuírem, uma habilidade especial e limitada. Cada usuário pode ter um número limitado de capacidades. Um usuário que possua todas as capacidades é um administrador, já que ele pode fazer praticamente tudo. Encare como um sistema de permissões, onde as capacidades são as permissões que você dá aos seus usuários.

Mas e por que as capabilities são importantes? Bom, aí depende de você. Por exemplo, no caso de você estar criando seu próprio plugin (ou tema), você pode criar sua própria capability “access_control_panel” e designá-la a alguns usuários.

Quando um usuário requisitar acesso ao seu “painel de controle”, será preciso verificar se o usuário possui a capability “access_control_panel” antes de exibir a página contendo o painel de controle. Você também pode fazer uma verificação de capability antes de executar algum trecho de código em particular para se certificar de que o usuário possui os privilégios requeridos.

O WordPress já vem por padrão com um número de capabilities necessárias ao seu funcionamento. Você pode lançar mão destas capabilities, mas tome cuidado para não removê-las. Você pode, é claro, criar suas próprias capabilities personalizadas.

2. Como as funções (roles) entram em jogo

Agora sabemos o que são as capabilities. Vamos visualizar um outro cenário, onde você tem uma quantidade maior de usuários, e deseja dividi-los em dois grupos: um com usuários mais privilegiados, e outro com menos privilégios. Cada grupo de usuários terá capabilities especiais.

Para atingir este objetivo, seria preciso atribuir as mesmas capabilities paara cada usuário, o que pode ser um tanto frustrante e improdutivo. É aí que entram em cena os roles, criados exatamente para agrupar usuários.

Então, em vez de atribuir capabilities aos usuários, você as atribui a roles; e em seguida atribui estes aos usuários (embora seja possível atribuir capabilities diretamente a usuários). Um role pode ser criado para um ou para vários usuários; e um usuário pode ter nenhum, um ou vários roles.

Então temos na realidade algo mais próximo disto:

É importante notar que antes de executar algum código que exija permissão, você deve verificar a presença de uma capability do usuário e não de um role. Nunca assuma que um role possui uma capability específica, pois isto pode ser alterado por outro plugin ou tema.

3. Meta Capabilities

Existem ações que necessitam de mais de uma capacidade (capability) para ser realizadas. Por exemplo, para editar um post do blog, você precisa da capability “edit_post“. Mas e se este post tiver sido criado por outro usuário? Você também vai precisar então da capability “edit_other_posts“. Então é preciso verificar a presença de ambas antes de permitir que o usuário edite o post.

É aí que entram as meta capabilities. O WordPress possui a função map_meta_cap() que retorna um array das capabilities necessárias para se executar uma capability em particular

Voltemos ao exemplo anterior. Vamos assumir que exista um usuário cuja ID é 3, e queremos verificar se este usuário pode editar um post cuja ID é 5. Este post foi originalmente publicado por outro usuário cuja ID é 6.

Neste caso, a função map_meta_cap() irá retornar um array com as seguintes capabilities:
edit_post, edit_published_posts, e edit_other_posts. Para criar este array, a função map_meta_cap() precisa fazer algumas verificações com base no usuário e no post.

As capabilities que a função verifica por padrão são delete_user, edit_user, remove_user, promote_user, delete_post, delete_page, edit_post, edit_page, read_post, ou read_page. É possível, entretanto, expandir com as suas personalizações com um hook no filtro map_meta_cap.

Conclusão

Este é, em resumo, o sistema de usuários e permissões do WordPress. Tentei manter o tutorial o mais simples e minimalista possível; e evitei incluir qualquer trecho de código. Na próxima parte, iremos examinar uma vasta gama de funções que o WordPress fornece para interação com este sistema.
Nota: O texto acima é uma tradução que fiz especialmente para o Tudo Sobre WordPress do artigo escrito por Abid Omar e publicado originalmente no site WP Tuts. Escolhi por manter no idioma original original termos técnicos como roles e capabilities, em vez de usar os correspondentes “funções” e “capacidades”, por dois motivos: evitar a confusão com as funções utilizadas pelos desenvolvedores na linguagem PHP, e se aproximar dos termos empregados nestas mesmas funções.