Os novos tipos de conteúdo, registrados em functions.php, aparecem na interface de administração

Ainda não tinha tido tempo de ver o Wordpress 3. Estava bem curioso para ver como funciona o esquema de “custom post types”. A princípio, fiquei desapontado. Na interface de administração não há nada, é tudo via código. Mas depois me animei.

Esse era o recurso que faltava no Wordpress. Agora não é preciso mais ficar fazendo gambiarras com categorias para usar tipos de conteúdo diferentes.

Na verdade, não tem segredo nenhum: é bem simples criar um novo tipo de post.

Apesar de o recurso estar ainda numa fase inicial, junto com as novas taxonomias, o Wordpress agora se aproxima do Drupal, no quesito “CMS para conteúdos mais complexos”.

Sempre que precisava escolher o CMS de um projeto, se o conteúdo fosse além das páginas fixas + blog, era Drupal na certa. Agora, o páreo fica mais concorrido. Ainda mais considerando os pontos fortes do WP: facilidade para design e a imbatível interface de administração.

Só falta agora um plugin WP equivalente ao Views do Drupal, para podermos criar rapidamente consultas e listagens desses diferentes tipos de conteúdo.

Leia mais:
Como criar Custom Post Types no Wordpress 3.0

Me deparei com essa questão migrando um blog (samsara.blog.br) do Blogger para Wordpress (com hospedagem própria). Como já era domínio próprio, não foi tão complexo:

1 – Permalinks

Depois de importar todo o conteúdo, com o domínio já funcionando no novo esquema, é preciso configurar o WP para usar a mesma estrutura de URL de posts do Blogger: dominio/ano/mês/titulo. Basta selecionar essa opção nas configurações de permalinks do WP.

2 – Corrigindo as URLs

Um problema surge aqui pois, após a importação, muitas URLs ainda não batem. Isso porque o modo como os títulos são montados na URL já foi diferente no Blogger: há alguns anos, todos os caracteres com acentos eram removidos. Como esse site tinha conteúdo de até quatro anos atrás, dezenas de URLs estavam desse jeito, com caracteres acentuados faltando.

A boa notícia é que, durante a importação de posts, o WP guarda todas as URLs originais em um campo extra. Então bastaria uma query SQL para arrumar tudo. Mais fácil ainda: encontrei um script PHP que já faz isso (Moving From Blogger To Wordpress – Maintaining Permalinks, Traffic & SEO):

<?php
require_once('wp-load.php');

$res = $wpdb->get_results("SELECT post_id, meta_value FROM $wpdb->postmeta WHERE meta_key = 'blogger_permalink'");
$wpdb->print_error();

foreach ($res as $row){
$slug = explode("/",$row->meta_value);
$slug = explode(".",$slug[3]);

$wpdb->query("UPDATE $wpdb->posts SET post_name ='" . $slug[0] . "' WHERE ID = $row->post_id");
$wpdb->print_error();
}

echo "DONE";
?>

Ao rodar esse PHP, as URLs originais são restauradas.

3 – Redirecionando o “.html”

Para não ter que deixar os endereços terminando em “.html”, como faz o Blogger, ainda é preciso mais uma etapa: redirecionar “dominio/ano/mês/titulo.html” para “dominio/ano/mês/titulo/”, o padrão WP.

Uma linha no .htaccess resolve:

RewriteRule ^([0-9]{4})/([0-9]{1,2})/([^/]+)\.html$ $1/$2/$3/ [QSA,R=301,L]


