Templates Wordpress e Tutoriais » Tutorials Wordpress

Como criar templates diferentes para single posts e categorias do WordPress

Paulo Faustino — Mon, 06 Feb 2012 16:30:42 +0000

Como criar templates diferentes para single posts e categorias do WordPress

O WordPress permite aos seus usuários criarem diferentes templates de páginas, mas infelizmente, não permite a criação de diferentes templates de posts, excepto através da criação de custom post types, que para a grande maioria dos usuários é um processo relativamente complexo de criar diferentes tipos/estilos de postagens para os seus blogs. No entanto, através de Custom Fields (campos personalizados), é possível criar diferentes tipos de templates para páginas. Mais uma vez, criar custom fields é algo que provavelmente a grande maioria dos usuários não-avançados terá dificuldade em reproduzir. Posto isto, restam-nos poucas soluções a ter em consideração, quando o objetivo é criar simples templates para single posts, tal como o fazemos para os templates de páginas.

Se você tem um blog e gostaria de ter dois templates diferentes para postagens diferentes em seu blog, ou dois templates diferentes para duas categorias diferentes do seu blog, saiba que existem duas formas bem simples de resolver esse problema, as quais explicamos de seguida neste nosso tutorial.

CRIAR TEMPLATES DIFERENTES PARA SINGLE POSTS

Para criar dois templates diferentes para single posts do WordPress, sugerimos a você que use o plugin Single Post Template, que lhe permite de forma fácil e cómoda, criar diferentes custom fields com um menu dropdown para a utilização de diferentes tipos de postagens. O processo de utilização é bem simples, veja:

Comece por efetuar uma busca indo na seção “Plugins > Adicionar Novo” do seu blog WordPress. Efetue uma busca por “Single Post Template”, e clique em “Instalar Agora” para instalar o plugin e ativá-lo em seu blog. Partiremos do princípio de que você ativa o seu plugin. Depois de ativado, avance para o próximo passo:

Depois de ter o plugin instalado, aquilo que você deverá fazer é criar novos templates para os seus single-posts. Para o fazer, recomendamos que você copie o código do seu ficheiro single.php, para um novo ficheiro, e coloque no início desse código o seguinte cabeçalho:

Tenha em consideração que se você quiser que o seu single.php seja diferente do outro template que deseja criar, terá de editar o código desse template e atribuir-lhe um novo diferente como por exemplo single-tutoriais.php, que será o template a usar nos seus tutoriais. Carregue esses ficheiros para dentro da diretoria /wp-content/themes/nomedotheme/ para que os mesmos fiquem automaticamente ativos e funcionais:

Não se esqueça que esses novos ficheiros terão obrigatoriamente de ter o cabeçalho que falámos anteriormente, caso contrário o plugin Single Post Template não conseguirá interpretar quais os ficheiros que são templates de single posts.

Ao carregar os ficheiros, o plugin “Single Post Templates” irá automaticamente perceber quais os templates de single posts, e disponibilizar um menu dropdown de seleção dentro do editor de artigos do WordPress. Por baixo da caixa de escrita de um novo artigo, irá aparecer agora o Custom Field para “Single Post Template” que contém todos os templates de single posts que você criou.

CRIAR TEMPLATES DIFERENTES PARA CATEGORIAS

No caso de você desejar aplicar a mesma técnica mas às categorias do seu blog WordPress, teremos de usar um processo relativamente diferente. Não procurámos por plugins que façam esta tarefa de forma automatizada, até porque na verdade não existe necessidade disso. Siga os passos para criar os seus templates de categorias diferentes usando o WordPress:

A hierarquia de templates do WordPress funciona seguindo uma lógica de análise. Ele irá procurar pelos templates seguindo uma determinada ordem, veja:

category-20.php
category.php
archive.php
index.php

Esta ordem significa que o WordPress irá primeiro procurar por um template category-6.php, depois pelo category.php, e assim sucessivamente até chegar ao index.php. Isto significa que criar diferentes tipos de templates no WordPress é na verdade um processo super simples e básico.

Para criar um template de categoria diferente do category.php, copie o código que está dentro do seu ficheiro category.php e guarde o novo ficheiro com o nome category-ID.php, onde o ID significa o ID da categoria onde você deseja que esse template seja aplicável. Se você não tiver um ficheiro category.php, você pode copiar o ficheiro archive.php ou index.php.

Para encontrar o ID da categoria que você deseja, entre na seção “Categorias” do seu blog WordPress, coloque o mouse em cima do nome da categoria, e olhe para a barra de endereço que aparece no rodapé do seu browser. Esse endereço contém o ID=X, sendo o X o valor ID da sua categoria. Não tem nada que enganar.

Para que tudo fique funcionando corretamente, você deverá carregar para dentro do seu servidor, na localização /wp-content/themes/nomedotheme/ os seus ficheiros de categorias. No exemplo em cima, criámos dois templates diferentes para a categoria 1 e categoria 65, mas você poderá criar aqueles que bem desejar, bastando colocar o ID da categoria no nome do ficheiro, e a estilização que você desejar. O WordPress irá ler esses templates antes de ler o category.php, diferenciando todos eles uns dos outros.

Até Já!

Artigos Recomendados

Como Criar Plugins para WordPress (Parte IV)

Vitor Carvalho — Tue, 24 Jan 2012 16:01:26 +0000

Como Criar Plugins para WordPress (Parte IV)

Este artigo é a quarta parte da série Como Criar Plugins para WordPress. O WordPress é uma das ferramentas para gestão de sites que tem vindo a crescer mais rapidamente nos últimos anos. Uma das razões provém da sua arquitetura altamente extensível através de plugins a par com a sua API simples de implementar. Recentemente um dos nossos leitores contatou-nos indicando que estava tendo dificuldades em encontrar tutoriais WordPress sobre criar plugins, e sugeriu-nos então que publicássemos uma série de artigos sobre como criar plugins para WordPress, ideia essa que decidimos aceitar!

SUMÁRIO

Permissões dos Usuários
Secrets e Nonces para autorização
Validação e saneamento dos dados postados
Formatando elementos para uso de SQL
Hábitos aconselhados

Falar em “segurança” no mundo da informática leva-nos sempre à noção de perigo constante. Para aqueles que se confrontam com estes problemas todos os dias, a segurança no código, seja este para a web ou para desktop, é sempre a última tarefa mais importante.

As ameaças são constantes: ataques de XSS, CSRF, injecções no SQL, ganho de permissões, vulnerabilidades e buracos de acesso.

Estas ameaças existem e qualquer autor de plugins do WordPress deve estar consciente disso! Se você distribuir o seu plugin na comunidade, deve ter em consideração ainda mais o facto de manter uma responsabilidade para com os dados dos usuários que usam os seus plugins.

Na escala dos principais problemas que os usuários toleram, o menor é a questão de segurança. Se for descoberto uma falha de segurança num plugin, os usuários acabam por deixar de usar os seus plugins e descredibilizam o autor.

Por estas razões, nunca devemos deixar de lado ou para segundo plano a questão da segurança, pois pode comprometer todo o nosso trabalho e reputação.

Segurança no WordPress

O WordPress já implementa várias soluções que ajudam nesta tarefa. Não é dificil e o tempo consumido é pouco, por isso vale sempre a pena!

PERMISSÕES DOS USUÁRIOS

Este é um dos temas mais importantes no que toca a segurança, senão o mais importante. Um bom sistema de permissões no software permite que muitos dos problemas de segurança seguintes não comprometam o sistema, pois brechas, validações, etc, embora possam existir necessitam por parte do usuário de permissão de acesso.

A API de Acessos do WordPress é versátil o suficiente para nos manter seguros dos perigos adjacentes. Nesta matéria existe uma função que nos faz todo o trabalho: current_user_can()

Esta função aceita como argumento uma capacidade ou papel, e testa se o usuário atual tem ou não essa permissão, retornando valores boleanos (true ou false). Caso o usuário não esteja logado, a função irá retornar sempre false – é aqui que reside a segurança para o exterior.

Papeis e Capacidades

As capacidades não são mais que uma tabela identificativa de determinadas ações que um usuário pode efetuar no WordPress. Para cada capacidade está associada uma ação. Sendo assim, um conjunto de capacidades, isto é, ações, formam um papel de usuário. Por exemplo: enquanto que com o papel de Administrador no WordPress, o usuário tem acesso a todas as ações existentes, ou seja, é-lhe atribuido todas as capacidades, um usuário com o papel de Subscritor, apenas tem a capacidade read, que lhe garante acesso apenas à Dashboard e ao perfil do usuário.

O sistema de papeis e capacidades é fantástico, pois permite-nos adicionar ou remover capacidades através de plugins, como visto nos artigos anteriores de como criar custom post types.

Função de avaliação de permissão de acesso

A melhor forma de checar se um usuário tem permissões de acesso é usando a função current_usar_can( $capacidade_ou_papel ). Esta função aceita como argumento tanto uma capacidade como um conjunto de capacidades, ou seja, um papel:

Com este snippet dentro de qualquer função do nosso plugin, nós evitamos que usuários sem permissão de acesso às ações que implementamos as acessem.

SECRETS E NONCES PARA OBTER AUTORIZAÇÃO

Este é um caso de ataque comum nos emails de spam e salas de conversação IRC ou de Instant Messaging.

Imagine que um usuário tem permissão para remover posts e encontra-se logado no sistema. No entanto, um outro usuário mal intensionado força o primeiro usuário a clicar num link encapsulado que mascara o link do site para deletar os posts. Como o usuário não sabe disto, ele acaba por remover os posts sem intensão. Acabámos de assistir a um ataque CSFR, ou seja, o usuário mal intensionado ganhou autorização.

Porque é que isto aconteceu? A resposta é: Autorização mas não Intensão!

A análise da anatomia deste ataque ajuda-nos a explicar este fenómeno. O usuário mal intensionado forçou o usuário logado no WordPress e com autorização para remover posts a praticar essa ação:

Como o usuário está logado no sistema e tem permissão, a função current_user_can() retornou true.
A permissão do usuário não checa se o usuário tem realmente a intensão de praticar aquela ação.

Como resolver esta situação? Felizmente o WordPress detém de um sistema de proteção contra este tipo de ataques. A solução é chamada de nonces, que são simplesmente strings de letras e números aleatórios que são criados durante o carregamento de uma página e colocados no final do link.

Este é um exemplo de um nonce colocado no link de remoção de um post para o lixo:

http://exemplo.com/wp-admin/post.php?post=54&action=trash&_wpnonce=89f5h3j54bc3

A string nonce encontra-se nesta parte _wpnonce=89f5h3j54bc3, em que a senha 89f5h3j54bc3 é gerada aleatoriamente segundo estas regras:

Uma senha só é gerada uma vez para um único usuário
A senha gerada só respeita uma ação (remover, editar, guardar, etc) para um objeto (post, página, link, etc)
Esta senha é um transient guardado por apenas 24h

Como criar uma senha nonce:

Existem dois métodos de gerar uma senha, sendo que um é mais habitual na geração de links e outro para formulários que usem o método POST.

O URL retornado seria hipoteticamente o mostrado em cima. O segundo parâmetro da função wp_nonce_url() é um identificador que deve ser único: use o prefixo do seu plugin em conjunto com o objeto referido e a ação a que respeita.

Outro método importante é a função wp_nonce_field():



  ID ); ?>

Esta função, tal como a sua função irmã, recebe como parâmetro um identificado único que diz respeitante à ação do formulário.

Verificar se um senha nonce está correcta:

Esta é a parte que realmente importa. Aqui iremos verificar através da função check_admin_referer() se a senha fornecida existe na base de dados de transients e se corrobora as obrigações descritas em cima.

No código seguinte, vou mostrar qual deve ser a implementação de segurança para um formulário igual ao que foi mostrado em cima:

Basicamente, este código primeiramente testa se o usuário tem permissão de acesso a estas configurações através da função current_user_can(), e, caso não tenha é gerado um erro do WordPress, e todo o script pára de correr nesse momento. Isto é conseguido com a função wp_die().

Na segunda parte do código, avaliamos se a ação pedida é legítima, ou seja, é proveniente do próprio WordPress e não de um link externo de alguém mal intensionado. Desta maneira garantimos que a segurança necessária para o nosso plugin.

Nós preparámos um documento PDF que contém as capacidades mais comuns associadas a um papel. Poderá fazer o download desse documento para sua referência

Faça o Download do documento de Capacidades e Papeis para WordPress

E aqui fica a versão em PNG:

VALIDAÇÃO E SANEAMENTO DOS DADOS POSTADOS

Depois de vermos dois principais tipos de ataque mais comuns que as comunidades blogueiras temem, existe um outro, que entre todos, é aquele que provavelmente o aluno deve ter mais conhecimento: ataque de força bruta.

Anteriormente vimos ataques de usuários mal intensionados, que tentam ganhar privilégios no sistema WordPress. Neste caso estamos a falar de um nível superior de ataque a que qualquer servidor está sujeito se não forem implementadas as medidas correctas.

Na anatomia deste ataque podemos destacar o facto de um visitante qualquer usar os campos de formulários para tentar injetar código SQL ou base64, de maneira a apoderar-se do próprio sistema operativo ou furtar informação legítima e proprietária. O WordPress em si já detém de um sistema de proteção contra este tipo de ataques, pois como já vimos na série anterior, para aceder ao banco de dados MySQL este usa o wrapper wpdb, no entanto devemos estar sempre cientes que devemos proteger os nossos formulários contra ataques de força bruta.

Exemplos de ataque de força bruta: No formulário de login, no campo password visitante digita um dos seguintes códigos:

