Este artigo é a primeira parte da série sobre desenvolvimento de plugins e temas com o foco na integração com o ambiente nativo da administração do WordPress, o uso dos componentes gráficos tais como butões, tabelas, frames, entre outro CSS nativo, incluindo as API de configurações, nonces entre outras ferramentas que o WordPress já nos oferece.

Nesta primeira parte iremos falar de alguns pressupostos importantes na criação de interfaces e do básico da criação de páginas de administração, integrando apenas com o CSS que promove o UI do WordPress. Para isso começaremos por criar um novo plugin, que será a nossa forma de testar o código que iremos desenvolver.

INTRODUÇÃO

A evolução da interface de administração do WordPress ao longo de todo o seu desenvolvimento foi fantástica, na minha opinião é um fenómeno raro em vários níveis quando se trata de desenvolvimento colaborativo em software. Passámos a ter aos poucos uma interface cada vez mais limpa e acessível, sendo que, atualmente o WordPress é considerado por muitos como o CMS com a interface de administração mais simples e intuitiva para o usuário operador, e os testes que têm vindo a acontecer no blog sobre UI da equipa de desenvolvimento mostram bem essa ideia.
A verdade é que esse desenvolvimento é continuamente rápido e a evolução tem sido bastante grande de versão para versão, é por essa razão e muitas outras que é importante respeitar os padrões de design e intuitividade já estabelecidos pelo software quando você criar a interface para o seu plugin ou tema.

Durante este artigo iremos abordar várias razões para que isto aconteça.

CRIANDO O PLUGIN DE DESENVOLVIMENTO

Já aqui falámos de como desenvolver um plugin. É bastante simples, no entanto vou repetir os passos necessários para os leitores mais desatentos. :)

Em primeiro lugar, vamos criar uma nova pasta dentro da diretoria wp-content/plugins/ com o nome «plugin-teste-ui» e em seguida um ficheiro dentro dessa recém criada diretoria exatamente com o mesmo nome mais a extensão php, ou seja «plugin-teste-ui.php». Em seguida abra o ficheiro para edição e inclua o seguinte texto, também chamado cabeçalho do plugin:

<?php
/*
Plugin Name: Escola WP Teste UI
Version: 1.0
Author: Escola WP
Author URI: https://www.escolawp.com/
*/

Neste momento já tem o seu plugin criado e poderá dirigir-se à área de administração de plugins para ativá-lo, no entanto ele ainda não é funcional pois não tem nenhum código lá dentro. Vamos no entanto deixá-lo ativado pois vamos adicionando aos poucos o código.

EXPERIÊNCIA DO USUÁRIO

Este é também conhecido como UX, do inglês user experience, e é uma das particularidades em que a equipa de desenvolvimento da administração do WordPress se tem mais preocupado: manter a experiência do usuário por toda a administração consistente. É demasiado ofuscante quando um usuário instala um plugin no WordPress e apercebe-se que a sua interface nada tem a ver com a que está habituado. Manter uma interface consistente é importante para manter usuários: acredite, não são poucos os usuários que deixam de usar determinados plugins porque simplesmente “não são bonitos”.

MANTER SEMPRE ATUALIZADO

O sistema de atualizações do WordPress é bastante simples. As mudanças ocorrem nas atualizações maiores, ou seja, no incremento dos dois primeiros digitos da versão, enquanto que as versões menores apenas corrigem bugs, e pode existir um infindável número destas. Por exemplo, a próxima mudança de versão, da 3.4 para a 3.5, vai trazer novas APIs e uma interface melhorada, no entanto a versão 3.4.3 (que provavelmente poderá sair antes da 3.5) irá apenas corrigir bugs encontrados nas versões anteriores do WordPress.

Posto isto, manter o plugin atualizado e a funcionar corretamente em todas as versões futuras é necessário e importante e uma das maneiras para não nos preocuparmos com a interface e usando os elementos nativos, pois à medida que o WordPress vai atualizando a sua interface, ela será sempre consistente com as versões do nosso plugin.

REDUZIR A PEGADA DO PLUGIN NA INTERFACE