O .htaccess inteiro fica assim:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^([0-9]{4})/([0-9]{1,2})/([^/]+)\.html$ $1/$2/$3/ [QSA,R=301,L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
<IfModule mod_rewrite.c>

E pronto! Todas as URLs antigas dos posts agora funcionam no novo site.

O motivo de o Blogger deixar os endereços terminando em “.html” (artificialmente, já que não se tratam de páginas estáticas) é discutível. Uns dizem que se deve a algum benefício em termos de SEO; outros que isso é mero resquício operacional de algo que já não é necessário. Como se trata de uma empresa Google, talvez valha a pena analisar melhor a questão.

Eu prefiro sem o “.html” e nunca notei nenhum prejuízo por isso. Mas quem quiser deixar o “.html” basta pular a etapa 3 e configurar uma estrutura personalizada nas configurações de permalinks do WP.

Spam automaticamente para onde deve ir: no lixo

Uma ótima opção para acabar com comentários-spam no Wordpress é o plugin WP-Hashcash.

Fazia tempo que queria testar isso, ao notar que esse é o plugin usado em instalações-padrão do Wordpress na Dreamhost.

Funciona — e é incrível como não ter que ficar lidando com spam aumenta a qualidade de vida!

Apache, MySQL, PHP estilo Mac

Nos útltimos anos me tornei agnóstico no que se refere a sistemas operacionais. Gosto um pouco até da Microsoft! O Windows 7.

Em casa, preferia Ubuntu Linux. Mas usava Mac no trabalho. E por sempre precisar encarar um Windows também, acabei aprendendo umas manhas que o tornam bem usável até.

Melhor assim. Apego = sofrimento.

Mas trabalhar com o MAMP, no Mac, não deixa de ser uma brisa! A gente arrasta a pastinha para Aplicativos e pronto, impressionante! Apache, PHP, MySQL, configurações… tudo ali. Sem nem uma encostadinha no Apache do sistema.

Mas cadê a emoção? Tem também! Na primeira vez, o MAMP pode provocar uns bons desconfortos. Principalmente se combinado com o Drupal.

Vou deixar registrado aqui umas dicas pra quem precisar (como eu mesmo no futuro).

Tela branca da morte

Se estiver caindo na temível “tela branca da morte”, ou seja, nenhum aviso de erro, carregamento da página, nada, apenas a tela branca no navegador, melhor re-ativar as mensagens de erro do PHP. No MAMP, elas vêm desativadas por padrão.

Applications/MAMP/conf/php5[ou 4]/php.ini

Nesse arquivo, a linha 277 deve ser:

display_errors = On

Depois basta reiniciar os servidores.

Memória

Depois disso, mensagens de erro vão surgir no admin do Drupal. É preciso aumentar o limite de memória por script, na linha 232:

memory_limit = 32M

Vem por padrão com 8M (MB), o que não dá nem para listar os módulos do Drupal. Em meus testes, 32M deu pro gasto. Mas é só ir aumentando conforme a necessidade.

Localhost no Parallels

Outra dúvida comum é: “Como fazer o Internet Explorer acessar o localhost de dentro do Parallels?”.

Assim:

1. Acesse no Mac: Preferências do Sistema | Rede
2. Copie o IP de Parallels Shared Networking Adapter
3. Edite o arquivo hosts do Windows (Windows\System32\drivers\etc), acrescentando uma entrada direcionando o IP acima para um nome qualquer (não use “localhost”, já que ele já está sendo usado)
4. Pronto, agora acesse o localhost do Mac no Internet Explorer com esse nome

Atualização: descobri agora outro problema chatinho, com o Wordpress:

Abrir uma instalação local do Wordpress no MAMP, pelo IE do Parallels, não carrega o CSS. Isso acontece porque o Wordpress internamente usa caminhos absolutos para acessar estilos. Ou seja, se o endereço do Wordpress no Parallels e no Mac forem diferentes, o CSS não vai carregar.

Dá pra contornar usando o mesmo alias nos dois.

Por exemplo, se no arquivo hosts do Windows você acrescentou o alias “localhost2″ apontando para o IP do Mac, então acrescente esse mesmo alias no arquivo hosts do Mac (/etc/hosts; é preciso editar via Terminal), apontando para o mesmo IP que o alias localhost do Mac já aponta.

Aí o endereço fica sendo o mesmo tanto no Mac quanto no Parallels, algo como localhost2:8888/wordpress.

Atualização 2: Mais problemas… Esse é bem chato. Se não conseguir mais acessar a página inicial do MAMP e surgir a mensagem “No permission to access MAMP on this server”, dá pra resolver editando o arquivo MAMP/conf/apache/httpd.conf.

Mude “AllowOverride All” para “AllowOverride None”.

Esse é um bug muito chato porque ele surge sem mais nem menos, de repente, completamente misterioso. Não foi só comigo. Chato também porque, teoricamente, essa mudança deveria impedir a leitura de configurações do .htaccess. Não impede! Outra coisa misteriosa.

Joomla

Vou aproveitar que o post descambou de vez para problemas e mais problemas do MAMP para falar de mais um. Na verdade é um problema do Joomla.

Se estiver usando o Joomla com o MAMP, pode ser que tenha problemas com as URLs amigáveis. Por algum motivo, o Joomla não reconhece a porta padrão 8888 do MAMP e duplica o endereço do site nos links internos, quando as URLs curtas são ativadas.

Dá pra contornar isso mudando a porta para o padrão do Apache (80) nas preferências do MAMP (isso deve dar algum conflito com o Apache do Mac, caso ele também esteja sendo usado).

Como tudo fica no nosso computador, o processo agiliza bastante:

• As mudanças no site são instantâneas
• Não há necessidade de ficar subindo cada arquivo editado, basta um refresh no navegador

Em Linux e Mac, nunca tive dificuldade para instalar e configurar. Ultimamente, usando Windows 7, foi uma boa surpresa descobrir que é tão fácil quanto (com o WampServer).

Importar banco de dados

Usando Wordpress, uma coisa um pouco chata é que na hora de passar tudo para o servidor web real, você importa o banco de dados e o site simplesmente implode: nada funciona mais.

Mas há uma gambiarra simples que contorna isso. Basta editar o arquivo .sql:

1. Exporte o banco de dados — com o PHPMyAdmin, por exemplo — em um arquivo .sql
2. Abra o arquivo em um bom editor de código, como o Notepad++
3. Dê um “find & replace”, substituindo “localhost” pelo domínio do servidor online
4. Importe o arquivo no servidor web real (se o arquivo for maior que 2 MB, vai haver problemas. A etapa 6 deste tutorial ajuda a resolver a coisa)
5. Pronto!

Com o Wordpress, isso funciona até que bem. Só há um erro que ainda não entendi: alguns widgets somem após a importação, sendo necessário reposicionar e configurar. Mas esse é um preço baratinho até pela comodidade de desenvolver localmente.

Arquivo “hosts”

Além desse método, há um outro mais simples ainda:

• Abra o arquivo “hosts” e acrescente a linha “127.0.0.1  seudominio.com.br”
• No Windows 7, o arquivo fica em “Windows\System32\drivers\etc\” (em Linux e Mac, fica em /etc/ )

Isso faz com que cada requisição a “seudominio.com.br” seja redirecionada para “localhost”. Assim, é possível importar o banco de dados local no servidor online, sem edição nenhuma.

O único incômodo é ter de ficar comentando e descomentando (#) a nova linha do arquivo hosts sempre que precisar acessar o domínio verdadeiro e vice-versa.

Nesse vai e vem, tem hora que já nem sei mais se estou no localhost ou no domínio online. Mas dá para acostumar e considero um preço barato também pelo tempo que isso poupa.

Plugin permite criação fácil de formulários de contato

O Contact Form 7 está entre os primeiros plugins que costumam ser instalados após uma instalação fresquinha do Wordpress. Com ele, é bem simples criar formulários de contato, cujos dados são enviados por email.

É fácil de usar e tem bons recursos, mas pode dar uma bela dorzinha de cabeça. Estou escrevendo isso pois encontrei muito pouca coisa na web sobre os possíveis problemas. Por exemplo:

1. A função mail() do PHP do servidor pode estar configurada de maneira diferente ou nem estar disponível
2. Os emails podem terminar retidos como spam, levando você a imaginar que o problema está no plugin
3. Se você usar o Gmail para baixar mensagens de outras contas (via pop3), elas podem não chegar também, de novo parecendo que o problema está no plugin

Mail()

No primeiro caso, é preciso ajustar o plugin de acordo com as configurações do servidor em que o site está hospedado. Uma outra opção é usar o plugin Cimy Swift SMTP. Aí, em vez de depender do PHP mail(), você usa uma conta de email comum, através do acesso SMTP.

Spam

O segundo caso é o mais comum. Nos testes, você preenche os dados, aparece a confirmação de que tudo correu bem, mas não chega nada. O problema é que a opção default do Contact Form 7 usa o email da pessoa que preenche o formulário como remetente (“From:”).

Então, na checagem de spam dos servidores por onde a mensagem passa, é detectado que o email do remetente não bate com os IPs associados de onde saiu a mensagem (o servidor onde o site está hospedado). Essa é uma técnica comum para enviar spam. E a mensagem termina retida.

Para resolver isso, basta fixar um remetente como no-reply@seudominio.com (o importante é que o domínio seja o mesmo do seu site).

Gmail

Essa foi meio burrice minha. Mas pode acontecer com outras pessoas, então vou deixar registrado aqui também.

Para testar emails que são enviados para múltiplos destinatários, eu usava uma conta Gmail que puxa emails de diversas outras contas. Acontece que quando o mesmo email chega tanto na conta principal quanto nas secundárias, o Gmail não baixa a mensagem repetida. Isso me levava a pensar que os emails não estavam indo para os outros destinatários.

Difícil de identificar o problema, mas fácil de resolver: basta acessar diretamente a outra conta, em vez de tentar contar com o acesso pop3 do Gmail.

Lifestream

O feed tá aqui ao lado na barra esquerda.

Vagas para desenvolvedores Drupal, Joomla e Wordpress aumentaram muito no exterior (reprodução/Indeed.com)

De um ano pra cá, a procura por profissionais especializados em CMS (Content Management System) de código aberto disparou. Principalmente, Drupal.

É o que mostra por exemplo o Indeed.com, que monitora vagas de trabalho em vários países [via Web Worker Daily - The Open Source Opportunity].

O motivo é a tendência — novidade nenhuma aí — de migração dos sistemas por trás dos sites para soluções open source, ao invés de continuarem usando ferramentas comerciais/proprietárias, muitas vezes já obsoletas [OStatic - Publishers Are Switching to Drupal, Cost Savings Reported].

No caso do Drupal, o que pode estar puxando a onda é o exemplo de sites como Recovery.gov (da Casa Branca norte-americana) e MTV UK (o site da MTV brasileira também é Drupal!).

Devido às ricas opções para lidar com conteúdo/informação e para customização, o sistema costuma agradar muito também os responsáveis pelos sites de jornais e revistas como London Paper, Mother Jones e The Onion (um dos pioneiros).

Intranet em Drupal

Outra novidade bem interessante para os “drupalistas” foi o anúncio do Open Atrium, um moderno sistema de intranet todo baseado (e compatível) com Drupal [Drupal Mavens Unveil Open Atrium: An Intranet in a Box].

Open Atrium, sistema open source de intranet em Drupal (reprodução/Openatrium.com)

Achei uma solução: Unknown style tag 10px bigger than image – ugly margin.

Resumindo, pra não ter que editar o /wp-includes/media.php dá para usar um plugin com o código (de Justin Adie) exemplificado no link acima.

No início, levei um susto e cheguei a desistir de tentar aprender:  complexo demais à primeira vista. “Que framework nada, vou fazer é na raça”. Mas… sem chance! Daria muito mais trabalho. Então, voltei para o Thematic.

Ainda faltam vários ajustes finos e bugs a limar fora, mas já dá pra colocar no ar.

Vamo nessa…