qwerty123` OR 1 = 1
base64(‘fe2fjweo923fijoe9vwev924gjljvw9s0ierf2jp4vlkw…..’);
qwerty” /> Password:

O que acabou de acontecer aqui?

Se qualquer um destes códigos fosse colocado num formulário do seu blogue ou site, você teria sido vítima de um ataque de força bruta. No primeiro exemplo, o visitante tenta ganhar acesso ao formulário de login injetando código SQL. A ideia é muito simples: 1 = 1, logo será sempre verdade mesmo que o utilizador e a password não estejam corretos. O usuário teria ganho permissão para entrar no sistema. No segundo exemplo o usuário usou um código PHP codificado em base64, que poderia correr no ato de login. No terceiro caso o usuário usa HTML para tentar enganar o sistema, apresentando um novo input password.

Qualquer uma destes ataques deve ser ponderado quando construimos um sistema que processa os nossos formulários.

O seguinte código usa o switch como meio de prever estas situações. Assim caso o campo action não seja igual a uma dessas ações, então não faz nada:

Esta é a primeira maneira de nos protegermos: se uma variável deverá ter apenas uma range de valores, então mapeamos os valores e forçamos que isso aconteça.

Primeiro Validar no contexto:

Que é que isto quer dizer? Um input tem um contexto, ou seja, o tipo de valor que se está à espera nesse input. Então, vamos recebê-lo presumindo que o valor que o usuário lá colocou é desse tipo. Caso isso não aconteça será mais fácil descartar os valores. O WordPress e o PHP têm várias funções que nos fazem esse trabalho.

Valores Inteiros:

Enquanto que a função is_int() avalia se o input é um número inteiro retornando true ou false, a função intval() retorna o valor desse input como um valor inteiro, caso seja convertível. A função absint() retorna o valor absoluto, ou seja, não recebe inteiros negativos.

Textos arbitrários (strings):

No caso do valor esperado ser um texto arbitrário, como um nome, número de celular ou outro caso em que a complexidade do texto não nos permite avaliar mais especificamente que tipo de valor se trata, usamos a função wp_strip_all_tags():

Esta função elimina qualquer tag HTML, CSS, XML do seu input. É a função ideal para sanear inputs. Formulários com este sistema de proteção não se têm de preocupar mais com ataques de força bruta.

No entanto, há um tipo de ataque que merece uma firewall mais robusta: base64. Nós preparámos um plugin especial que atual como uma firewall para o seu sistema todo. Poderá fazer o download no link que se encontra no final do artigo.

Validar HTML:

O WordPress tem uma função que faz o saneamento de um input com texto HTML, removendo qualquer código malicioso porém mantendo as tags HTML. A função usada é wp_kses():

 array(),
  'strong' => array(),
  'a' => array(
     'href' => array(),
     'title' => array(),
  )
);

// Vamos limpar o input HTML
$html = wp_kses( $_POST['html'], $tags_aceites );

?>

Esta função aceita como parâmetros o HTML em causa e um array de tags e seus atributos que nós aceitamos neste HTML. Qualquer tag que não estejam dentro deste array será removida.

FORMATANDO ELEMENTOS PARA USO DE SQL

Vimos no artigo anterior quais os métodos para aceder ao banco de dados, através da classe WPDB. Vamos aprender mais um método, este protege o código SQL contra qualquer tipo de SQL num input.

prefix}_posts WHERE id = %d;";

  // Este é o ID do post que queremos remover
  $id = absint( $_POST['id'] );

  // O método prepare faz a limpeza do SQL.
  // Recebe o SQL com o placeholder e o $id que
  // substituirá o %d no código SQL.
  $sql = $wpdb->prepare( $sql, $id );

  // Vamos então correr o SQL seguro
  $wpdb->get_results( $sql );

}

?>

O método prepare recebe o número de parâmetros iguais ao número de placeholders que existirem no código SQL. Com este sistema de proteção acabámos de excluir a última hipótese de ataque ao servidor: ataque por força bruta com SQL.

HÁBITOS ACONSELHADOS

Sempre que criar um plugin, tente encontrar brechas de segurança. Pense em formas de como é que um usuário malicioso poderia atuar e experimente. Considere também colocar-se no papel de um usuário leigo em informática, e que tipos de uso errados poderia ele dar ao seu plugin.
Sempre que projetar um plugin tenha em consideração a segurança desde o inicio do projeto.
Mantenha sempre o seu plugin atualizado com as novas versões do WordPress.
Comente sempre o seu código. Assim sempre que tiver que o rever será mais fácil entender o que determinada função ou parte do código fará. Na documentação do código use sempre palavras chave como TODO ou TOFIX para indicar melhoramentos a serem feitos nas próximas versões.
Tente sempre ser paragmático quando escrever código e focar-se na lógica do problema.
Prefira decisões em vez de opções. Assim estará a diminuir o número de variáveis com que se tem que preocupar.
Divida o seu código em funções. Fica mais organizado e será mais fácil mantê-lo futuramente.

PLUGIN FIREWALL PARA WORDPRESS

Falamos de todos os ataques possíveis e resolvemos todos menos um: ataque com código codificado em base64. Como este tipo de ataque é muito genérico e normalmente ocorre via HTTP ou GET, a solução passa por criar um plugin que atua como firewall.

Nós, da Escola WordPress, criamos um plugin pequeno, muito simples mas bastante robusto que bloqueia qualquer pedido URL que tenha um comprimento exageradamente grande ou que contenha algumas palavras que indiciem que seja um ataque: base64, UNION, JOIN, etc.

Faça Download do Plugin Firewall para WordPress

Instalação:

Faça o upload ou instale a partir do menu “Adicionar Plugin”
Após a instalação, ative o plugin.

Não é necessário fazer mais nada, a partir de agora já se encontra protegido contra ataques via GET e HTTP.

NOTAS FINAIS

Escrever código para WordPress não é dificil, e interligar código já feito muito menos. No entanto deverá ter sempre em mente que, como qualquer bom software, irá sempre encontrar vulnerabilidades no código. Assim, é sempre necessário estar atento a problemas que possam surgir.

Espero que tenham gostado desta série e que vos tenha sido útil.

Até breve,

Vitor

Artigos Recomendados

Como Criar Plugins para WordPress (Parte III)

Vitor Carvalho — Wed, 18 Jan 2012 18:16:30 +0000

Como Criar Plugins para WordPress (Parte III)

Este artigo é a terceira parte da série Como Criar Plugins para WordPress. O WordPress é uma das ferramentas para gestão de sites que tem vindo a crescer mais rapidamente nos últimos anos. Uma das razões provém da sua arquitetura altamente extensível através de plugins a par com a sua API simples de implementar. Recentemente um dos nossos leitores contatou-nos indicando que estava tendo dificuldades em encontrar tutoriais WordPress sobre criar plugins, e sugeriu-nos então que publicássemos uma série de artigos sobre como criar plugins para WordPress, ideia essa que decidimos aceitar!

PÁGINAS DE PLUGINS NA ADMINISTRAÇÃO

Alguns plugins mais complexos exigem que o usuário, após a instalação, escolha algumas opções para ativar funcionalidades. É o caso de alguns plugins de cache, tais como o W3 Total Cache. Essa necessidade prende-se com o facto do criador do plugin querer, numa única instalação fornecer o máximo de funcionalidades dentro da área de atuação do mesmo.

Já todos vimos plugins que criam subpáginas no menu da administração. A maior parte das abordagens estão corretas, porém, a meu ver, são vários os autores de plugins que pecam de duas maneiras:

Criar uma página nova para colocar apenas uma ou duas opções.
Fornecer opções a mais ao usuário.

A primeira parte prende-se com a economia de espaço. Se, por exemplo, um plugin for escrito para de alguma maneira alterar links internos do site e houver necessidade de apresentar uma ou duas opções, o ideal seria aproveitar a página de Links Permanentes na administração e colocar lá essas opções, em vez de se criar uma nova página.

Fornecer muitas opções pode baralhar o usuário. A política do WordPress quanto a isto é bastante clara – fornecer o mínimo de opções e optar pela configuração que abranja mais usuários. Esta ideia traz organização e simplicidade ao WordPress.

Na verdade você pode criar plugins de plugins, isto é, plugins que extendem as funcionalidades de outros plugins, e assim, abranger um nicho de usuários com necessiades específicas.

Um dos casos mais extravagantes neste campo é o plugin para envio e gestão de newsletters MeeNews. Quando este plugin apareceu ocorreu um boom de reviews em vários blogs da especialidade. Muitos afirmavam ser o melhor plugin para WordPress. Na verdade, ele funciona bastante bem, mas apenas quando configurado corretamente. Por ter demasiadas opções, torna o processo de configuração exageradamente complexo e, sendo assim, os usuários acabam por desistir da instalação. Os factos estão à vista: o ranking está bastante baixo e o forum tem muitos threads não respondidos.

Estando aqui o aviso feito, passemos então ao estudo de como criar páginas de opções e agregar opções a páginas nativas do WordPress.

Como criar uma página na administração do WordPress

Vamos criar uma página de administração dentro do menu “Opções” (Settings em inglês). Para isso servimo-nos da nosssa tão bem conhecida add_action():



  
  As Minhas Opções
  
    // Todo o conteúdo tem de vir aqui dentro

Como explicado no trecho de código, este é o mínimo necessário para se criar uma página. A função screen_icon() imprime o icon correspondente na página. Todos os inputs têm que ser guardados pela página options.php.

Registar opções de input para a página

Usando a API de Opções nativa do WordPress é a melhor maneira de podermos garantir que os dados serão armazenados e geridos pelo WordPress, e que este aplica todas as medidas de segurança necessárias aos inputs.

Para isso é necessário registar primeiro quais as novas opções que estamos a acrescentar e como é que as validamos:

Cabeçalho da página';
}

function ewp_opcao_1_input() {
  // Vamos primeiro buscar a opção registada em cima...
  $opcao = get_option( 'ewp_as_minhas_opcoes' );
  $opcao_1 = $opcao['opcao_1'];

  // ... e agora vamos imprimir o campo de input com a opção
  echo '';

}
?>

Esta parte pode ser um tanto complicada, mas iremos por partes.

A primeira função register_setting() é responsável por dizer ao WP que vai ser criada uma nova opcção chamada ewp_as_minhas_opcoes sendo que esta deverá ser guardada na base de dados com o mesmo nome. Desta maneira o WordPress sempre que encontrar esta opção numa submissão de formulário na administração, saberá que deve atualizar a base de dados com o seu valor. De outro modo, se a opção não fosse registada, o WP apenas a ignorava.

A função add_settings_section() vai criar uma nova secção com um cabeçalho. Esta é a forma indicada de agrupar as várias opções. existem plugins que implementam uma estrutura de abas nestas páginas, sendo assim é necessário seguir esta forma de organização para que funcione com os usuários que pretendem a navegação por abas. Esta função aceita quatro argumentos:

Um ID arbitrário para identificar a secção nos inputs.
O cabeçalho que será exibido. Pode-se usar o sistema de tradução universal incluído no WordPress __( ‘String para traduzir’ ).
A função a chamar, para que possa ser colocado algum texto depois do cabeçalho e antes das opções.
A slug (link) da página onde se pretende que a secção apareça. Se colocar por exemplo options-general.php esta secção aparecerá na página de Opções Gerais.

A função add_settings_field() adiciona uma opção e imprime o HTML necessário. Aceita como argumentos:

Um identificador do campo / opção.
A label para esse campo.
A função que irá imprimir o HTML.
A slug da página onde quer que apareça.
A secção onde quer agrupar as opções.

Esta função pode ser usada para criar vários campos de opções. Por exemplo, se você quiser criar cinco campos individuais, terá que chamar cinco vezes esta função, cada uma chamando a sua função específica no código. Também poderá criar as secções que queira.

A aqui uma screenshot do resultado final:

ADICIONAR CAMPOS NAS PÁGINAS DA ADMINISTRAÇÃO JÁ EXISTENTES

Claro que é possível, como já foi dito em cima, criar campos de opções e associá-los a páginas já existentes em vez de se criar uma nova página.

Para exemplificar isso, vamos criar um campo novo na página de Privacidade:

E este é o resultado final:

ACESSO À BASE DE DADOS

O WordPress usa pouco SQL para acessar a base de dados. Em vez disso, toda a conecção é efetuado através da class WPDB, baseado no código EzSQL. Esta classe gere todas as tabelas da base de dados e seus conteúdos. É responsável por toda a conexão do WordPress.

É possível obviamente usarmos essa classe para criarmos a nossas próprias tabelas, ou simplesmente retirar ou guardar dados usando SQL. Embora os developers sugerem a utilização dos Custom Post Types e da tabela wp_posts para guardar dados, por vezes é necessário criar uma tabela específica pois a sua estrutura é muito diferente.

Por vezes, como é o caso do nosso exemplo, criar uma nova tabela pode ser mais benéfico. Se você pretender guardar os IPs dos seus usuários que visitam o site, é preferível colocá-lo noutra tabela, pois devido à grande quantidade de dados envolvida, usar a wp_posts poderia causar lentidão do site.

Criando uma nova tabela na base de dados

prefix . 'hits';

  // Se a tabela não existe vamos criá-la
  if ( $wpdb->get_var( "SHOW TABLES LIKE '$tablename'" ) != $tablename ) {

    $sql = "CREATE TABLE `$tablename` (
         `id` INT( 11 ) NOT NULL AUTO_INCREMENT,
         `hit_ip` VARCHAR( 100 ) NOT NULL,
         `hit_date` DATETIME
    );";

    // Para usarmos a função dbDelta() é necessário carregar este ficheiro
    require_once( ABSPATH . 'wp-admin/includes/upgrade.php' );

    // Esta função cria a tabela na base de dados e executa as otimizações
    // necessárias.
    dbDelta( $sql );

  }

}
?>

Para completar o nosso código de registo dos IPs dos usuários, vamos criar criar o nosso procedimento para guardar os registos na tabela:

get_var("SELECT id FROM ".$wpdb->prefix."hits WHERE hit_ip = '$ip' AND hit_date BETWEEN '.date("Y-m-d H:i:s", time() - 10 ).' AND '$current_time';");

  // Checamos se não existe nenhum registo procedemos
  if ( ! $id ) {
    // Registar os IPs na base de dados
    $novo_ip = array(
      'hit_ip' => $ip,
      'hit_date' => $current_time,
    );

    // Guardar os valores na tabela
    $wpdb->insert( $wpdb->prefix . "hits", $novo_ip );

  }

}
?>

E aqui temos um plugin que poderá ser colocado no functions.php do seu tema.

Poderá fazer o download deste plugin no rodapé deste artigo.

Neste trecho de código nós vimos dois novos métodos do objeto $wpdb. O método insert() insere novos dados na base de dados usando apenas um array. O método get_var(), usando SQL, conseguimos buscar dados às tabelas da base de dados.

Existem também outros métodos:

get_row( $sql ) : usando SQL, você poderá ir buscar qualquer linha na base de dados. O método retorna um array associativo.
get_results( $sql ) : caso pretenda buscar várias linhas no SQL, este método retorna-lhe um array de arrays, cada um deles associativo.
update( $nome_da_table, $data ) : este método é similar ao insert(), porém você deverá passar a chave primária (id) da linha que quer atualizar.

Para mais informações acerca desta classe, poderá ver aqui no site do Codex.

PLUGGABLE FUNCTIONS

As funções plugáveis, são funções carregadas pelo WordPress após todos os plugins estarem carregados, permitindo aos autores reescreverem essas funções da maneira que quiserem.

Todas as funções dentro do ficheiro wp-includes/pluggable.php podem ser rescritas. Basta o autor de plugin colocar no ficheiro principal uma função com o mesmo nome.

É muito natural os autores reescreverem a função wp_mail() – que se encontra nesse ficheiro – para poderem enviar emails do WordPress através de um servidor SMTP.

Não me vou alongar nesta matéria pois as possibilidades são inifinitas, ficando apenas a nota que você pode reescrever as funções que se encontram nesse ficheiro a seu gosto.

DOWNLOAD DO CÓDIGO

Este código serve apenas pra fins didáticos e não deve ser usado em sites de produção. Poderá fazer o download do código didático aqui.

Download do Código do Artigo

DOWNLOAD DO PLUGIN DE REGISTOS DOS IPS

Criámos um plugin especial para este artigo, baseado no código apresentado.

Este plugin regista os IPs dos seus usuários numa tabela customizada para depois poder acessar através de uma página da administração, no menu Ferramentas.

Plugin Registo de IP

NOTAS FINAIS

Ao criar o seu plugin tenha sempre em conta ser o mais responsável para com a instalação dos seus usuários. Se você tiver a necessidade de criar uma tabela na base de dados, por exemplo, faça-o apenas na ativação do plugin e não se esqueça de implementar uma função de remoção da tabela na desinstalação do plugin. O procedimento é o mesmo.

No próximo artigo iremos falar apenas e exclusivamente sobre segurança nos plugins e no WordPress em geral, hábitos e padrões que devem ser seguidos, matéria que tenho andado a adiar nos últimos artigos.

Espero que este artigo tenha sido útil, continuem a percorrer esta série.

Abraço,

Vitor

Artigos Recomendados

Como colocar comentários do Facebook no WordPress sem precisar de plugins

Paulo Faustino — Tue, 17 Jan 2012 17:05:53 +0000

Como colocar comentários do Facebook no WordPress sem precisar de plugins

Já aqui falámos na Escola WordPress sobre sobre como colocar comentários do Facebook no seu blog WordPress e também como usar o Facebook Insights no seu blog WordPress. No entanto, no guest-post de hoje, o Rodrigo pretende explicar-nos, passo-a-passo de forma prática, como colocar os comentários do Facebook no WordPress sem precisar de plugins. Tendo em consideração que o uso de plugins pode deixar o seu blog mais lento, pelos constantes pedidos ao banco de dados, esta solução do Rodrigo torna-se simplesmente fantástica para quem deseja tirar o máximo partido dos comentários do Facebook no seu blog em WordPress.

CRIANDO UMA NOVA APLICAÇÃO

Para iniciar nossos trabalhos, devemos criar uma aplicação no Facebook (Clique aqui para acessr a página)
Clique em “Aplicativos”:

Depois em “+ Criar novo aplicativo:

Após isto, aparecerá uma janela pop-up pedindo as informações do aplicativo, dê à ele um Nome (Lembrando que sua conta do facebook deve ser confirmada com cartão de crédito, ou celular).

Criado o aplicativo aparecerá esta janela, com as informações do aplicativo:

Pode fechar a janela, agora vamos a segunda parte do nosso tutorial.

CRIANDO O SISTEMA DE COMENTÁRIOS

Esta parte é facil e não demora nem 5 minutinhos. Vamos começar?

Primeiramente acesse a página de plugins do Facebook, clicando aqui.
Clique no link “Comments”, como veremos abaixo:

Esta é a página de configuração dos comentarios, coloque a url do seu blog (No meu caso http://jegueass.org), o número de comentários que deseja exibir (No meu caso 15, para não sobrecarregar a página), a largura (no meu caso 710px) e o “Esquema de Cores” Dark ou Light (Como o tema do meu blog é escuro, escolhi o sistema “Dark” pois dará o contraste certo para meu blog).

Agora é só clicar em “Get Code” escolher o aplicativo criado, o modo de implementação e depois copiar o código para o blog. (Eu Escolhi o modo HTML5, pois é mais simples a alteração do tema).

IMPLEMENTANDO O CÓDIGO NO BLOG

Agora é que vem a parte mais simples de todo o tutorial, a implementação do código.

Acesse a página do editor de temas do wordpress, e abra o “footer.php” ou “header.php (No meu caso, implementei no “footer.php”), procure uma boa área e coloque o primeiro código sugerido pelo facebook.

Feito isso acesse o “single.php”, ache a área que preferir para implementar o código e cole.

Aqui está a mágica, lembra quando colocamos a URL de nosso blog lá na hora de configurar o plugin? Mudaremos ela agora, seu código ficará parecido com o meu acima, procure o trecho que diz:

data-href="http://www.jegueass.org/

Ao lado da sua URL, após a barra, coloque o seguinte código:

?p=

Este código irá puxar a ID do seu post automaticamente e incluirá após a sua URL, fazendo assim, os comentários do facebook mudarem a cada post.

Abraços

O artigo de hoje foi um guest post do Rodrigo, blogueiro que escreve no blog Jegueass.

Artigos Recomendados

Como Criar Plugins para WordPress (Parte II)

Vitor Carvalho — Thu, 12 Jan 2012 17:26:44 +0000

Como Criar Plugins para WordPress (Parte II)

Este artigo é a segunda parte da série Como Criar Plugins para WordPress. O WordPress é uma das ferramentas para gestão de sites que tem vindo a crescer mais rapidamente nos últimos anos. Uma das razões provém da sua arquitetura altamente extensível através de plugins a par com a sua API simples de implementar. Recentemente um dos nossos leitores contatou-nos indicando que estava tendo dificuldades em encontrar tutoriais WordPress sobre criar plugins, e sugeriu-nos então que publicássemos uma série de artigos sobre como criar plugins para WordPress, ideia essa que decidimos aceitar!

COMO É QUE OS PLUGINS INTERAGEM COM O WORDPRESS?

Na primeira parte fizemos uma introdução ao desenvolvimento de plugins para WordPress. Falámos sobre os tipos de plugins que existem, convenções usadas e funções base para começarmos o nosso desenvolvimento. No entanto, uma secção ficou em aberto: como é que os plugins interagem com o WordPress.

Como adiantado no artigo anterior, o WordPress apresenta várias APIs para que plugins e temas possam interagir facilmente e criar novas ou alterar funcionalidades:

Plugin – Providencia as hooks – um conjunto de acções e filtros – para que os plugins possam interagir em várias partes do WordPress de maneira muito simples;
Widgets – Permite colocar pedaços de código nas sidebars registadas do nosso tema, fazendo com que haja o display de várias informações na parte do site.
Shortcode – Permite que um editor chame uma função PHP definida no plugin de maneira simples no editor de posts.
HTTP – Esta API é um meio standard para fazer chamadas HTTP a servidores remotos sem que o autor do plugin se tenha que preocupar se existe cURL instalado. Basta chamar através desta API e ela preocupa-se em determinar qual o método de chamada mais apropriado para o servidor em que corre.
Settings – Permite a inserção de campos de opções personalizados na administração do WordPress para que estes possam ser usados pelos plugins facilmente. Com esta API o autor não se tem que preocupar com segurança nos ataques CRSF e XSS – ela faz tudo por si.
Dashboard Widgets – Permite criar e alterar widgets para a Dashboard da administração e com controlo de acessos.
Rewrite – Possibilita a criação de rewrite rules personalizadas para vários pontos do código dos plugins.
Transients – Sistema de cache básico persistente na base de dados com tempo de expiração. Pode ser usado para adicionar opções temporárias.
Database – Acesso rápido à base de dados sem haver necessidade de conhecimento de SQL. Permite inserir, atualizar, remover e selecionar registos.
Pluggable Functions – Funções providenciadas pelo WordPress que podem ser completamente redefinidas. É o caso da função wp_mail() que pode ser alterada para usar um servidor SMTP em vez do atual Sendmail.

Pelo facto destas APIs serem muito grandes iremos principalmente focar-nos em exemplos e dividir entre este e o próximo artigo as APIs.

PLUGIN ACÇÕES E FILTROS

Ao contrário da maior parte dos CMSes e Frameworks em PHP, o WordPress é construído em cima de uma estrutura de procedimento, usando classes apenas dentro da Core como forma de organização e não de estrutura. Ao invés de usar uma estrutura MVC com a herança de classes, o WordPress é “montado” através de Hooks – acções e filtros – que são “disparados” em momentos específicos, chamando funções registadas dentro de cada uma das acções ou filtros. Este é um dos grandes entraves para developers que migram de outras plataformas, no entanto, na minha opinião, a forma como o WordPress está construído trás muito mais vantagens. Posso enumerar algumas:

Classes em PHP são um meio dispendioso de recursos para estruturar códigos, pois de cada vez que se instância um novo objecto a carga de CPU é grande, além de que todos os métodos e propriedades de cada um dos objectos permanece na RAM até à sua remoção. Deve-se sempre avaliar se é realmente necessário criar uma classe ou usar apenas umas funções para fazer o nosso trabalho.
Em quase todo o código do WordPress é possível filtrar dados e acionar acções, sem que haja um aumento do tempo de resposta e carregamento do WordPress.
Ainda assim, é possível usar-se um modelo MVC nos seus plugins, basta que os métodos da classe pai (controller) implementem as acções e filtros apropriados ao nosso trabalho.

ACÇÕES E FILTROS

A implementação de uma hook no WordPress é feita pela função do_action( $id, $args ) na parte do código onde se pretenda dar a possiblidade de inserir novas acções.

A título de exemplo, no ficheiro wp-includes/general-template.php, linha 1580 (versão 3.3.1), é definida a função wp_footer(), normalmente incluída no template footer.php dos temas:

/**
 * Fire the wp_footer action
 *
 * @since 1.5.1
 * @uses do_action() Calls 'wp_footer' hook.
 */
function wp_footer() {
    do_action('wp_footer');
}

Esta função apenas apresenta no seu conteúdo do_action(‘wp_footer’); . Este é um bom exemplo do poder modular que as hooks têm no WordPress, pois qualquer função registada na hook wp_footer, pode ser removida.

Registar Funções numa Hook

A função add_action( $id, $nome-da-funcao, $prioridade, $numero-de-argumentos ); regista numa hook uma função qualquer comum para ser “disparada” nesse momento.

Por exemplo:

add_action( 'wp_footer', 'funcao_copyright', 10, 0 );

function funcao_copyright() {
   echo 'Copyright (c) Escola WordPress';
}

Assim, quando for chamada a função wp_footer() no nosso template, a função que acabámos de registar também correrá mostrando o copyright da Escola WordPress.

Remover Funções duma Hook

A função remove_action( $tag, $function_to_remove ); permite remover qualquer função registada para qualquer hook.

Por exemplo, pegando no código anterior, iremos registar a função e voltar a removê-la da hook:

add_action( 'wp_footer', 'funcao_copyright', 10, 0 );

function funcao_copyright() {
   echo 'Copyright (c) Escola WordPress';
}

remove_action( 'wp_footer', 'funcao_copyright' );

Se corresse este código, o copyright não iria aparecer pois, o que acabámos de fazer foi registar a função para em seguida removê-la.

Claro que este código não faz sentido, pois seria um gasto de processamento desnecessário, porém serve para demonstrar o poder das hooks. Desta forma, damos ao developer a possibilidade de remover seja o que quiser, mesmo uma função que esteja na core do WordPress e poder implementar a sua própria função customizada sem ter que alterar o código da core.

O que são os filtros?

Ao contrário das acções, os filtros servem, nem mais nem menos, para filtrar informação passada pelo WordPress em determinados momentos. Funciona da mesma maneira que as acções, porém as funções registadas nessas hooks recebem como argumento um array de variáveis com informações para serem filtradas. Esse mesmo array, já com os filtros customizados serão retornados no final do procedimento da função.

Registar e Remover Funções de filtro

As funções add_filter() e remove_filter() aceitam os mesmos argumentos e comportam-se da mesma maneira, excepto no argumento das funções registadas:

// Acrescentar Bold nos títulos dos artigos via add_filter
add_filter( 'the_title', 'titulo_acrescenta_bold' );

function titulo_acrescenta_bold( $titulo ) {
   return ''.$titulo.'';
}

Neste caso simples, recebemos uma variável que, depois de modificada deve retornar a função.

Acrescentar Hooks customizadas nos plugins

Esta API pode ser (e deve ser) usada também nos plugins e temas para que outros developers possam também eles hackear os seus plugins sem ter que alterar o seu código.

A função do_action( ‘nome_da_hook’ ); pode ser colocado em qualquer lugar do código, basta ter em atenção para que o id da hook já não esteja registado algures no WordPress. Para isso, prefixe-o com as iniciais do seu plugin, por exemplo, por forma a evitar esse problema.

...
// Código do seu plugin
do_action( 'escolawp_rodape' );
A função apply_filter faz o mesmo, mas para filtrar informação, por exemplo um array:

$elementos = apply_filters( 'escolawp_filtro_array', array( 'a' => 'b', 'c' => 'd' ) );
foreach( $elementos as $elemento )
// Código qualquer

Neste caso estamos a dar a possibilidade de developers manipularem o conteúdo do array.

WIDGETS

Esta API já foi muito falada aqui na escola, dexamos aqui o link para um dos artigos que explica como criar widgets para WordPress. Essa implementação pode ser facilmente transportada para um plugin.

SHORTCODES

Esta API é muito útil e fácil de implementar. Permite que qualquer utilizador possa correr código PHP dentro de um post ou página recorrendo apenas à inserção uma tag do tipo [tag argumento="valor"] no lugar onde pretende.

Se registar a função add_shortcode( ‘tagqualquer’, ‘funcao_qualquer’ ); permite que o utilizador insira a tag [tagqualquer] num post para que a funcao_qualquer possa ser chamada na posição onde o utilizador pretende.

add_shortcode( 'cumprimentos', 'escolawp_cumprimentos' );

function escolawp_cumprimentos() {
  echo 'Com os melhores cumprimentos,
Escola WordPress';
}

A implementação acima dá a possibilidade ao autor do post de incluir [cumprimentos] no final do post e que no site apareça a string HTML que se encontra na função.

Para mais ideias sobre shortcodes, leia este artigo.

HTTP

Esta API pretende centralizar todas as chamadas HTTP via PHP a páginas externas sem que o developer se tenha que preocupar qual o método instalado no servidor.

Nesta API existem 3 funções importantes:

$url = 'http://www.escolawp.com';
$argumentos = array(
  'timeout' => 5, // Desiste da chamada após 5 segundos de inatividade
  'useragent' => 'Mozilla/5.0', // Permite alterar o "browser" de PHP para Firefox por exemplo
  'sslverify' => true // Verifica se os certificados SSL são válidos em ligações HTTPS
);

// Faz uma ligação à URL com uma chamada GET
$resultado_get = wp_remote_get( $url, $argumentos );

// Faz uma ligação à URL com uma chamada POST e acrescenta
// dados POST ao argumento em forma de array
$argumento['body'] = array( 'user' => 'Bob', 'pass' => 'qwerty' );
$resultado_post = wp_remote_post( $url, $argumentos );

// Para ligações onde é apenas necessário o cabeçalho,
// como por exemplo, se se pretende saber apenas se determinado
// URL encontra-se online, usa-se o método HEAD
$resultado_head = wp_remote_head( $url, $argumentos );

Qualquer uma desta funções irá retornar um array de arrays com o cabeçalho, o corpo e a resposta. A título de exemplo, aqui fica um retorno genérico de uma chamada por uma destas funções:

Array
(
    [headers] => Array
        (
            [date] => Thu, 30 Sep 2010 15:16:36 GMT
            [server] => Apache
            [x-powered-by] => PHP/5.3.3
            [x-server] => 10.90.6.243
            [expires] => Thu, 30 Sep 2010 03:16:36 GMT
            [cache-control] => Array
                (
                    [0] => no-store, no-cache, must-revalidate
                    [1] => post-check=0, pre-check=0
                )

            [vary] => Accept-Encoding
            [content-length] => 1641
            [connection] => close
            [content-type] => application/php
        )
    [body] => Isto é um site!
    [response] => Array
        (
            [code] => 200
            [message] => OK
        )

    [cookies] => Array
        (
        )

)

Estas funções são portanto muito úteis para developers de WordPress e devem ser usadas em vez do uso de métodos nativos como o cURL ou a função PHP get_file_contents() que sofrem do problema de poderem ou não existir em diversas instalações PHP.

OPÇÕES

O WordPress implementa a tabela wp_options com uma estrutura que permite salvar qualquer valor na forma de par chave => valor, sendo que o valor pode ser qualquer tipo nativo do PHP, seja este uma string, array, objecto ou uma instância.

Para isso existem quatro funções que podem ser usadas em qualquer altura para acicionar, receber, remover ou atualizar valores dessa tabela.

$url = 'http://escolawp.com';

// Adicionamos um valor à tabela wp_options
add_option( 'escolawp_url', $url );

// Recebemos esse valor para uma variável
$url_get = get_option( 'escolawp_url' );

// Atualizamos o valor com novos dados
update_option( 'escolawp_url', $url . '/pagina-link' );

// e por fim removemos o valor da tabela
delete_option( 'escolawp_url' );

Estas funções são muito simples, fáceis de usar e essenciais para qualquer developer WordPress. Elas permitem de uma forma rápida guardar permanentemente e obter valores da base de dados para uso nos plugins.

O exemplo seguinte guarda um array na tabela:

add_option( 'escolawp_url', array(
  'url' => $url,
  'name' => 'Escola WordPress',
  )
);

Desta forma, se obtiver este valor através da função get_option( 'escolawp_url' ) irá também retornar-lhe o array tal e qual como quando o guardou. Fantástico não é?

Acontece que estes registos são permanentes, ou seja, não podem ser usados como meio de guardar sessões, por exemplo, pois necessitaria de um tempo de expiração a partir do qual os valores seriam apagados da base de dados. Foi a pensar nisto que foi criado os transients.

TRANSIENTS

Tal como o próprio nome indica, são "coisas" que transitam de um estado para o outro. Um transiente não é mais que um valor que permanece guardado na base de dados por um certo período de tempo, sendo eliminado após ter expirado.

Esta API é muito útil para guardar, por exemplo, sessões em base de dados, em vez de nos cookies do browser.

Para se criar um transient na base de dados usamos a função set_tansient(). As funções get_transient() e delete_transient() recolhem e removem respetivamente os valores da base de dados:

// Guardar o valor MD5 do login do utilizador por 1 hora
set_transient( 'ewp_user_login_'.get_current_user_id(), md5( get_current_user_id() ), 3600 );

A função aceita 3 argumentos: um nome para o valor, o valor em si e o tempo em segundos até expirar.

// Verificar se o Utilizador atual ainda tem um login feito à menos de uma hora
$login = get_transient( 'ewp_user_login_'.get_current_user_id() );
if ( $login )
 // o utilizador tem login efetuado à menos de uma hora
else
 // considera-se que o utilizador não tem login efetuado

Se chamar a função delete_transient( 'ewp_user_login'.get_current_user_id() ); ela irá remover qualquer vestígio deste valor da base de dados independentemente se ainda não estiver expirada.

O uso de transients pode ser por vezes abusivo. Ao criar o seu plugin, tenha em atenção em reduzir o número de chamadas à base de dados pois poderá aumentar o tempo de resposta do seu site caso o número de chamadas à base de dados seja grande.

NOTAS FINAIS

No desenvolvimento de plugins é necessário ter em atenção a questão da economia de recursos. Para isso deixo umas breves notas finais:

Nas APIs de base de dados, é natural os developers "abusarem" no número de chamadas, ora dividindo várias opções separadamente, chamando sucessivas vezes o get_option(), ora usando muitos transients. A solução na maior parte das vezes está em agrupar dados.

Opte por guardar todos os dados numa única chamada add_option() ou set_transient()
Ao chamar get_option() faça-o apenas uma vez, guardando o seu valor numa variável que pode ser reutilizada
Não guarde conteúdo gerado, como HTML de uma página inteira na base de dados. Ao contrário daquilo que seria suposto, estas funções comportam-se muito mal com uma grande quantidade de dados. Opte por guardar um array de dados e gerar o HTML on-the-fly. Use apenas cache para guardar páginas de HTML inteiras e nunca a base de dados.

Espero que tenha gostado deste artigo. Espero ve-lo para a próxima semana na terceira parte que falará sobre as restantes APIs e segurança ao nível de plugins. Ah, e não se esqueça de comentar.

Abraço,

Vitor

Artigos Recomendados

Como Criar Plugins para WordPress (Parte I)

Vitor Carvalho — Tue, 03 Jan 2012 17:00:20 +0000

Como Criar Plugins para WordPress (Parte I)

O WordPress é uma das ferramentas para gestão de sites que tem vindo a crescer mais rapidamente nos últimos anos. Uma das razões provém da sua arquitetura altamente extensível através de plugins a par com a sua API simples de implementar. Recentemente um dos nossos leitores contatou-nos indicando que estava tendo dificuldades em encontrar tutoriais WordPress sobre criar plugins, e sugeriu-nos então que publicássemos uma série de artigos sobre como criar plugins para WordPress, ideia essa que decidimos aceitar!

O QUE SÃO OS PLUGINS NO WORDPRESS?

Um plugin no WordPress é uma porção de código escrito em PHP que é incluído na pasta wp-content/plugins e que aumenta as funcionalidades do WordPress através da implementação de Hooks – acções e filtros – em várias partes do código do WordPress.

Após a activação de um plugin, o WordPress encarrega-se de registá-lo sempre que há uma chamada ao site, analisando que acções e filtros é que ele implementa.

Desta maneira a extensabilidade torna-se algo muito simples de conquistar e de aprender.

COMO É QUE OS PLUGINS INTERAGEM COM O WORDPRESS

Existem várias APIs que o WordPress fornece para que os plugins possam trabalhar funcionalidades usando-as. Cada API, ou application programming interface (interface de programação da aplicação), ajuda a interagir de diferentes maneiras.

Plugin – Providencia as hooks – um conjunto de acções e filtros – para que os plugins possam interagir em várias partes do WordPress de maneira muito simples;
Widgets – Permite colocar pedaços de código nas sidebars registadas do nosso tema, fazendo com que haja o display de várias informações na parte do site.
Shortcode – Permite que um editor chame uma função PHP definida no plugin de maneira simples no editor de posts.
HTTP – Esta API é um meio standard para fazer chamadas HTTP a servidores remotos sem que o autor do plugin se tenha que preocupar se existe cURL instalado. Basta chamar através desta API e ela preocupa-se em determinar qual o método de chamada mais apropriado para o servidor em que corre.
Settings – Permite a inserção de campos de opções personalizados na administração do WordPress para que estes possam ser usados pelos plugins facilmente. Com esta API o autor não se tem que preocupar com segurança nos ataques CRSF e XSS – ela faz tudo por si.
Dashboard Widgets – Permite criar e alterar widgets para a Dashboard da administração e com controlo de acessos.
Rewrite – Possibilita a criação de rewrite rules personalizadas para vários pontos do código dos plugins.
Transients – Sistema de cache básico persistente na base de dados com tempo de expiração. Pode ser usado para adicionar opções temporárias.
Database – Acesso rápido à base de dados sem haver necessidade de conhecimento de SQL. Permite inserir, atualizar, remover e selecionar registos.
Pluggable Functions – Funções providenciadas pelo WordPress que podem ser completamente redefinidas. É o caso da função wp_mail() que pode ser alterada para usar um servidor SMTP em vez do atual Sendmail.

VANTAGENS DE SE CRIAR UM PLUGIN

Uma das principais vantagens é a de não se ser obrigado a alterar o código fonte do WordPress! Com isto podemos estar seguros que uma atualização da versão do WordPress não irá “destruir” as alterações que fizémos.

Outra vantagem é o que a comunidade chama de plugin sandbox: quando se ativa um plugin o WordPress “testa” o plugin por forma a que este não quebre a nossa instalação se gerar um erro fatal. Esta forma de procedimento salvaguarda todo o trabalho que tivemos anteriormente em contruir e manter o nosso site.

TIPOS DE PLUGINS

O que muita gente não sabe é que no WordPress existem três tipos de plugins. São estes:

“Regulares” – que podem ser ativados e desativados a qualquer mamento a partir da página de plugins;
“Must-Use” – ou simplesmente MUPlugins (não confundir com Multisite, não é a mesma coisa) que são ficheiros de plugins, normalmente constituidos por apenas um ficheiro PHP e que não necessitam de registar CSS nem JS. Esses pequenos plugins encontram-se na pasta /wp-content/mu-plugins/ e são ativados automaticamente pelo WordPress. A única forma de os desativar é removendo-os dessa diretoria. São os primeiros plugins a ser ativados e portanto servem principalmente para alterar funcionalidades da core e não para extender funcionalidades como faz a maior parte dos plugins regulares;
“Drop-ins” – Algumas funcionalidades específicas do WordPress podem ser alteradas através de ficheiros com nomes específicos colocados na pasta /wp-content. Se os seguintes ficheiros forem encontrados, serão automaticamente carregados em momentos específicos:
- advanced-cache.php – Para uso de cache avançada, como por exemplo, cache persistente. É normalmente usado para plugins de cache como o WP Super Cache e o W3 Total Cache.
- db.php – Implementa uma nova classe PHP para gestão da base de dados. A classe irá sobrepor-se à classe nativa wpdb. Uma boa maneira de ver uma implementação disto é usando o plugin da Automattic Hyper DB que implementa uma classe PHP que faz a gestão de multiplas bases de dados MySQL.
- db-error.php – Implementa uma mensagem de erro de acesso ao MySQL customizada
- install.php – Possibilita a implementação de um script de instalação customizado.
- maintenance.php – Mensagem customizada de site em manutenção.
- object-cache.php – O WordPresstem uma cache não-ersistente no entanto é possível implementar uma classe de cache alternativa que use, por exemplo, o memcached ou o sistema PHP-APC.
- sunrise.php – Permite implementar um sistema de mapeamento de domínios. Usado pelo plugin WordPress MU Domain Mapping.
- blog-deleted.php – Mensagem de blog apagado customizada
- blog-inative.php – Mensagem de blog inativo customizada
- blog-suspended.php – Mensagem de blog suspenso customizada

TESTANDO FUNCIONALIDADES COMO SE FOSSEM PLUGINS

Este método serve como uma sandbox para testar ou implementar scripts feitos especialmente só em PHP. É óptimo para fazer o display de variáveis e uma óptima forma de implementar standalone scripts já criados.

Como visto, basta carregar o ficheiro wp-load.php para o nosso ficheiro de script para iniciar o ambiente do WordPress.

Embora isto não seja propriamente um plugin, não deixa de ser uma funcionalidade bastante interessante e que trás muitas vantagens.

CONVENÇÕES

Para que o seu plugin possa coexistir num ambiente em que outros plugins residem, algumas convenções devem ser seguidas:

Mantenha sempre o seu plugin dentro de uma diretoria com o nome do seu plugin, permitindo assim uma organização dos ficheiros mais equilibrada.
Se o seu plugin for criado para ser distribuido, não use as tags à lá ASP , use por as tags . Inclua também comentários das suas funções ao estilo PHPDoc ou comumente conhecido, HereDoc.
Prefixe sempre as suas funções com um nome comum, pode ser por exemplo, o nome do seu plugin.
Use técnicas de código PHP compatíveis com o PHP versão 5.2. Evite técnicas superiores a essa versão.

O CABEÇALHO DO PLUGIN

O cabeçalho do plugin é um pequeno snippet de comentários em PHP que mantém a informação necessária para que o WordPress reconheça o plugin e mostre algumas informações relativas ao plugin.

Esse cabeçalho deve-se encontrar nos primeiros 8kB do ficheiro principal do plugin. Para evitar problemas, os developers colocam-no sempre no início.

Para o seu primeiro plugin, cria a diretoria o-meu-plugin dentro do wp-content. Dentro dessa diretoria vamos criar um ficheiro PHP chamado o-meu-plugin.php.

O cabeçalho que deve ser introduzido nesse ficheiro é o seguinte:

Este cabeçalho é muito direto e as informações que contém devem ser adaptadas com o seu nome, endereço de email e URL.

Algo muito importante a ter em conta é o copyright do plugin. Existe muita discussão pela internet sobre se os plugins WordPress podem ter ou não licensas proprietárias, isto é, não compatível com as licensas OpenSource, nomeadamente a licensa GPL que é a que a core do WordPress usa. Este é um assunto sério e que deve ser respeitado, pois a legislação de direitos de autor existe! A verdade é a seguinte: a licensa GPL diz que qualquer trabalho derivativo de um trabalho licensiado em GPL deve ter a mesma licensa ou pelo menos uma licensa compatível com GPL. Os plugins, como usam código proveniente da core do WordPress são considerados trabalhos derivativos, sendo assim devem seguir o mesmo trâmito de licensa.

Deverá colocar isto logo a seguir ao cabeçalho do plugin:

/*
 *      Copyright 2012 Aluno da Escola WordPress 
 *
 *      This program is free software; you can redistribute it and/or modify
 *      it under the terms of the GNU General Public License as published by
 *      the Free Software Foundation; either version 3 of the License, or
 *      (at your option) any later version.
 *
 *      This program is distributed in the hope that it will be useful,
 *      but WITHOUT ANY WARRANTY; without even the implied warranty of
 *      MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 *      GNU General Public License for more details.
 *
 *      You should have received a copy of the GNU General Public License
 *      along with this program; if not, write to the Free Software
 *      Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
 *      MA 02110-1301, USA.
 */

Este comentário mostra é uma informação para mostrar a licensa do plugin protegendo-o para que terceiros não “abusem” das suas criações.

Gostaria de dar ainda algumas notas acerca da licensa GPL:

Ela permite a livre redistribuição do código, caso o autor o libere, mas não força o autor a redistribui-la se não for essa a intensão – o autor é que decide se quer manter só para si ou liberá-la à comunidade.
O código em GPL alterado deve manter os créditos ao(s) autor(es) origina(l/is).
Você pode pedir um valor monetário aos seus clientes pelo código GPL, porém não pode impossibilitar terceiros a redistribui-lo gratuitamente.

FUNÇÕES PARA DETERMINAR CAMINHOS E URLS

A partir deste ponto, você já tem um plugin que pode ser ativado a partir da administração! Todo o código seguinte irá ser incluido nesse ficheiro ou em ficheiros que ele inclua com as diretivas include ou require.

Determinar os caminhos para incluir ficheiros e os links para imprimir imagens, CSS e scripts pode ser uma tarefa muito complicada. Felizmente o WordPress graciona-nos com várias funções muito importantes:

plugin_dir_path( $file ) – esta função aceita como argumento um nome do ficheiro retornando o caminho absoluto para a diretoria em que o ficheiro está incluído. Usando em combinação com a constante __FILE__, esta função é muito valiosa pois retornando a diretoria do plugin em questão, todos os caminhos a incluir passam a ser relativos, auxiliando assim a programação.
Uso comum:
Exemplo: /www/wp-content/o-meu-plugin/ficheiro/a/incluir.php
plugins_url( $path, $file ) – esta função aceita como argumentos o caminho URL para uma imagem, CSS ou script relativo à diretoria onde o ficheiro passado no segundo no segundo argumento está incluído.
Uso comum:
Exemplo: http://exemplo.org/wp-content/plugins/o-meu-plugin/images/imagem.png
includes_url() – retorna a URL para a diretoria wp-includes
Exemplo: http://exemplo.org/wp-includes
content_url() – retorna a URL para a diretoria wp-content
Exemplo: http://exemplo.org/wp-content
admin_url() – retorna o link para a área de administração
Exemplo: http://exemplo.org/wp-admin
home_url() – retorna o link para a homepage do site
Exemplo: http://exemplo.org

É muito importante usar-se exclusivamente estas funções para determinar os caminhos. Algumas das vantagens são:

Elas suportam SSL, caso o site esteja a ser visualizado em https
Elas suportam as contantes e opções do multisite, retornando os valores atuais para o domínio do blog em questão. Assim, caso haja mapeamento de domínios, elas retornam o valor para esse domínio, em vez do subdomínio nativo.

Exemplos de uso:

Homepage';

Não se esqueça que este plugin é apenas um exemplo de implementação.

FUNÇÕES DE ATIVAÇÃO, DESATIVAÇÃO E DESINSTALAÇÃO

Quando um usuário ativa, desativa ou desistala um plugin, alguns métodos devem ser chamados por forma a permitir o plugin tomar certas decisões nessas alturas.

Porquê? Imagine por exemplo um plugin que necessita de criar opções iniciais para funcionar, usando uma função customizada, é possível criar essas opções durante a instalação.

Registar uma função de instalação

A função register_activation_hook( $file, $function ) regista uma função customizada para ser executada apenas na ativação do plugin. Esta função aceita como parâmetros essa função customizada e o ficheiro em que a função está localizada.

Exemplo de uso:

Registar uma função de desinstalação

A função register_deactivation_hook( $file, $function ) tem o mesmo comportamento que a anterior porem apenas é corrida na desativação do plugin. Sendo assim, qualquer função de desativação customizada deve ser registada com isto.

Ficheiro de desinstalação uninstall.php

Todos os plugins devem ter este ficheiro na sua diretoria. Este ficheiro é chamado pelo WordPress quando um usuário remove o plugin em causa. É aqui que iremos remover quaisquer vestígios do plugin da base de dados do WordPress.

Por exemplo, aqui devemos remover as opções criadas durante a instalação.

Exemplo de ficheiro uninstall.php:

HOOKS DE ACÇÃO E DE FILTRO – O CORE DOS PLUGINS

Nesta secção iremos falar das hooks, o core dos plugins do WordPress. É com as hooks que os plugins conseguem interagir com o WordPress em determinadas situações definidas por essas hooks.

Existem dois tipos de hooks:

Acções: permitem aos developers “colocar” pedaços de códigos em pontos específicos na execução do WordPress.
Filtros: permite filtrar informações (principalmente variáveis) e manipular o output do código. Ao contrário das acções, estas hooks permitem “reescrever” código em determinados pontos.

As funções add_action() e add_filter() possibilitam essa interação. Essas duas funções aceitam como argumentos o nome da hook que queremos alterar e a assinatura da função que providencia o código customizado.

O seguinte código é executado no início do WordPress, durante a hook init:

Lista de Acções mais usadas

plugins_loaded – é usado pelos plugins. Nenhum código do seu plugin deve ser executado antes desta acção, assim, todo o código inicial deve ser colocado dentro desta acção.
init – nesta hook já todo o código core do WordPress foi carregado, o que nos garante que podemos usar qualquer função e ler qualquer variável global do WordPress pois essas já estão carregadas.
admin_init – é igual à init, só que é carregado após todo o interface da administração estar concluído.
wp_head – esta hook possibilita a impressão de código no cabeçalho da página. Ideal para colocar metatags e códigos script e style.
admin_head – igual à anterior porem só funciona na administração.
admin_menu – serve para adicionar páginas ao menu da administração.
wp_footer - imprime ou executa código no rodapé da página.

Iremos falar mais sobre esta API na segunda parte desta série.

Download do código O Meu Plugin

Nota: peço especial atenção para não usar este código como plugin, pois, além de não implementar nenhum funcionalidade, pode comprometer a sua instalação. Serve apenas para fins didáticos.

LEITURA RECOMENDADA

Sugestões de leitura adicional prendem-se com o seu interesse em aprender mais acerca da criação de plugins para o WordPress. Se souber Inglês e for o seu caso, então sugiro:

Use o Codex do WordPress para procurar funções, aprender a API e conhecer novas técnicas de código. Como esta está em formato de wiki comunitária, ou seja, qualquer um pode editar, aproveite e colabore criando e atualizando novos conteúdos do Codex.
Inscreva-se na WordPress Hackers List e faça perguntas diretamente aos developers do WordPress.
Frequente e faça perguntas em sites da especialidade. Comente aqui no Escola WordPress os posts colocando novos códigos e tirando dúvidas; participe nas discussões do WP Tavern.
Adquira um bom livro que será como um bíblia para si. O Professional WordPress Plugin Development, criado por três developers do core do WordPress (Brad Williams, Ozh Richard, Justin Tadlock), profissionais com dezenas de plugins criados, é um bom começo para aprender novas técnicas, reunindo o essencial para a criação ótimos plugins.

E é tudo! Espero que este artigo lhe tenha trazido novas luzes para o desenvolvimento do seu plugin. Não se esqueça de comentar e aguarde pelo segundo artigo desta série que falará sobre a API do WordPress, algumas classes e segurança.

Até breve e um abraço,

Vitor

Artigos Recomendados

Guia definitivo para criar Custom Post Types (Parte 5)

Vitor Carvalho — Wed, 21 Dec 2011 16:57:19 +0000

Guia definitivo para criar Custom Post Types (Parte 5)

Esta série de Tutoriais WordPress pretende ser um complemento de estudo tanto para iniciantes como para profissionais de como programar tipos de post customizados no WordPress. Não esqueça de ler o primeiro, segundo e terceiro artigos desta série: Guia definitivo para criar Custom Post Types (Parte 1) + Guia definitivo para criar Custom Post Types (Parte 2) + Guia definitivo para criar Custom Post Types (Parte 3) + Guia definitivo para criar Custom Post Types (Parte 4). Tenha em atenção que todos os códigos desta série, servem apenas como exemplo. Você pode e DEVE fazer as suas experiências o modificar o código a seu gosto e necessidades.

Este será o último artigo desta série de como criar custom post types. Será aqui que tudo o que você aprendeu irá culminar.

Iremos tratar de extender os links permanentes de forma a adicionar e modificar endpoints e rewrite rules para os seus tipos de post. Desta forma poderá ter posts organizados de maneira diferente sem ser o que normalmente está consagrado por defeito no WordPress. Vamos adicionar novos papeis e atribuir a papeis existentes capacidades para o nosso tipo de post Filmes e vamos falar de segurança no código e como combater ataques XSS e CSRF (os mais comuns).

SUMÁRIO

Adicionar um novo papel de utilizador e novas meta capacidades ao tipo de post
Validar e segurar os inputs dos seus usuários
Bónus: Extender as URLs permanentes através da Rewrite API

Até aqui aprendemos a criar e a extender tipos de post e taxonomias existentes de forma a encaixar plenamente às nossas necessidades. No entanto, por motivos didáticos, não falámos sobre segurança tanto no código, como em inputs dos usuários e até em ACL (lista de controlos de acesso). É sobre este tema que iremos falar. Como bónus, falaremos também sobre a poderosa ferramenta embutida no WordPress que possibilita criar seus próprios links / URLs personalizados.

PAPÉIS DE USUÁRIOS E CAPACIDADES (ACL)

Por defeito o WordPress vem com cinco grandes grupos de acesso que se podem atribuir aos usuários, esses grupos são chamados de papeis (roles, em inglês) e que controlam que partes da Administração do WordPress os usuários podem ver ou alterar. Por exemplo, um usuário cujo papel atribuído é o de administrador terá acesso a tudo, enquanto que um usuário com o papel de autor apenas poderá escrever os seus posts e terá acesso limitado à interface.

Embora possa parecer simples, este processo é mais complexo do que parece. O sistema do WordPress inicial (versões anteriores à 2.1) centrava o controlo dos acessos no grupo, porém este método não era flexível e não possibilitava a sua modificação. Com as novas versões o processo foi-se modificando. Foram criadas as capacidades e os grupos passaram a ser papeis que agregam capacidades que os usuários podem deter, sendo que uma capacidade é uma função em determinado sitio da administração como por exemplo a capacidade de publicar ou remover um post, ou a capacidade de alterar as opções do tema ativo.

Com este método conseguimos criar novos papeis agregando apenas as capacidades necessárias para essa função.

Como exemplo, vamos criar o papel de Revisor de Filmes e assim os usuários que tiverem este papel atribuído terão apenas acesso a criar, editar, remover e publicar filmes. Todos as outras áreas da administração serão barradas a estes usuários.

Para tal colocamos este código no functions.php:

Esta função add_role() cria um novo papel que poderá ser usado em usuários. Aceita como argumentos um ID único do role, uma string de apresentação do papel e um array com as capacidades incluídas nesse papel. No nosso caso adicionamos apenas as capacidades que necessitamos.

Neste momento as capacidades usadas na função em cima ainda não existem, não estão definidas. Para isso vamos ter que modificar a nossa função register_post_type() anteriormente registada na parte 1 desta série, acrescentando uma capacidade personalizada mudando o valor de capability_type para film:

add_action( 'init', 'create_post_type_film' );
function create_post_type_film() {
  register_post_type( 'film', array(
    [...]
    'capability_type' => 'film', // Mudamos de post para film
    [...]
    )
  );
}

Agora já temos ativadas as capacidades personalizadas para o tipo de post film e os usuários com o papel de Revisor de Filmes vão poder criar, editar, remover e publicar filmes.

Caso queiramos acrescentar estas novas capacidades a papeis já existentes como o de Editor, basta adicionar como seguinte código:

add_cap( 'edit_film' );
  $role->add_cap( 'read_film' );
}
?>

Estas são as funções básicas para adicionar capacidades e papeis aos tipos de post. Mais funções podem ser usadas, este é apenas o básico. Para mais informações sugiro dar uma olhada aqui no codex.

VALIDAÇÃO E SEGURANÇA DOS INPUTS

Todos nós sabemos que segurança é um questão muito importante quando criamos código de qualidade para qualquer software. A necessidade de preocupação com essa questão aumenta na elaboração de websites e webapplications.

Conhecemos e ouvimos ou lemos (quase) todos os dias sites que são atacados ou informação confidencial que é extraída ilegalmente, normalmente isso acontece por falta de mecanismos de segurança ao nível da configuração dos servidores, mas o crescente número de exploits (pedaços de código expostos a ataques) ao nível de scripts na Web é uma preocupação que todos temos que ter em mente quando elaboramos código.

Há dois tipos de ataque muito comuns, e normalmente são os único que nos deve preocupar em sites de pequena e média dimensão, chamam-se XSS (cross-site scripting) e CSRF (Cross-site request forgery). O primeiro existe quando o usuário clica num link mal-intensionado que cria danos à sua própria instalação de WordPress e o segundo é o chamado tipo de ataque de força bruta, em que um usuário mal intencionado usa, por exemplo, formulários para tentar ganhar permissões ou criar exploits em instalações de WordPress alheias.

Felizmente o WordPress e o PHP vêm com proteções nativas contra este tipo de ataques, porém, em muitos casos podem não ser suficientes. Nesta secção iremos tratar de combater com funções e métodos muito simples este tipo de ataques usando validações de input e de links.

Limpar as informações de um formulário submetido:

É muito simples usando a função nativa do PHP strip_tags() limpando todos os caracteres que não sejam alfanuméricos. Isto consiste num ótimo meio de proteção primordial.

Assim, no caso de validação dos inputs em hora de guardar os campos personalizados, vamos usar esta função primeiro, antes de passar os seus conteúdos à função update_post_meta(). Vamos então alterar o código criado na parte 2:

Esta é a função mais usada no saneamento de inputs e aquela que deve ser sempre colocada antes de salvar algum registo para a base de dados.

Checar as permissões do usuário:

O WordPress vem com a função nativa current_user_can( $capability ) que, dada uma capacidade, retorna true ou false se o usuário corrente tiver ou não a permissão que estamos testar, respetivamente. Este é o segundo patamar da nossa protecção contra ataques de força bruta.

No nosso caso vamos voltar a alterar o nosso código anterior para acrescentar esta função. Desta forma estamos a avaliar se o o usuário que está a tentar guardar um registo é um usuário com permissões para isso:

[...]
function ewp_film_save_post( $film_id, $film ) {
   if ( ! $_POST['ano_film'] ) return;

   // Caso o usuário não tenha permissões de edição de filmes, não faz nada
   if ( ! current_user_can( 'edit_film' ) ) return;
[...]

Garantimos assim que os registos para os campos customizados são legítimos e que, pelo menos, o usuário que está a tentar guardar tem permissões para isso. Esta é a segunda defesa contra ataques, porém, garantir que o usuário tem permissões para editar filmes não chega. Falámos à pouco de ataques XSS e ainda precisamos de garantir que o pedido para guardar estes dados provém da própria administração. Para isso vamos validar os links com nonces.

Validar o referer dos links com a técnica de nonces:

A técnica de nonces é muito simples e prática. A ideia é gerar uma senha aleatória que será guardada na base de dados temporariamente e colocada na query do pedido através de um hidden input. Assim de toda a vez que o usuário acessar essa página uma nova senha será gerada com a função wp_nonce_field() e, em tempo de salvar os dados, iremos checar se essa senha existe na base de dados e corresponde com a acção que queremos realizar com a função check_admin_referer(). Vamos alterar dois códigos, o da metabox, adicionando a função criadora do nonce e novamente a função para guardar os campos personalizados:

[...]
function film_inner_meta_box( $film ) {
  wp_nonce_field( 'edit_film', __FILE__ );
?>

  Ano:
[...]

e alteramos o código para guardar:

[...]
function ewp_film_save_post( $film_id, $film ) {
   if ( ! $_POST['ano_film'] ) return;

   // Caso o usuário não tenha permissões de edição de filmes, não faz nada
   if ( ! current_user_can( 'edit_film' ) ) return;

   // Verfificamos se este pedido é legítimo, ou seja, se provém da administração
   check_admin_referer( 'edit_film', __FILE__ );

[...]

Usando estas três técnicas protegemos os nossos websites WordPress contra os dois tipos de ataques mais comuns.

EXTENDER AS URLS USANDO A API REWRITE

A API de Rewrites do WordPress não tem propriamente a ver com custom post types, no entanto, achámos por bem falar um pouco nela uma vez que pode ser útil na organização de alguns tipos de post mais complicados.

Esta API cria endpoints de URLs, ou seja, estruturas permanentes de URL customizadas. No caso do nosso tipo de post Filme, podemos querer apresentar os filmes por vários tipos de organização estrutural na URL, seja por Realizador ou Produtos ou por Ano do filme.

Peguemos no exemplo do caso mais lógico e vamos criar uma estrutura de URLs que apresente os filmes organizados por ano de lançamento. Basta passar a função add_rewrite_rule(). O código seguinte viabiliza o que queremos alcançar:

Colocando este código no functions.php estamos a permitir que o nosso tipo de post filme seja navegável também por ano de lançamento. Se um usuário entrar na URL filmes/ano/2011/ irá obter uma lista de todos os filmes realizados no ano de 2011 em género de blogue.

Mas antes disso acontecer terá que regenerar as rewrite rules. A melhor maneira é, depois de colocar os códigos, ir à secção de Ligações permanentes nas Opções da administração. Apenas visitando essa página de opções regenera as rewrite rules.

Esta é uma poderosa ferramenta que você pode usar para criar outras estruturas de URL para os seus tipos de post.

DOWNLOAD DO CÓDIGO COMPLETO

Este é o último artigo para finalizar esta série de custom post types e como prometido nos artigos anteriores, disponibilizamos os códigos de todos os artigos desta série num único download. Segue o ficheiro que poderá descarregar.

Faça o Download do Código!

Tenha em atenção ao usar este código: evite o copy e paste e leia com atenção cada um dos pedaços de código que disponibilizamos assim como os comentários ao código e, necessariamente, os artigos correspondentes.

Uma palavra final…

Espero que esta série tenha sido do vosso agrado e que tenha valorizado a sua aprendizagem no desenvolvimento para WordPress. Este guia definitivo tentou dar as luzes iniciais para as matérias mais importantes dentro do mundo dos custom post types. No entanto, vale sempre a pena referir que o conhecimento vai muito mais além que ler, é necessário pôr em prática e aprender cada vez mais. Se souber Inglês, sugiro sempre o uso da wiki oficial do WordPress, o CODEX.

Partilhe os seus códigos através dos comentários e participe nesta comunidade colocando questões e tirando dúvidas aos colegas!

Um forte abraço e até breve,

Vitor

Artigos Recomendados

Guia definitivo para criar Custom Post Types (Parte 4)

Vitor Carvalho — Tue, 13 Dec 2011 15:17:09 +0000

Guia definitivo para criar Custom Post Types (Parte 4)

Esta série de Tutoriais WordPress pretende ser um complemento de estudo tanto para iniciantes como para profissionais de como programar tipos de post customizados no WordPress. Não esqueça de ler o primeiro, segundo e terceiro artigos desta série: Guia definitivo para criar Custom Post Types (Parte 1) + Guia definitivo para criar Custom Post Types (Parte 2) + Guia definitivo para criar Custom Post Types (Parte 3). Tenha em atenção que todos os códigos desta série, servem apenas como exemplo. Você pode e DEVE fazer as suas experiências o modificar o código a seu gosto e necessidades.

Neste artigo da série iremos tratar de extender e usar de uma forma mais customizada as taxonomias nos nossos tipos de post.

SUMÁRIO

Extender, acrescentando novos campos as taxonomias
Apresentar as taxonomias customizadas no website
Criar um filtro a partir da taxonomia na página de listagem de tipos de post

As taxonomias customizadas foram iniciadas no ciclo da versão 2.8 do WordPress tendo a API sido acabada na versão 2.9, antes do lançamento dos Custom Post Types. Com esta nova funcionalidade, os developers tiveram a possibilidade de criar novos tipos de categorias para os posts e páginas, extendendo dessa forma o tipo de categorização disponível. Com isto iniciou-se um novo ciclo para o WordPress: de gestor de blog para um verdadeiro CMS personalizável.

É possível criar taxonomias para categorizar não só posts e páginas mas também os nossos tipos de post.

Pegando no nosso tipo de post Filme, e na categoria customizada que criámos no primeiro artigo, vamos extendê-la de modo a termos mais campos para além dos habituais.

EXTENDER, ACRESCENTANDO NOVOS CAMPOS ÀS TAXONOMIAS

Por defeito, as taxonomias apresentam apenas três campos – Título, Slug e Descrição – e sem a possibilidade de acrescentar ou retirar campos.

No entanto, com um plugin que cria a funcionalidade de metadata nas taxonomias, conseguimos atingir da mesma forma o pretendido.

No nosso caso nós iremos criar um campo muito simples, uma caixa de input onde poderemos colocar a URL de uma imagem que será usada como imagem de destaque da categoria de filmes. Que tal? Vamos então!

Para começar, colocamos o código que está na parte 1 desta série para criar a nossa taxonomia. Agora que temos a nossa taxonomia instalada, vamos extendê-la.

Seguidamente fazemos o download do plugin e instalamo-lo da mesma forma como outro plugin qualquer – aqui fica o local para download do nosso plugin.

Existem vários plugins para criar esta funcionalidade, no entanto este é aquele com que prefiro trabalhar e que recomendo.

Depois de instalado e configurado, já temos a estrutura necessária para trabalhar com estes campos das taxonomias customizadas. Desta forma basta-nos mapear quatro acções para realizarem a tarefa de nos criar a interface visual entre os campos e o WordPress:

add_action( 'film_category_add_form_fields', 'film_category_add', 10, 2);
add_action( 'film_category_edit_form_fields', 'film_category_edit', 10, 2);
add_action( 'edited_film_category', 'film_category_save', 10, 2);
add_action( 'save_film_category', 'film_category_save', 10, 2);

Estas quatro acções irão, conjuntamente com as funções que chamam, criar os campos na página de adição de termos – _add_form_fields e save_ – e os campos na página de edição dos termos da taxonomia – _edit_form_fields e save_. Estes dois conjuntos existem pois as páginas de criação e de edição dos termos das categorias é diferente.

Agora que temos as acções mapeadas, vamos acrescentar as funções que são necessárias:

function film_category_add( $tag ) { ?>

Imagem:

Adicionar uma imagem de destaque para esta categoria.

term_id, '_category_image', true ); ?>

Imagem:

Adicionar uma imagem de destaque para esta categoria.

Estas funções são muito simples. A primeira apenas apresenta um HTML que desenha o campo de input para se colocar o URL da imagem.

A segunda função é mais complexa, pois é a função que é usada na edição dos termos das taxonomias. Primeiro, através da função get_term_meta() – uma das funções adicionadas pelo plugin que instalámos à pouco – retornamos para a variável $image o URL definido pelo usuário, apresentando-o em seguida no campo de input.

Neste momento os campos são apresentados na interface do WordPress, porém nenhum valor é guardado quando se salva um termo dessa taxonomia. Precisamos ainda de definir a função que guarda os valores:

function film_category_save( $term_id ) {
  // Se foi inserido algum valor no campo...
  if ( isset( $_POST['image'] ) )
    // ...guarda esse valor
    update_term_meta( $term_id, '_film_category_image', strip_tags( $_POST['image'] ) );

  // senão...
  else
    // Remove esse valor
    delete_term_meta( $term_id, '_film_category_image' );

  return $term_id;

}

Esta função é muito simples: caso o valor ‘image’ exista (ou seja, caso o utilizador preencha o campo de imagem) ela guarda esse valor, senão ela remove o valor anterior, pois, caso esteja o campo em branco é provável que o usuário tenha querido remover essa imagem do termo da taxonomia.

E estamos prontos! O nosso campo customizado irá aparecer em beleza na interface.

APRESENTAR AS TAXONOMIAS CUSTOMIZADAS NO WEBSITE

Como foi visto na parte 2 desta série, a hierarquia de templates WordPress é bastante complexa, dando a possibilidade de se construir o que se quiser. No caso da apresentação de posts em taxonomias, só necessitamos de um template: taxonomy-.php

No nosso caso vamos primeiro criar um ficheiro no nosso tema com o nome taxonomy-film_category.php para receber toda a lógica programática de apresentação dos nossos filmes:


  



  term_id, '_category_image', true ); ?>" />

Este é o código que é responsável pela apresentação dos filmes dentro de cada termo da taxonomia. A diferença para com o código do artigo anterior prende-se com o uso de uma tag H1 e da função single_tag_title(). Esta é reponsável por apresentar o título da taxonomia que estamos a navegar – por exemplo, se estivermos a ver a categoria Drama, esta função imprime Drama no ecrã.

Novamente usamos a função get_term_meta() para retornar deste modo o URL da imagem que se definiu na administração para cada categoria de filmes.

Com alguns ajustes de HTML e CSS conseguimos atingir algo como isto, em que a imagem da esquerda é a que usámos colocando o seu URL na caixa de input:

É possível criar e extender muito este exemplo, que deve ser trabalhado e usado para os seus próprios fins. Basta dar uso à criatividade.

CRIAR UM FILTRO POR TAXONOMIA NA PÁGINA DE LISTAGEM DE TIPO DE POSTS

Se você visualizar a página de listagem dos Posts na sua administração, verá que no topo existem uma série de filtros, sendo que um deles é filtrar os posts por categoria. É essa funcionalidade que iremos apresentar nesta secção, filtrando os filmes por categoria.

Com uma simples acção é possível colocar uma caixa dropdown com as categorias da taxonomia film_category. Desta forma atingimos algo parecido, apresentando no campo da filtragem a seguinte caixa:

Este é o código necessário:

add_action( 'restrict_manage_posts', 'film_retrict_categories' );

function film_retrict_categories() {
  // Acesso às variáveis do tipo de post atual e o array do pedido
  global $typenow, $wp_query;

  // Se o tipo de post for diferente de film não faz nada
  if ( $typenow != 'film' )
   return false;

  // Imprime uma select box com todos os termos da taxonomia film_category
  wp_dropdown_categories(array(
   'show_option_all' =>  'Mostrar tudo',
   'taxonomy'        =>  'film_category',
   'name'            =>  'film_category',
   'orderby'         =>  'name',
   'selected'        =>  $wp_query->query['term'],
   'hierarchical'    =>  true,
   'depth'           =>  3,
   'show_count'      =>  true,
   'hide_empty'      =>  true,
   )
  );
}

Ao chamarmos a acção restrict_manage_posts com a nossa função, temos a possibilidade de acrescentar HTML na zona de filtragem, no cabeçalho da tabela de listagem.

Primeiro, caso o tipo de post não seja film a função retorna sem continuar a sua atividade, assim apenas aplicamos este filtro nas páginas de listagem dos filmes.

A função wp_dropdown_categories é responsável pela impressão da dropdown das categorias da taxonomia passada como argumento, no nosso caso film_category. Não me vou alongar mais sobre os argumentos desta função, pois davam um artigo inteiro, porém deixo o link para estudo mais profundo.

Espero que este artigo lhe tenha sido útil para criar o seu plugin que tanto deseja

Não esqueça de ler os outros artigos desta série:

Bons estudos!

Vitor

Artigos Recomendados

Como carregar Gravatars em tempo real no seu blog WordPress

Paulo Faustino — Wed, 07 Dec 2011 18:30:55 +0000

Como carregar Gravatars em tempo real no seu blog WordPress

Recentemente escrevemos um artigo sobre Como adicionar mais campos no perfil de usuários do WordPress, através de funcionalidades que implementámos no nosso Diretório de Blogs há pouco tempo. E para continuarmos a oferecer soluções de qualidade aos nossos leitores, hoje decidimos que seria interessante partilharmos mais algumas funcionalidades que implementámos recentemente em alguns dos nossos blogs. A ideia do artigo de hoje, é explicar-lhe como carregar gravatars em tempo real no seu blog WordPress. Esta ideia implementámos recentemente no nosso blog sobre como ganhar dinheiro, mais concretamente na seção de comentários do blog, e muitos leitores têm-nos pedido para explicarmos como o fizemos.

Para conseguirmos atingir este resultado final, necessitamos de um algoritmo de encriptação MD5, uma vez que a API do Gravatar necessita dessa encriptação para manter seus endereços de email seguros. Existe um webtoolkit MD5 que faz este trabalho de forma simples e eficaz. Basicamente o que terá de fazer é copiar este código para dentro de uma nova página em branco, e gravá-lo como um ficheiro .js (javascript).

/**
*
*  MD5 (Message-Digest Algorithm)
*  http://www.webtoolkit.info/
*
**/

var MD5 = function (string) {

	function RotateLeft(lValue, iShiftBits) {
		return (lValue<>>(32-iShiftBits));
	}

	function AddUnsigned(lX,lY) {
		var lX4,lY4,lX8,lY8,lResult;
		lX8 = (lX & 0x80000000);
		lY8 = (lY & 0x80000000);
		lX4 = (lX & 0x40000000);
		lY4 = (lY & 0x40000000);
		lResult = (lX & 0x3FFFFFFF)+(lY & 0x3FFFFFFF);
		if (lX4 & lY4) {
			return (lResult ^ 0x80000000 ^ lX8 ^ lY8);
		}
		if (lX4 | lY4) {
			if (lResult & 0x40000000) {
				return (lResult ^ 0xC0000000 ^ lX8 ^ lY8);
			} else {
				return (lResult ^ 0x40000000 ^ lX8 ^ lY8);
			}
		} else {
			return (lResult ^ lX8 ^ lY8);
		}
 	}

 	function F(x,y,z) { return (x & y) | ((~x) & z); }
 	function G(x,y,z) { return (x & z) | (y & (~z)); }
 	function H(x,y,z) { return (x ^ y ^ z); }
	function I(x,y,z) { return (y ^ (x | (~z))); }

	function FF(a,b,c,d,x,s,ac) {
		a = AddUnsigned(a, AddUnsigned(AddUnsigned(F(b, c, d), x), ac));
		return AddUnsigned(RotateLeft(a, s), b);
	};

	function GG(a,b,c,d,x,s,ac) {
		a = AddUnsigned(a, AddUnsigned(AddUnsigned(G(b, c, d), x), ac));
		return AddUnsigned(RotateLeft(a, s), b);
	};

	function HH(a,b,c,d,x,s,ac) {
		a = AddUnsigned(a, AddUnsigned(AddUnsigned(H(b, c, d), x), ac));
		return AddUnsigned(RotateLeft(a, s), b);
	};

	function II(a,b,c,d,x,s,ac) {
		a = AddUnsigned(a, AddUnsigned(AddUnsigned(I(b, c, d), x), ac));
		return AddUnsigned(RotateLeft(a, s), b);
	};

	function ConvertToWordArray(string) {
		var lWordCount;
		var lMessageLength = string.length;
		var lNumberOfWords_temp1=lMessageLength + 8;
		var lNumberOfWords_temp2=(lNumberOfWords_temp1-(lNumberOfWords_temp1 % 64))/64;
		var lNumberOfWords = (lNumberOfWords_temp2+1)*16;
		var lWordArray=Array(lNumberOfWords-1);
		var lBytePosition = 0;
		var lByteCount = 0;
		while ( lByteCount < lMessageLength ) {
			lWordCount = (lByteCount-(lByteCount % 4))/4;
			lBytePosition = (lByteCount % 4)*8;
			lWordArray[lWordCount] = (lWordArray[lWordCount] | (string.charCodeAt(lByteCount)<>>29;
		return lWordArray;
	};

	function WordToHex(lValue) {
		var WordToHexValue="",WordToHexValue_temp="",lByte,lCount;
		for (lCount = 0;lCount<=3;lCount++) {
			lByte = (lValue>>>(lCount*8)) & 255;
			WordToHexValue_temp = "0" + lByte.toString(16);
			WordToHexValue = WordToHexValue + WordToHexValue_temp.substr(WordToHexValue_temp.length-2,2);
		}
		return WordToHexValue;
	};

	function Utf8Encode(string) {
		string = string.replace(/\r\n/g,"\n");
		var utftext = "";

		for (var n = 0; n < string.length; n++) {

			var c = string.charCodeAt(n);

			if (c < 128) {
				utftext += String.fromCharCode(c);
			}
			else if((c > 127) && (c < 2048)) {
				utftext += String.fromCharCode((c >> 6) | 192);
				utftext += String.fromCharCode((c & 63) | 128);
			}
			else {
				utftext += String.fromCharCode((c >> 12) | 224);
				utftext += String.fromCharCode(((c >> 6) & 63) | 128);
				utftext += String.fromCharCode((c & 63) | 128);
			}

		}

		return utftext;
	};

	var x=Array();
	var k,AA,BB,CC,DD,a,b,c,d;
	var S11=7, S12=12, S13=17, S14=22;
	var S21=5, S22=9 , S23=14, S24=20;
	var S31=4, S32=11, S33=16, S34=23;
	var S41=6, S42=10, S43=15, S44=21;

	string = Utf8Encode(string);

	x = ConvertToWordArray(string);

	a = 0x67452301; b = 0xEFCDAB89; c = 0x98BADCFE; d = 0x10325476;

	for (k=0;k
De seguida, é necessário configurar corretamente o funcionamento do nosso Gravatar. Copie e cole o seguinte código para o local onde deseja que o campo de preenchimento do email correspondente ao Gravatar apareça:




Neste código temos a dimensão do gravatar definida para 80×80 pixeis, mas poderá alterar essa dimensão para outro valor que desejar. Temos campo o campo definido para o Id=”email” com um type=”text”, que específica que o tempo é de texto e para o endereço de email. Por fim temos uma chamada do nosso código de encriptação MD5 em Javascript, que faz a encriptação dos emails e os mantém seguros do ponto de vista da API do Gravatar. Ao digitar o endereço de email, ele altera o Gravatar em tempo real.
Para conseguirmos que o Gravatar seja puxado em tempo real e com isso atingirmos o resultado desejado, é recomendável utilizarmos mais um código Javascript que basicamente trabalha os campos de texto/email e o Gravatar em si. Veja:

Este código tem algumas particularidades interessantes. O “var gravatar” e o “var email” controlam os campos de email e gravatar com o JavaScript, enquanto que o campo “email.onkeyup” é uma função que faz com que o Gravatar se altere há medida que o usuário começa a escrever o seu endereço de email, usando o nosso ficheiro de encriptação MD5. O “gravatar.src” significa que você pode colocar o endereço de uma imagem com 80×80 pixeis para servir como o seu gravatar padrão, caso o usuário não tenha um registrado, tal como fizemos no nosso blog sobre como ganhar dinheiro. Se desejar, pode passar por lá para ver o Gravatar em tempo real funcionando corretamente.
Até Já!
Artigos Recomendados
Como criar templates diferentes para single posts e categorias do WordPress
Como Criar Plugins para WordPress (Parte IV)
Como Criar Plugins para WordPress (Parte III)
Como colocar comentários do Facebook no WordPress sem precisar de plugins
Como Criar Plugins para WordPress (Parte II)
Como Criar Plugins para WordPress (Parte I)

Guia definitivo para criar Custom Post Types (Parte 3)

Vitor Carvalho — Tue, 06 Dec 2011 16:18:03 +0000

Guia definitivo para criar Custom Post Types (Parte 3)

Esta série de Tutoriais WordPress pretende ser um complemento de estudo tanto para iniciantes como para profissionais de como programar tipos de post customizados no WordPress. Não esqueça de ler o primeiro e segundo artigos desta série: Guia definitivo para criar Custom Post Types (Parte 1) + Guia definitivo para criar Custom Post Types (Parte 2). Tenha em atenção que todos os códigos desta série, servem apenas como exemplo. Você pode e DEVE fazer as suas experiências o modificar o código a seu gosto e necessidades.

Neste artigo da série iremos extender as capacidades do tipo de posts de maneira a customizar ainda mais a sua apresentação e melhorar a organização dos elementos.

SUMÁRIO

Definir mensagens de actualização customizadas na administração
Criar texto de ajuda contextualizada para o tipo de post
Modificar e acrescentar colunas na página de listagem do tipo de post
Editar e acrescentar “Ações em Massa”

Customizar a administração por vezes requer algum trabalho, e entrando agora nesta parte o trabalho já não vai ser mais direto como foi nos últimos artigos – estamos neste momento a “escavar” fundo no WordPress.

Porém, o nosso objectivo é apenas proporcionar as ferramentas para você poder trabalhar e fazer dos tipos de post o que você quiser, inventando, experienciando e até descobrindo novas funcionalidades, assim sendo nós aqui vamos continuar a seguir uma linha condutora muito directa. O “grau da sua experiência” é você que define depois de ler e aprender.

MENSAGENS DE ESTADO E ATUALIZAÇÃO

As mensagens de estado e atualização são aquelas mensagens de noticia ou de erro (amarelas e vermelhas, respectivamente) que aparecem no cabeçalho das páginas da administração indicando que houve acções de criação, edição, eliminação outras acções ou estados que foram concluídos com êxito ou não.

Nesta parte iremos tratar de como implementar as nossas próprias mensagens de erro ou de estado quando o nosso tipo de post é atualizado, apagado, publicado, removido, etc, mapeando todas as acções possíveis.

Para isso chamamos o filtro post_updated_messages que contém um array com todas as strings de estado para todos os tipos de post registados. O código abaixo é a representação de como é possível modificar essas strings facilmente para o nosso tipo de post film:

add_filter( 'post_updated_messages', 'film_updated_messages' );
function film_updated_messages( $messages ) {
  global $post, $post_ID;

  $messages['film'] = array(
    1 => sprintf( 'O filme foi atualizado. Ver Filme', esc_url( get_permalink($post_ID) ) ),
    2 => 'Campo customizado atualizado',
    3 => 'Campo customizado apagado',
    4 => 'Filme atualizado',
    5 => isset( $_GET['revision'] ) ? sprintf( 'Filme atualizado para a revisão %s', wp_post_revision_title( (int) $_GET['revision'], false ) ) : false,
    6 => sprintf( 'Filme publicado. Ver Filme', esc_url( get_permalink($post_ID) ) ),
    7 => 'Filme guardado.',
    8 => sprintf( 'Filme guardado. Prever Filme', esc_url( add_query_arg( 'preview', 'true', get_permalink($post_ID) ) ) ),
    9 => sprintf( 'Filme agendado para: %1$s. Prever Filme' ), date_i18n( __( 'M j, Y @ G:i' ), strtotime( $post->post_date ) ), esc_url( get_permalink($post_ID) ) ),
    10 => sprintf( 'Rascunho de Filme guardado. Prever Filme', esc_url( add_query_arg( 'preview', 'true', get_permalink($post_ID) ) ) ),
  );

  return $messages;
}

A função que faz a gestão das mensagens primeiro chama as variáveis globais $post e $post_ID de modo a serem acessíveis a partir da função. Seguidamente, modificamos o array que representa este tipo de post, passando novas strings para serem usadas no lugar das strings por defeito. A função nativa do PHP sprintf() é muito usada aqui, uma vez que ela ajuda na insersão de variáveis importantes para que as mensagens não fiquem descontextualizadas.

Você deve seguir uma linha igual à apresentada no código acima, modificando apenas as strings e fazendo o mínimo de mudanças possíveis à posição das variáveis para que a experiência do usuário seja uniforme em toda a administração.

AJUDA CONTEXTUALIZADA

A administração do WordPress tem uma funcionalidade que quase toda a gente desconhece ou simplesmente não liga, mas que deveria ser o primeiro recurso de procura de informação em caso de dúvida.

Estou a falar daquela aba que fica no cabeçalho de quase todas as páginas da Administração que apresenta o texto “Ajuda”. Se clicar nessa aba, abre-se um painel que apresenta uma ajuda dedicada apenas à página que estamos a observar – é por isso que se chama “Ajuda Contextualizada”, pois encontra-se no contexto da página em que estamos.

Por defeito, quando criamos um novo tipo de post a ajuda contextualizada para esse tipo apresenta apenas dois links que ajudam muito pouco quem vai à procura de mais informação, na verdade nós podemos (e devemos) modificar esse painel de maneira a apresentar um texto de ajuda contextualizado tanto na página de edição de posts como no de listagem.

Para isso procedemos como anteriormente, chamando agora a acção contextual_help e passando-lhe uma função que retorna o texto HTML que queremos para ajuda. O código é o seguinte:

add_action( 'contextual_help', 'film_help_text', 10, 3 );

function film_help_text( $contextual_help, $screen_id, $screen ) {
  if ( 'film' == $screen->id ) {
    $contextual_help =
     'Este é um texto de ajuda ao nosso tipo de post Filme que aparece na página de edição.' .
     'Você pode criar o texto que quiser aqui';
  } elseif ( 'edit-film' == $screen->id ) {
    $contextual_help =
     'Este texto aparece na ajuda da página de listgem de filmes.';
  }
  return $contextual_help;
}

Esta acção procura se a tela atual é a página de edição ou a página de listagem de filmes através da variável id do objecto $screen, retornando para cada um dos casos uma ajuda contextual que vai aparecer na aba de Ajuda.

Você pode colocar o quiser, seja HTML ou código script ou PHP (sendo que este será escapado e não irá correr, apenas será apresentaod como referência), no entanto à medida que for escrevendo será cada vez mais complicado fazer a gestão destas strings – escrever HTML dentro de aspas não é a melhor coisa para organização.

É por isso que normalmente uso outra abordagem: em vez de colocar as strings aqui, crio um ficheiro HTML para cada uma das ajudas contextuais, e leio o ficheiro para a variável em tempo de execução com ajuda da função nativa do PHP file_get_contents(). Desta forma salvaguardo a organização do espaço nesta função e ao mesmo tempo possibilita-me a modificação do HTML sempre que necessário.

Desta maneira a abordagem ficaria o seguinte:

**Ficheiro film_help_text.html:**

Este é um texto de ajuda ao nosso tipo de post Filme que aparece na página de edição.

Você pode criar o texto que quiser aqui

Aqui sou livre de criar o HTML que quiser.

Modificação do código acima:

add_action( 'contextual_help', 'film_help_text', 10, 3 );

function codex_add_help_text( $contextual_help, $screen_id, $screen ) {
  if ( 'film' == $screen->id ) {
    $contextual_help = file_get_contents( 'film_help_text.html' );
  } elseif ( 'edit-film' == $screen->id ) {
    $contextual_help = file_get_contents( 'edit-film_help_text.html' );
  }
  return $contextual_help;
}

Para isto funcionar, não se esqueça de colocar os ficheiros html no seu Tema WordPress, na mesma directoria que o ficheiro functions.php. Lembre-se também de criar o html para o ficheiro edit-film_help_text.html que será apresentado na página de listagem.

MODIFICAR COLUNAS NA LISTAGEM DE POSTS

A página de listagem apresenta por defeito apenas duas colunas: o título do post e a data de criação ou publicação. Porém, como seria óbvio, nós vamos agora modificar essa tabela de modo a podermos usar mais colunas de maneira customizada, apresentando apenas os dados que queremos e como queremos.

Para modificarmos as colunas teremos que chamar quatro acções e filtros, de modo a termos as funcionalidades necessárias. Isto requer algum treino e experiência pois não é muito intuitivo. Penso que a API aqui poderia ser melhorada, e provavelmente será um dia.

Para facilitar esta terefa vamos dividir isto em duas partes: a primeira diz respeito à apresentação das colunas em si e a segunda à possibilidade de dar a capacidade de sortear os resultados por coluna.

Primeira parte:

Através do filtro manage_edit-_columns criamos o cabeçalho das colunas que queremos que apareçam. Lembra-se daqueles campos customizados (ano, realizador e produtor) que criámos na parte dois da série? Pois bem, vamos usá-los aqui apresentando um por cada coluna:

add_filter( 'manage_edit-film_columns', 'film_manage_edit_columns' );
function film_manage_edit_columns( $columns ) {

  $film_columns = array(
    "cb" => $columns["cb"],
    "title" => $columns["title"],
    "film_ano" => 'Ano',
    "film_realizador" => 'Realizador',
    "film_produtor" => 'Produtor',
    "date" => $columns["date"],
  );
  return $film_columns;

}

Neste momento temos as colunas já mapeadas, o WordPress sabe que colunas deve apresentar na página de listagem. Nesta função fizémos passar uma nova organização de colunas, mantendo as colunas com a Checkbox, Título e Data, e criando novas colunas que farão a apresentação dos campos customizados.

Seguidamente iremos chamar a acção que irá fazer o display efetivo do conteúdo de cada post dentro da tabela de listagem. Para isso usamos manage_posts_custom_column :

add_action( "manage_posts_custom_column", 'film_manage_columns', 10, 2);
function film_manage_columns( $column ) {
  global $post;
  switch ($column) {
    case "film_ano":
      echo get_post_meta( $post->ID, '_ano_film', true );
      break;

    case "film_realizador":
      echo get_post_meta( $post->ID, '_realizador_film', true );
      break;

    case "film_produtor":
      echo get_post_meta( $post->ID, '_produtor_film', true );
      break;

  }
}

Nesta função procuramos pelo nome da coluna pela condição switch, e caso seja igual a uma daquelas corre o código correspondente. Neste caso fazemos o print dos próprios campos customizados.

Segunda Parte:

As colunas já aparecem na página de listagem, porém, as únicas colunas que são sorteáveis são o título e a data. Caso queiramos sortear os filmes por ano ou realizador teremos que completar esta segunda parte.

Usando mais dois filtros, conseguimos fazer com que essas colunas sejam sorteáveis:

// Definindo que colunas devem ter a capacidade de sortear
add_filter( 'manage_edit-film_sortable_columns', 'manage_film_sortable_columns' );
function manage_film_sortable_columns( $columns ) {
  $columns['film_ano'] = 'ano';
  $columns['film_realizador'] = 'realizador';
  return $columns;
}

// Aqui lemos as variáveis que estão no URL e fazemos buscas como quisermos
add_filter( 'request', 'film_request' );
function film_request( $vars ) {
  // Procuramos saber se o URL pede para sortear uma das colunas
  if ( isset( $vars['orderby'] ) ) {

    // Sorteamos por coluna
    switch ( $vars['orderby'] ) {

      case 'ano' :
         $vars = array_merge( $vars, array(
           'meta_key' => '_ano_film',
           'orderby' => 'meta_value'
         ) );
         break;

      case 'realizador' :
         $vars = array_merge( $vars, array(
           'meta_key' => '_realizador_film',
           'orderby' => 'meta_value'
         ) );
         break;
    }
  }
  return $vars;
}

Este código é bem maior, mas é muito direto e de fácil compreensão. No primeiro filtro nós juntamos às colunas já sorteáveis por defeito (Título e Data) as colunas Ano e Realizador. Decidi não colocar a coluna Produtor como sorteável apenas por questões didáticas.

O segundo filtro define, para cada uma das colunas, caso seja pedido o seu sorteio, o que deve o WordPress fazer. Neste caso, o WordPress vai fazer o pedido à base de dados de sortear ascendentemente pelo campos customizado. Na verdade, este filtro serve muito mais do que sortear colunas… você pode criar variáveis no URL que irão fazer novos pedidos à base de dados e apresentar novos posts, mas isso está fora do escopo deste artigo. Fica só a ideia.

EDITAR E ACRESENTAR ACÇÕES EM MASSA

Este truque é por enquanto um pouco tricky, pois a API do WordPress aqui nunca ficou concluída, e possívelmente ainda vai levar algum tempo até ficar concluída. No entanto é possível dar a volta à situação.

Vamos dividir esta parte em duas uma dedicando-se ao dropdown de acções em massa e outra aos links de estado listados por cima do cabeçalho da tabela.

Dropdown de Acções em Massa:

Este dropdown é um dos exemplos de uma API inacabada. Neste momento você só poderá eliminar opções da dropdown, não podendo acrescentar mais. Existe forma de o fazer, nomeadamente usando jQuery, porém este é assunto um tanto complexo, pois será necessário trigar a acção que criamos, e por isso ficará para outra altura.

No entanto fica aqui como exemplo o código de como remover a acção de editar em massa. Você poderá retirar todas as acções que estiverem pelo dropdown, basta simplesmente procurar a chave do array correspondente à acção:

add_filter( 'bulk_actions-edit-film', 'film_bulk_actions', 10, 1 );
function film_bulk_actions( $actions ){
  unset( $actions['edit'] );
  return $actions;
}

O filtro bulk_actions-edit- recebe um array com as acções disponíveis, bastando ao programador retirar as que quiser.

Links de Estados:

Normalmente uso este espaço para apresentar links para posts customizados que sejam complexos. Deixo como exemplo daquilo que é possível atingir um printscreen destes links dum plugin de encomendas que criei para um cliente:

É fantático não é? Então vamos a isso. O código é simples e muito direto irei apenas dar os componentes necessários para você criar as suas próprias estruturas:

add_filter( 'views_edit-film', 'film_views', 10, 1 );
function film_views( $views ){
  // Aqui vão as views customizadas
}

Este é o filtro que pode usar para criar os links de estado customizados. Imagine que gostava de criar novos estados para os filmes, por exemplo: “Pré-lançamento” e “Estreias”.

Primeiro Passo: vamos criar um campo customizado chamado ‘_estado_film’ da maneira descrita no artigos anteriores.

Segundo Passo: criamos os links que vão aparecer no espaço das views (dentro da função film_views):

Primeiro vamos pesquisar se não estamos a aceder a um destes estados e seguidamente criamos os links, isto para cada um deles:

// Pré-lançamento
$class = ( isset( $_REQUEST['meta_value'] ) && $_REQUEST['meta_value'] == 'pre' ) ? 'current' : '';
$views['pre'] = 'Pré-lançamento';

// Estreias
$class = ( isset( $_REQUEST['meta_value'] ) && $_REQUEST['meta_value'] == 'estreias' ) ? 'current' : '';
$views['estreias'] = 'Estreias';

return $views;

Neste código nós criamos mais dois estados que irão aparecer como links. Em cada um, procuramos se a URL contém a variável meta_value e se o seu valor é um dos dois estados definidos anteriores, para se poder aplicar a class current. Em seguida criamos os links para cada view.

NOTA BREVE SOBRE WORDPRESS E PHP

O WordPress é uma fantástica plataforma como framework de criação de novas funcionalidades e bastante bem desenhada e fácil de compreender, pois apresenta uma variedade enorme de filtros e acções para utilizar, isto além de racionar bastante o uso de classes, fazendo-o onde é apenas necessário.

Pessoalmente, não sou muito fã do sistema de classes em PHP, primeiro porque instanciar objectos em scripts torna-se lento, e segundo porque o sistema de classes no PHP5 está, no meu entender, “mal” acabado – são muitas as questões que não estão bem explicadas e não se sabe bem para que servem, e portanto na prática estas não têm muita utilizade.

Porém, assim que você começar a ser um bom programador de tipos de posts vai perceber que são muitas as APIs que necessitam de ser corrigidas ou acabadas, mas há sempre uma forma de se dar a volta.

Sempre que você encontrar alguma lacuna, pode sempre criar um patch e submetê-lo no trac do WordPress em http://core.trac.wordpress.org/

Espero que este artigo tenha aumentado a sua visão em relação aos tipos de post. E lembre-se, a curva de aprendizagem existe sempre, mas com gosto e persistência acabamos sempre por conseguir vencer os obstáculos.

Lembre-se de comentar este artigo, e se tiver novos codigos compartilhe.

Bons estudos e até para a semana.