Esta é uma questão muito discutível, no entanto demasiado importante para ser deixada de fora. Existe a ideia entre os developers de que o plugin que criamos é mais importante que o próprio WordPress em si, e isso é natural pois quem é que não estima as suas criações? Eu também pasei por essa fase quando apenas programa plugins, no entanto, trabalhar e contribuir para a core deu-me uma percepção diferente do que deve ser um plugin. Enumero algumas das minhas conclusões:

  1. Um plugin deve servir apenas um propósito e não uma data deles;
  2. Serve apenas para extender funcionalidades e não para recriá-las (é para isso que existem action hooks do WordPress, se não existir nenhuma que possa ajudá-lo, peça uma!);
  3. Não deve ser de dificil instalação;
  4. Não deve criar demasiadas opções para o usuário, principalmente se requererem nível técnico.

Bom exemplo: P2P do scribu – é um plugin complexo mas com apenas uma finalidade: permitir ligar vários posts e usuários entre si apenas passando determinados parâmetro areavés da WP_Query, ou seja destinado a pessoas que saibam programar em PHP.

Mau Exemplo: W3 Total Cache – o propósito é fazer cache, no entanto também serve para integrar o S3 ou outro CDN, comprime o HTML, minifica o javascript e o CSS, importa automaticamente anexos dos posts para a biblioteca e só lhe falta tirar cafés para ficar completo… A meu ver totalmente desnecessário, sendo que este deveria ter sido separado em pequenos plugins cada um com um propósito apenas.

CRIAR OU NÃO CRIAR UM MENU OU SUBMENU?

Esta dúvida é muito importante responder coerentemente: “Será necessário meu plugin ter um menu ou um submenu específico?”, “poderei usar um dos submenus já existentes para colocar lá as opções?”. Como já referido anteriormente, é demasiado importante que se reduza a “pegada gráfica” do seu plugin para que o usuário se sinta confortável. Existem plugins cuja necessidade é de ter apenas um ou dois controladores (checkboxes, input boxes, etc), será mesmo necessário criar uma página nova na administração para apresentar esse dois controladores? Não poderão eles irem para a página de opções gerais?

Como exemplos disso poderemos pensar em dois plugins hipotéticos: um gere e integra todas as suas contas das redes sociais e necessita portanto no mínimo de uma input box para identificar cada conta. Faz sentido neste caso criar uma página nova chamada, por exemplo, “Redes Sociais” e aí disponibilizar seus controladores. Outro exemplo é de um plugin que transforma a galeria nativa do WordPress num slideshow em jQuery e que necessita de poucos controladores para modificar o aspecto do slideshow. Neste caso, faz sentido colocar esses controladores na página de “Opções de Media”.

Uma excepção poderá ser um plugin que forneça uma ferramenta ao WordPress. Ferramenta aqui é algo que corra na administração como um analisador de SEO ou um regenerador de thumbnails. Quando estamos perante um caso destes, esse plugin deve obrigatoriamente criar uma subpágina no menu de ferramentas.

Um bom exemplo de um plugin que não necessita de configurações pois já tem um propósito bem definido é o meu plugin “Hide Comments Feature” que simplesmente elimina o sistema de comentários do WordPress assim que ativado. É simples, direto, eficaz e não necessita de nenhuma configuração.

No meu entender não vejo razão nenhuma para que um plugin crie um novo menu de topo para albergar em várias páginas a sua funcionalidade. Um dos plugins que mais aprecio em termos de SEO é o WordPress SEO do Yoast de Valk, é bastante útil e as suas funcionalidades são milagrosas, no entanto ele erra em toda a construção que faz da sua interface. O plugin cria uma nova estrutura de raiz apenas para albergar várias subpáginas com uma montanha de configurações cada uma, muitas delas repetidas e desnecessárias. O mais interessante foi que nas versões seguintes o Yoast deve ter percebido a dificuldade que seus usuários encontravam em configurar o seu plugin e com isso decidiu incluir uma tour para guiar na configuração. Infelizmente também peca ao não saber usar a ferramenta ideal, que a meu ver poderia ser algo parecido com o wizard do BuddyPress.
Para terminar esta critica, o que para mim é mais flagrante: uma página de promoção chamada “About” e uma sidebar que acompanha todas as páginas que inclui várias caixas com publicidade e links para doações.

