CSS do TinyMCE

A primeira é fundamental para quem usa o módulo Image Assist, que torna fácil a inserção de imagens no editor. O problema é que ao deixar uma imagem flutuando na direita ou esquerda, o editor (no caso o TinyMCE) não exibe o HTML corretamente, fazendo uma bagunça horrível na tela.

Claro que é muito mais preciso escrever tudo em HTML direto. Mas e quem não sabe HTML? Por exemplo, clientes. Para isso, o Image Assist e um editor Wysiwyg são fundamentais. Para funcionar é o seguinte:

• primeiro, é preciso fazer o TinyMCE ler um arquivo CSS customizado. Essa dica [Drupal: How to increase the default font size in TinyMCE] funciona bem. Vale a pena também aumentar o tamanho das fontes, que por default são minúsculas
• depois, para fazer o TinyMCE exibir os “img floats” é só copiar os estilos do arquivo img_assist.css (na pasta do módulo)  para esse CSS customizado
• se quiser alterar o tamanho padrão do editor, o mais fácil é definir a altura e largura para “body.section-node-edit textarea#edit-body.form-textarea” direto no CSS do tema

Pronto, agora o TinyMCE do Drupal funciona melhor que o do Wordpress! Mas isso depende desse tipo de customização.

Legendas para imagens do CCK

Essa aqui também era tudo que eu precisava! Talvez outras pessoas tenham o mesmo problema:

Um campo customizado do tipo imagem, criado com o CCK, tem a desvantagem de não ter legendas. Mas esse tipo de campo é imprescindível para podermos listar imagens em views (por exemplo, para mostrar automaticamente imagens em chamadas), coisa muito mais difícil de fazer com o Image Assist.

Simplesmente escrever a legenda embaixo da imagem não funciona, pois ela “vai para o saco” em uma simples paginação ou outros casos.

Como então fazer a legenda? Dá para criar um arquivo de template que pega a informação de alguma tag interna da imagem (title, alt ou description) e exibe isso como legenda. Bingo!

A dica que usei e funciona é essa aqui: Printing the Description (or Title) Below the Image.

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.

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.

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.