Marcelo MesquitaRT: @felipernb: Trabalhe duro, pois milhões de pessoas que vivem do Fome Zero e do Bolsa Família, sem trabalhar, dependem de você.


Migrando conteúdo do Drupal para o WordPress

Da necessidade de migrar o conteúdo do Drupal para o WordPress, surgiu o plugin para o Drupal chamado ‘Drupal to WordPress’. Durante o desenvolvimento desse plugin tive a oportunidade de conhecer um pouco mais sobre o Drupal e ficarei grato se nunca mais precisar trabalhar com ele.

A instalação básica do Drupal gera 47 tabelas e isso dificulta muito o trabalho de migração dos conteúdos. Entendo que isso torne o sistema mais ‘completo’, mas fico pensando em quantas instalações do Drupal realmente utilizam todas essas tabelas. Acredito ser muito mais interessante um sistema enxuto com possibilidades de expansão e é por isso que gosto tanto do WordPress.

Portanto, aos usuário de Drupal que quiserem experimentar algo novo, heis a chance!

Descrição

Esse plugin recupera o conteúdo dos nodes, comentários e anexos do Drupal, qualquer outro conteúdo inserido através de plugin não é recuperado. Ele separa os tipos de nodes em categorias no WordPress já que as categorias no Drupal não são obrigatórias.

Instalação

  1. baixe o plugin;
  2. descompacte-o no diretório ’sites/all/modules/’ ou ’sites/nome-do-seu-site/modules/’;
  3. vá para ‘Administer › Site building › Modules’;
  4. marque o módulo ‘Drupal to WordPress’;
  5. salve as configurações.

Modo de usar

Backup

Após a instalação deverá aparecer um novo item no menu chamado ‘Drupal to WordPress’, basta clicar nele para baixar o arquivo de migração. Caso o item do menu não apareça, você pode digitar o endereço do seu site em Drupal seguido de ‘drupal_to_wordpress’, por exemplo: http://www.meusite.com/drupal_to_wordpress

Restauração

  1. faça o login no WordPress;
  2. vá para ‘Ferramentas › Importar’;
  3. selecione o item ‘WordPress’;
  4. faça o upload do arquivo de backup;
  5. informe o nome dos autores;
  6. marque a opção ‘baixar e importar arquivos anexos’ para copiar os arquivos do Drupal;
  7. clique em enviar.

Download


Criando Meta Boxes

Na versão 2.7 o WordPress estreiou as meta boxes, que são aquelas caixinhas arrastáveis que estão presente no dashboard, na área de edição de posts e páginas além de outros locais na área administrativa do WordPress.

Muitas vezes, na criação de plugins que interajem com os posts ou páginas, é necessário adicionar um novo campo à area de edição. Afim de manter a formatação do WordPress, a criação de uma meta box é o caminho mais limpo e fácil. Também é possível adicionar as metaboxes as páginas dos seus plugins, mas é uma tarefa um pouco mais complicada, então vamos deixar para outro artigo.

add_meta_box($id, $title, $callback, $page, $context=’advanced’, $priority=’default’, $callback_args=null);

Essa função é a responssável por adicionar a meta box a uma determinada página. O $id é o identificador único para o HTML, é com esse identificador que o WordPress manipulará sua metabox. Já o $title é o título da metabox, $callback é a sua função que ficará responssável pelo carregamento do conteúdo dentro da metabox e $page é a página onde a sua metabox será carregada (’page’, ‘post’, ‘link’, etc). Os outros parâmetros são opcionais: $context define o local da página onde sua metabox será carregada por padrão (’normal’, ‘advanced’, ’side’) enquanto $priority diz o posicionamento padrão da metabox dentro do $context (’high’ ou ‘low’), e por fim $callback_args que permite a passagem de argumentos à metabox.

Por exemplo, para criar uma metabox que mostre uma frase de incentivo (não consegui pensar em algo mais simples e útil) na parte de cima do sidebar da tela de edição de posts, ficaria assim:

add_meta_box('incentivador', 'Incentivador', 'incentive_me', 'post', 'side', 'high');

Não se esqueça de criar a função ‘incentive_me’ em seu plugin.

Agora só falta adicionar um gancho para a chamada da metabox:

add_action('do_meta_boxes', 'incentivador_metabox');

Onde ‘incentivador_metabox’ é a função que conterá o seu add_meta_box.

O código final ficaria assim:

<?php
/*
Plugin Name: MetaBox: Incentivador
Description: Mostra uma frase
Version: 0.1
Author: Marcelo Mesquita
Author URI: http://www.marcelomesquita.com/
*/

add_action('do_meta_boxes', 'incentivador_metabox');

function incentivador_metabox()
{
    add_meta_box('incentivador', 'Incentivador', 'incentive_me', 'post', 'side', 'high');
}

function incentive_me()
{
    $frases = array(
        'Você consegue!',
        'Faça seu melhor!',
        'Tudo é possível!'
    );

    print $frases[rand(0, 3)];
}
?>

Para saber mais acesse a Referência da Função add_meta_box


Criando Widgets para o WordPress 2.8

Como todos já devem saber, foi lançada a versão 2.8 do WordPress e entre as principais melhorias está novo sistema de widgets. A interface do usuário está muito mais simples de utilizar, todos os widgets e sidebares ficam listados, basta arrastar um widget para o sidebar desejado e pronto! O WordPress salva automaticamente o sidebar, além disso os widgets já são multiplicáveis então não é mais necessário ficar regulando a divisão deles ou utilizar plugins que façam a duplicação.

Mas a melhoria não foi só na interface com o usuário, a criação dos widgets também ficou muito mais simples, o WordPress disponibiliza uma classe com todo o código bruto para o funcionamento dos widgets sobrando para o desenvolvedor apenas algumas funções específicas.

A API dos Widgets do WordPress fornece um modelo para a criação dos widgets:

class My_Widget extends WP_Widget {
	function My_Widget() {
		// widget actual processes
	}

	function widget($args, $instance) {
		// outputs the content of the widget
	}

	function update($new_instance, $old_instance) {
		// processes widget options to be saved
	}

	function form($instance) {
		// outputs the options form on admin
	}
}
register_widget('My_Widget');

Explicando rapidamente, nesse modelo você cria uma classe ‘My_Widget’ filha de uma classe ‘WP_Widget’ que é a classe fornecida pelo WordPress contendo o código bruto, restando ao desenvolvedor a definição dos métodos:

My_Widget()

O construtor deve sempre ter o mesmo nome da classe ou se chamar __construct (depende da versão do PHP). No construtor são definidos o id, o nome, a descrição, e outras informações relativas ao widget.

widget($args, $instance)

Esse método define a forma como o widget é apresentado no tema. O parêmetro $args é um array contendo a formatação da estrutura do widget como: tags de abertura e fechamento do widget e do título do widget além do nome e id do widget.

O conteúdo dessa função não muda muito em relação ao modelo anterior dos widgets que era chamado pelo ‘register_sidebar_widget’, a única diferença é que o conteúdo da função, antes carregado do banco, agora vem todo no array $instance.

form($instance)

O médoto form representa a inteface administrativa do widget, onde é feita a configuração do mesmo, sua definição não é obrigatória.

Esse método é o espelho da função chamada pelo ‘register_widget_control’, mas aqui fica somente a estrutura do formulário. Assim como o método ‘widget’, aqui os dados não precisam mais serem carregados do banco, o array $instance traz todos os dados. O que notei de diferente na montagem do formulário foram apenas as nomeclaturas dos campos, agora tendo que ser feita da seguinte forma:

<input type="text" id="<?php print $this->get_field_id('nome-do-campo'); ?>" name="<?php print $this->get_field_name('nome-do-campo); ?>" value="<?php print $instance['nome-do-campo']; ?>" />

update($new_instance, $old_instance)