Não quero com isto dizer que o Yoast não possa monetizar o seu plugin, mas não é necessário fazer isto, pois podemos sempre partir do princípio que se uma pessoa quer doar porque gosta do trabalho, então ela fá-lo, procurando uma maneira de o fazer. A meu ver um pequeno link a pedir doação na página de ativação do plugin seria o suficiente e teria praticamente o mesmo efeito. A resolução ideal para este problema poderia ser a escolha das configurações mais importantes e criar uma subpágina chamada “SEO” no menu de opções. Todas as outras configurações deveriam ser deslocadas para action hooks.

DECISÕES, OPÇÕES NÃO!

É o mote usado sempre na construção do WordPress. A ideia é que o usuário não perca tempo em ter que configurar ou fazer escolhas. Escolhas levam a indecisões, indecisões levam a pedidos funcionalidade e quanto mais opções existirem mais propenso ao erro o WordPress se encontra. Obviamente, um usuário não deve ficar preso às escolhas da maioria e por isso é que existem os plugins: para extender as funcionalidades que possam ajudar um grupo de pessoas que usam o WordPress e fazer melhor o seu trabalho.

Tenha sempre em mente o seguinte quando for construir o seu plugin:

  • Um plugin deve ter um propósito, e apenas um, bem definido;
  • Deve dar a escolher ao usuário apenas opções que são fundamentais para o bom funcionamento do plugin;
  • Desenvolva uma funcionalidade de maneira a atender à maioria, e forneça action hooks para que o usuário mais desenvolto possa modificar a funcionalidade a seu gosto.

CRIANDO UMA PÁGINA NA ADMINISTRAÇÃO

Vamos então dar inicio à criação de uma subpágina na administração, abaixo do menu de opções. Esse submenu vai-se chamar fantasticamente “Teste de UI”! Para isso abra o ficheiro de plugin que criámos anteriormente e vamos então colocar o seguinte código:

<?php
// Adicionar uma acção no menu da adminsitração
add_action( 'admin_menu', 'test_ui_submenu_page' );

function test_ui_submenu_page() {
	// Adicionar um submenu para a página do plugin onde iremos criar controladores
	add_submenu_page( 'options-general.php', __( 'Teste UI', 'plugin-test-ui' ), __( 'Teste UI', 'plugin-test-ui' ), 'manage_options', 'plugin-test-ui', 'test_ui_submenu_page_callback' ); 
}

// Esta função faz o display do conteúdo da página
// No futuro iremos colocar tudo o que é visível aqui
function test_ui_submenu_page_callback() {
	echo '<div class="wrap">';
	echo '<h3>Teste UI</h3>';
	echo '</div>';

}

Esta entrada de submenu já está criada. Guarde o ficheiro e volte a fazer refresh ao browser, irá encontrar uma entrada de submenu “Teste UI” sob o menu de opções. Esta é a página onde iremos colocar os nossos controladores. Qualquer usuário poderá encontrar esse submenu, mas será fácil? Poderá ser uma tarefa dificil se você não disponibilizar instruções para seus usuários buscarem a página de configurações. Para isso existe uma forma bastante fácil de contronar esse problema.

CRIAR LINK PARA A PÁGINA DE OPÇÕES

Com isto vamos tentar garantir que qualquer opção do plugin não é perdida, e assim os nossos usuários descobrem facilmente o que fazer após ativar o plugin. Adicionar um link para a página de configuração ao lado dos links de desativar e editar é uma boa maneira de garantir isso:

<?php
add_filter( 'plugin_action_links', 'my_plugin_settings_link', 10, 2 );
function my_plugin_settings_link( $links, $file ) {
    if ( $file == 'plugin-test-ui/plugin-test-ui.php' ) {
        /* Insert the link at the end*/
        $links['settings'] = sprintf( '<a href="%s"> %s </a>', admin_url( 'options-general.php?page=plugin-test-ui' ), __( 'Settings', 'plugin-test-ui' ) );
    }
    return $links;

}

Se você dirigir-se agora à página de plugins irá encontrar nas acções do plugin um link direto para a página de configuração. Desta maneira seus usuários irão sentir-se mais confortáveis.

No próximo artigo iremos tratar de outros elementos nativos da administração. Vamos começar por construir os controladores da nossa página e aprender mais algumas regras na construção de plugins para WordPress.

Até breve!