Vamos dar continuidade ao nosso artigo sobre como o WordPress trata a questão de perfis/papéis e permissões de usuário. Nesta parte iremos falar de como aplicar tudo o que vimos até aqui, apesar de não ser um termo oficial, é muito comum nos referimos aos perfis/papéis usando o termo “tipos de usuários” principalmente quando precisamos usar nas diferentes situações do Front-end. Digamos que você está construindo um site para uma loja. Além do Administrador que supervisiona todos os colaboradores (e todos os autores que escrevem no site da loja), você também tem compradores e vendedores – estes seriam os tipos de usuário registrados no seu site, porém cada um exigiria um front-end diferenciado.

Na página de perfil de um usuário comprador provavelmente você queira mostrar o número de itens comprados, frequência de compra de material quando conectado, e ainda poderia ver uma lista de arquivos baixados.

Já na página de vendedor teríamos o portfólio de trabalho do vendedor, os itens mais vendidos, e assim por diante. Quando conectado, ele provavelmente também precise ver as estatísticas de vendas da loja.

Não esqueça de ler também os dois primeiros artigos:

• Trabalhando com roles e capabilities sem plugins – Parte 01
• Trabalhando com roles e capabilities sem plugins – Parte 02

Configurando os papéis e as permissões

Como podemos perceber, temos dois papéis bem distintos e um não pode fazer o papel do outro; então vamos criar os dois papéis com um conjunto de acesso a recursos e permissões (tudo vindo da minha mente). Vejamos isso:

add_action( 'admin_init', 'register_custom_roles' );

function register_custom_roles() {
    $seller = add_role( 'seller', _e('Vendedor'), array(
        'read' => true,
            'delete_posts' => true,
            'edit_posts' => true,
            'delete_published_posts' => true,
            'publish_posts' => true,
            'upload_files' => true,
            'edit_published_posts' => true,
        'view_sales' => true,
        'moderate_comments' => true
    ));

    $role = get_role( 'administrator' );

        if( null !== $seller ) {
        $role->add_cap( 'view_sales' );
        $role->add_cap( 'view_others_sales' );
   }

    $buyer = add_role( 'buyer', _e('Comprador'), array(
        'read' => true,
        'add_payment' => true,
        'download_resources' => true
    ));

        if( null !== $buyer ) {
        $role->add_cap( 'add_payment' );
        $role->add_cap( 'add_others_payment' );
        $role->add_cap( 'download_resources' );
        $role->add_cap( 'download_others_resources' );
   }

}

A ideia aqui é que os vendedores atuem como autores, que irão armazenar itens vendáveis como um “post”. Assim definimos os recursos de autor. Adicionalmente eles também podem ver as estatísticas de vendas de seus próprios itens.

Nota: eu tenho por costume sempre usar variáveis, e tudo que for do sistema escrever em inglês.

Além da exibição dos itens, os compradores também podem adicionar pagamentos e downloads de arquivos relacionados aos itens que eles compram.

E claro que todas as funções novas também devem ser adicionadas ao perfil Administrador, como também o acesso as estatísticas de qualquer usuário, adicionar pagamentos a qualquer conta, e transferir recursos para qualquer item.

Implementando o front-end

A partir de agora é só colocarmos em prática tudo que vimos até aqui e determinar as verificações de quem pode ver o quê. Vejamos alguns exemplos:

Listando os usuários

Supondo que queremos listar todos os usuários numa página de colaboradores, onde compradores possam ver os itens comprados e os itens vendidos pelos vendedores. Vejamos como isso pode ser codificado:

<!-- 
  Os dados de usuário são armazenados na variavel global $user no WordPress como um objeto de WP_User
--> 

<div class='user'>
    <div class='row'>
        <div class='threecol'>
            <?php echo get_avatar( $user->ID, 120 ) ?>
        </div>
        <div class='sixcol'>
            <h1><?php echo $user->display_name ?></h1>
            <?php echo $user->description ?>
        </div>
        <div class='threecol last'>
            <?php if( user_can( $user->ID, 'buyer' ) ) : ?>    
                <div class='counter'>
                    <span class='number'><?php get_purchases_count( $user->ID ) ?></span>
                    <span class='text'><?php echo _e('comprados')?></span>
                </div>
            <?php else ?>
                <div class='counter'>
                    <span class='number'><?php get_sales_count( $user->ID ) ?></span>
                    <span class='text'><?php _e('vendidos')?></span>
                </div>            
            <?php endif ?>
        </div>
    </div>
</div>

Como podemos perceber, temos bastante coisa de código HTML. Repare como o contator é criado: usamos duas funções que não são parte do WordPress e foram adicionadas por nós e como a funçãouser_can() é utilizada para verificar os requisitos que definimos para chamar as funçõesget_purchases_count() e get_sales_count().

Claro que, em um exemplo do mundo real seria necessário mais algumas checagens e certificarmos que os compradores e vendedores são listados somente para um Papel ou para outro e talvez até exibir em um template diferenciado, por exemplo:

foreach( $users as $user_id ) {
    $user = get_userdata( $user_id );
    if( user_can( $user->ID, 'buyer' ) ) {
        get_template_part( 'userlist', 'buyer' );
    }
    else {
        get_template_part( 'userlist', 'seller' );
    }
}

Enquanto executamos o LOOP pelos usuários, tanto o userlist-buyer.php ou userlist-seller.php será utilizado de acordo com o papel do usuário.

Conclusão

O sistema de funções de usuários e capacidades do WordPress são ferramentas extremamente poderosas. Sempre que você criar um plugin que requer a implementação de permissões especiais baseadas em seus papéis, você deve considerar o uso desta técnica.

Além de tornar sua vida mais fácil (e mais gerenciável), ele vai te ajudar nos seus processos em seus sites e facilitando fazer um roolback quando tiver algum problema sem comprometer todo o resto.