Também não é necessária a definição do método update. É esse método que realiza o processamento dos dados antes de salva-los no banco. O parâmetro $new_instance contém os dados novos (os que acabaram de ser informados) enquanto o $old_instance contém os dados antigos, para o caso de ser necessário fazer uma comparação.

Após o processamento dos dados, um array com os dados finais deverá ser retornado.

Não pretendo explicar novamente a lógica de criação de um widget, portanto vou simplesmente refazer o widget ‘Posts Mais Quentes’ nesse novo modelo e caso tenham dúvidas, consultem o post Opções de Widgets.

<?php
/*
Plugin Name: Widget: Posts mais quentes
Description: Lista posts mais comentados
Version: 0.3
Author: Marcelo Mesquita
Author URI: http://www.marcelomesquita.com/
*/

// Posts Mais Quentes
class Widget_Posts_Mais_Quentes extends WP_Widget
{
	function Widget_Posts_Mais_Quentes()
	{
		$this->WP_Widget('posts_mais_quentes', 'Posts Mais Quentes');
	}

	function widget($args, $instance)
	{
		global $wpdb;

		// Valor padrão, caso nada tenha sido informado
		if(empty($instance['quantidade'])) $instance['quantidade'] = "5";
		// Recuperando os posts
		$hot_posts = $wpdb->get_results("SELECT ID, post_title, comment_count FROM {$wpdb->posts} WHERE post_status = 'publish' ORDER BY comment_count DESC LIMIT {$instance['quantidade']}");

		if(empty($hot_posts))
			return false;

		// Usando o modelo de widgets do tema
		print $args['before_widget'];
		print $args['before_title'] . $instance['titulo'] . $args['after_title'];
		print "<ul>";
		// Listando os posts mais quentes
		foreach($hot_posts as $hot_post)
			print "<li><a href='" . get_permalink($hot_post->ID) . "'>{$hot_post->post_title} ({$hot_post->comment_count})</a></li>";
		print "</ul>";
		print $args['after_widget'];
	}

	function update($new_instance, $old_instance)
	{
		return $new_instance;
	}

	function form($instance)
	{
		?>
			<p>
				<label for="<?php print $this->get_field_id('titulo'); ?>">Título:</label>
				<input type="text" id="<?php print $this->get_field_id('titulo'); ?>" name="<?php print $this->get_field_name('titulo'); ?>" maxlength="26" value="<?php print $instance['titulo']; ?>" class="widefat" />
				<label for="<?php print $this->get_field_id('quantidade'); ?>">Quantidade:</label>
				<input type="text" id="<?php print $this->get_field_id('quantidade'); ?>" name="<?php print $this->get_field_name('quantidade'); ?>" maxlength="2" value="<?php print $instance['quantidade']; ?>" class="widefat" />
			</p>
		<?php
	}
}
// register widget
add_action('widgets_init', create_function('', 'return register_widget("Widget_Posts_Mais_Quentes");'));

Boa sorte!


Regex em JavaScript para remover tags

Expressão regular em JavaScript para remover as tags de um texto:

text = text.replace(/<[^>]*>/g, "");

Onde text é o texto formatado com as tags.


Minhas impressões sobre o BuddyPress

Estive trabalhando no projeto Cultura Digital e não tem sido uma tarefa fácil. Grande parte da dificuldade que estamos tendo é atribuída ao BuddyPress. Ele não parece ter sido desenvolvido para o WordPress, suas tabelas e códigos (tanto interface quanto programação) não seguem um padrão semelhante ao do WordPress (”Code is Poetry”).

Banco de Dados

Me espantei na primeira vez que resolvi analisar a estrutura de dados do BuddyPress; vinte e uma tabelas novas criadas! A instalação original do WP utiliza apenas dez tabelas, a do WPMU necessita de dezesete, por que diabos o BP precisaria de vinte e uma só pra ele, resultando em trinta e oito no total (BP + WPMU).

Após gerar o modelo de dados do BP pude ter uma visão mais ampla da bobagem que haviam feito:

Nomeclatura das tabelas

Nomes como ‘wp_bp_acivity_user_activity’, ‘wp_bp_acivity_user_activity_cached’, ‘bp_messages_messages’ ou ‘bp_messages_threads’ já eram em si um quebra-cabeça a ser decifrado.

Normalização das tabelas

Ao começar a trabalhar com as tabelas não pude deixar de notar a quantidade de campos ‘user_id’ espalhados por tabelas, de alguma forma, conectadas. O caso mais claro foi o das tabelas ‘bp_activity_user_activity’ e ‘bp_activity_user_activity_cached’ que já são ligados através do campo ‘item_id’ mas ambas possuem os campo ‘user_id’.

Outro caso que me fez perder alguns cabelos foi o da tabela ‘bp_messages_threads’ que apenas mantém a ligação das mensagens que são respostas a outras mensagens. Isso poderia ser feito simplesmente criando um auto-relacionamento na tabela ‘bp_messages_messages’.

Dados redundantes

Acredito que o pior de tudo foi descobrir que algumas tabelas criadas pelo BuddyPress nem precisavam existir, pois serviam para armazenar informações que podiam ser armazenadas nas tabelas do WordPress.

Destaco o conjunto de tabelas ‘bp_xprofile_fields’ e ‘bp_xprofile_data’ que server para adicionar novos campos ao perfil do usuário. Para passar uma idéia, uma única tabela do WordPress substitui essas duas do BuddyPress, o plugin Register Plus é um exemplo de como isso pode ser feito. O único motivo, que vejo para que o BuddyPress tenha feito essa separação, seria para obter ganhos em performance, mas o fato de existir um campo para cada dado me fez pensar que a performance estaria equilibrada já que na tabela ‘usermeta’ esses dados poderiam estar em forma de array e, assim, ocupariam um campo apenas.

Também não gostei da forma como o BuddyPress trata as atividades. Apesar das atividades do site serem o conjunto das atividades de cada usuário, os dados ficam duplicados em diferentes tabelas. Por exemplo: Ao alterar meu perfil uma nova atividade é cadastrada na tabela ‘bp_activity_user_activity’ e depois a mesma informação é cadastrada na tabela ‘bp_activity_sitewide’.

Codificação

A codificação também ficou a desejar.

Funções engessadas

Diferente do WordPress onde as ‘template tags’ (funções que auxiliam a montagem do tema) praticamente não interferem na forma como o html é montado, no BuddyPress algumas ‘template tags’ carregam muito lixo e apresentam um visual pré-definido. Isso dificulta a personalização do tema pois força a alteração dos arquivos do BuddyPress para atingir um resultado esperado.

Por exemplo: a função que carrega os dados do perfil (xprofile_get_profile) monta uma tabela zebrada (uma linha clara outra escura), apenas com os dados informados e adiciona link a cada item. Mas a zebra que o BP monta é baseada nos dados que estão no banco, então se eu tiver deixado algum campo vazio a tabela acaba pulando uma cor deixando duas linhas claras e uma escura ou algo parecido. Se eu quiser corrigir essa zebra ou retirar os links dos dados eu precisarei criar uma função do zero para não ter que ‘hackear’ o BP.

Mistura de tema com plugin

Os temas são muito dependentes de funções definidas nos plugins. Essa questão é mais ou menos a mesma citada no item acima, imagine tentar criar uma nova função apenas para recuperar os membros ou pense na dor de cabeça que é ficar alternando entre plugins e tema para entender como tal trecho de código é montado.

Conclusão

O BuddyPress tem muito a evoluir antes de se tornar um sistema confiável, acredito que o principal é voltar os esforços para deixá-lo mais compatível com o seu hospedeiro, o WordPress. Assim poderá haver uma maior compatibilidade entre os plugins e temas, além de diminuir a curva de aprendizado para os desenvolvedores que já trabalham com o WordPress, o que, na minha opinião, poderá resultar em um impulso na comunidade BuddyPress.