Reboot

Pronto. Recomecei minha empreitada.

Mudança de host. Vontade de provocar uma mudança de foco para esta página, este meu espaço virtual. Talvez, escrever de uma maneira diferente. Para isso, precisava de um reboot. De um novo começo, de uma outra chance. E é isso o que pretendo fazer.

Não sei quantos ainda acompanham o site — e provavelmente, agora que eu o tirei do ar por um tempo e tinha colocado uma página temporária no ar, devem ser menos ainda. De qualquer modo, eis-me aqui de regresso.

Impressões? Feedbacks? Falem nos comentários, please.

Dois passos a seguir se você for atacado por um hack eval(base64

Para minha mais completa infelicidade, encontrei esta semana indícios de que eu — e este humilde blog —continuamos a ser vítimas de ataques de .

Mas você pode estar se perguntando como se faz para descobrir que você foi vítima de um ataque de script injection.

Bom, é fato que a maneira mais desagradável possível aconteceu comigo: Tentei acessar meu site um belo dia e descobri , informando que o site é inseguro. Daí precisei tomar uma série de medidas, entre as quais estas que estão descritas aqui, para recuperar tudo. Para que isso não aconteça com você, é importante examinar seu site periodicamente, tal como quando executamos anti-vírus em nossos computadores. Dois plugins que podem ser úteis neste caso são o Exploit Scanner e o Antivirus, sendo que confesso que prefiro o primeiro, por sua riqueza de informações. Também pode ser uma boa ideia utilizar o Sucuri Site Check, que informa a situação atual do seu site sob o ponto de vista de diversos sites especializados (há um plugin para WordPress que traz esta varredura para dentro do painel de administração, também).

Bom… se você, assim como eu, se deparar com alguma evidência de ataque, ou, no mínimo, com algum sintoma suspeito, pode seguir dois passos simples. Mas aviso que será necessário se munir de toda a paciência possível e fazer aquilo que eu acredito que seja a única opção plausível em uma situação destas: Executar alguns comandos diretamente no servidor via , para acabar com alguns comportamentos inadequados.

Se você quer uma dica de ferramenta para utilizar em uma conexão telnet (ou SSH, seu substituto mais recente e mais seguro), experimente o Putty. Para continuar a escrever este texto, assumirei que você já possui o Putty, ou outra ferramenta similar para o processo, e usarei minha própria experiência aqui no site como base.

Primeiro passo: Acabe com os arquivos world-writable

Antes de qualquer coisa, dado que fazia um boooooom tempo que eu não acessava minha conta e meus arquivos hospedados, resolvi dar uma olhada para ver se alguma de minhas pastas era, digamos, world-writable — ou seja, será que alguém do mundo exterior conseguiria alterar meus arquivos? Isto seria um enorme pecado. Para descobrir isso, já conectado ao servidor, executei a seguinte instrução:

find . -type d -perm -o=w

E, não é que, infelizmente, encontrei ? Para evitar que pessoas do mal pudessem continuar fazendo o que bem entendessem por aqui, executei mais um comando, para que as permissões dos arquivos em questão fossem alteradas, bloqueando o acesso do mundo exterior:

find . -type d -perm -o=w -print -exec chmod 770 {} \;

Segundo passo: Detecte quais são as infecções e as elimine

Dado que já suspeitava de que haviam arquivos vitimados com script injection, resolvi que seria importante saber quais eram os infectados. Arquivos infectados com script injection possuem linhas em seu conteúdo — geralmente no topo do arquivo, no final do arquivo, ou logo após a abertura da tag <html> — que se assemelham ao seguinte:

<!--<?php /**/ //eval(base64_decode(&quot;aWYoZnVuY3Rpb25fZ....?>

Um comando útil para listar que arquivos são os que contém o script injection é o seguinte:

grep -lr --include=*.php "eval(base64_decode" /caminho/do/seu/servidor

Se o output deste comando for diferente de nulo, como foi no meu caso, com mais de mil arquivos listados, pode ter certeza de que há script injection na parada. Mas não há problema, você pode se livrar desses arquivos facilmente. Basta executar um pequeno script de uma linha em perl — através da própria sessão aberta via telnet:

for f in `find . -name "*.php"`; do perl -p -i.bak -e 's/<\?php \/\*\*\/ eval\(base64_decode\(\"[^\"]+"\)\);\?>//' $f; done

O resultado deste script será a eliminação de todas as linhas, em todos os arquivos com extensão php, do trecho de código inserido através do script injection. O processo gerará arquivos de backup como resultado — vários arquivos com a extensão bak. Isso porquê, se algo der errado e você , você ainda terá os arquivos originais a seu dispor, ainda que infectados.

Se nada se quebrar durante o processo e você não tiver mais arquivos vitimados por script injection em seu site, vale citar um comando para apagar todos os arquivos .bak, recursivamente:

find . -type f -name "*.bak" -exec rm -f {} \;

Finalmente… uma faxina!

A etapa final, como eu a fiz, consistiu de passar um bom tempo dando uma olhada nos diretórios hospedados em cada um dos meus sites. Arquivos muito antigos foram para o beleléu — acreditem ou não, o que ocorreu no meu caso foi uma vulnerabilidade causada por um plugin de galeria de fotos esquecido há anos dentro do meu servidor — e tudo aquilo que eu julgava não saber do que se tratava, também (CUIDADO). Além disso, sempre vale dizer que é imporante resetar suas senhas. Todas. Agora.

Um ataque de script injection é aquele em que alguém, de maneira mal intencionada, se aproveita de falhas de segurança ou de vulnerabilidades em ferramentas como o WordPress para introduzir em seu código-fonte mecanismos que alterem o seu funcionamento normal. Ao visitar um site atacado, você poderia, por exemplo, ser direcionado para um endereço em que um programa mal intencionado ou vírus fosse baixado para seu computador. É por isso que estes ataques tem que ser combatidos.
Telnet é um protocolo cliente-servidor usado para permitir a comunicação entre computadores ligados em rede local, ou através da internet.
Arquivos com permissão de escrita fornecida para o mundo inteiro podem ser resultado de instalações ou desinstalações de plugins mal feitas, como foi o meu caso. Cuidado com o que instala ou deixa de instalar em seu website.
Sim,  veja que estas dicas não possuem garantia alguma, e, muito menos, são garantia de 100% de eliminação dos problemas . No entanto, é verdade, vale   pena tentar.

WPTouch to the rescue

São impressionantes as coisas nas quais começamos a pensar quando nos tornamos proprietários de um smartphone. Uma delas, sem sombra de dúvidas, é o desejo de que cada site que visitamos com nosso aparelho seja preparado para os dispositivos móveis — o que, infelizmente, nem sempre é verdade. Pensando em fazer a minha parte, no entanto, foi que instalei um plugin muito interessante para o WordPress, o WPTouch.

Em resumo, o que o plugin faz é instantaneamente transformar o tema do site — sempre que este for visitado através de um iPhone, iPod touch, Android, Opera Mini, Blackberry ou similar —, de maneira que a aparência se torne a de um aplicativo desenvolvido nativamente para iPhone, contando inclusive com efeitos e carregamento em AJAX. Acabo de testar o resultado, e fiquei bastante satisfeito.

Se você por acaso me visitar munido de um desses aparelhinhos, por favor, me dê feedback.

Traga mais Readability para o seu blog

Meu amigo Rodrigo Ghedin conseguiu, sem querer, me deixar preocupado com a aparência: Não a minha, é verdade — já que neste caso nem as versões mais avançadas e recentes de Photoshop dariam jeito —, mas com a do meu blog. Tudo isso porquê, há alguns dias atrás, ele falou, em mais um de seus excelentes posts, sobre o conceito de readability.

Para quem não sabe o que readability significa, eu vou simplificar: Trata-se, basicamente, de tornar o processo de leitura mais fácil.

Ao encontrarem condições que lhes permitam ler mais facilmente, os seres humanos têm melhoradas suas capacidades de compreensão, retenção e velocidade de leitura. E para quem estiver se perguntando o que isso pode ter — ainda que de longe — a ver com os blogs que lemos no dia-a-adia, eu explico, mais uma vez. Só que desta vez vou usar um trecho do post onde o Ghedin menciona leituras realizadas na web:

(…) mesmo nas leituras mais rápidas, essenciais ao trabalho que desempenho e muito útil para ler muita coisa boa que aparece em blogs, sites e outros locais,  s vezes me sinto incomodado. Não pelo monitor, mas sim pelo layout. Tem gente que publica um texto com fonte branca em fundo preto! A mim, o efeito é o mesmo que ficar meia hora olhando diretamente para uma lâmpada acesa. Meus olhos sentem essa agressão.

E esse problema de contraste é apenas um dos vários que existem. Tipografia mal escolhida, espaçamento inadequado, excesso de anúncios inseridos dentro do texto. Eu costumava pregar a máxima de que não importa aonde você escreva, o que importa, mesmo, é a mensagem. Bobagem! Já deixei de ler muita coisa boa porque a apresentação não colaborava.

Notem que um site mal cuidado, com qualquer um dos deslizes mencionados acima, pode estar prejudicando a facilidade de leitura de seus visitantes. Na prática, isso pode, inclusive, acabar se traduzindo em falta de fidelização dos leitores, ou seja: Eles podem nunca mais querer voltar ao seu site, pois se lembrarão, por exemplo, que precisaram de óculos escuros para proteger os olhos na última vez em que ali estiveram.

Felizmente, visando auxiliar a leitura de informações por milhões de internautas, um pessoal muito bacana desenvolveu um projeto — também, obviamente, chamado de Readability —, onde se encontra disponível um bookmarklet configurável para tornar qualquer página mais agradável de ler. O Rodrigo, muito oportunamente, ensina como fazer a configuração, passo-a-passo.

Com a existência de plugins prontamente disponíveis para a implantação de readability no Firefox e Google Chrome, o lado dos internautas está ainda mais garantido.

Mas acontece que eu fiquei pensando em como garantir que qualquer um que me visitasse pudesse ter acesso aos recursos de readability sem necessariamente contar com bookmarklets, extensões ou plugins. Esse conceito é tão interessante que deveria ficar ao lado de botões como os de compartilhamento de links no del.icio.us, ou de retweet, que hoje são amplamente vistos nos blogs por aí. E felizmente, não é nada complicado deixar o seu blog readability-ready.

O primeiro passo para isso é dar uma olhada no código fonte do bookmarklet que o Rodrigo ensina a configurar. No Firefox, basta clicar o botão direito sobre ele e selecionar a opção Propriedades. Você logo se deparará com algo assim no campo endereço:

javascript:(function(){readConvertLinksToFootnotes=false;readStyle='style-novel';readSize='size-medium';readMargin='margin-medium';_readability_script=document.createElement('script');_readability_script.type='text/javascript';_readability_script.src='http://lab.arc90.com/experiments/readability/js/readability.js?x='+(Math.random());document.documentElement.appendChild(_readability_script);_readability_css=document.createElement('link');_readability_css.rel='stylesheet';_readability_css.href='http://lab.arc90.com/experiments/readability/css/readability.css';_readability_css.type='text/css';_readability_css.media='all';document.documentElement.appendChild(_readability_css);_readability_print_css=document.createElement('link');_readability_print_css.rel='stylesheet';_readability_print_css.href='http://lab.arc90.com/experiments/readability/css/readability-print.css';_readability_print_css.media='print';_readability_print_css.type='text/css';document.getElementsByTagName('head')[0].appendChild(_readability_print_css);})();

Assustador, não é mesmo?

No entanto, não é necessário se preocupar com o que o código acima faz — que, na verdade, é somente aplicar readability   página que você está lendo. O importante é saber que é este o código que você precisará para permitir que qualquer um que visite seu site aplique readability nele. Na verdade, a coisa é tão simples que você precisará apenas criar um link em qualquer lugar da página onde escreveu um texto para que a pessoa possa clicar sobre ele. Vejamos a seguir como isso funciona no WordPress.

Acessando seu editor de temas, você precisará criar um link com o código acima no arquivo single.php — uma vez que o bookmarklet original é idealizado para transformar páginas com artigos individuais, e não sites inteiros, embora isso também possa ser feito. No meu caso, isso se traduziu da seguinte maneira:

<span class="readability">
 <a title="Torne este texto mais agradável de ler!" href="javascript:(function(){readConvertLinksToFootnotes=false;readStyle='style-novel';readSize='size-medium';readMargin='margin-medium'; _readability_script=document.createElement('script');_readability_script.type='text/javascript';_readability_script.src='http://lab.arc90.com/experiments/readability/js/readability.js?x='+(Math.random());document.documentElement.appendChild(_readability_script)_readability_css=document.createElement('link');_readability_css.rel='stylesheet'; _readability_css.href='http://lab.arc90.com/experiments/readability/css/readability.css';_readability_css.type='text/css'; _readability_css.media='all';document.documentElement.appendChild(_readability_css); _readability_print_css=document.createElement('link'); _readability_print_css.rel='stylesheet'; _readability_print_css.href='http://lab.arc90.com/experiments/readability/css/readability-print.css'; _readability_print_css.media='print'; _readability_print_css.type='text/css'; document.getElementsByTagName('head')[0].appendChild(_readability_print_css);})();">Readability</a>
 </span>

O único retoque que eu fiz foi acrescentar uma classe CSS para deixar a coisa um pouco mais bonita de se ver. Não sabia exatamente qual ícone utilizar, então optei por capturar o favicon do próprio projeto Readability:

.readability{
 display:line;
 background: transparent url(images/readability_16.png) no-repeat;
 margin-left: 5px;
 padding-left:26px;
 padding-bottom:5px;
 min-width:8px;
 }

O resultado já pode ser visto nas páginas individuais dos artigos aqui do blog. Espero, sinceramente, que desta maneira, eu esteja contribuindo para que as pessoas encontrem por aqui uma experiência de leitura um pouco mais agradável.

PS: Depois, com mais calma, pensarei em um jeito de tornar essa coisa um plugin para o WordPress.

Protegendo melhor o meu WordPress

Depois de ter sido recentemente atacado por uma script injection que surgiu do nada, fiquei mais cauteloso no que diz respeito ao blog, quando se trata de segurança.

No começo deste mês acabei encontrando um artigo da Smashing Magazine, com 10 dicas para reforçar a proteção de sites que, como o meu, utilizam o WordPress. Embora seja verdade que reforçar a segurança de um site por conta própria requeira um conhecimento mínimo de Apache — e não se sentir intimidado com alterações no arquivo .htaccess —, não há nada realmente muito cabeludo a se fazer.

Assim sendo, quero compartilhar com vocês duas das alterações que fiz:

Primeira coisa: Proteger o blog de injeções de script

Os ataques de injeção de scripts acontecem quando um hacker introduz algumas linhas de código malicioso em um site através de um de seus formulários — o de comentários, por exemplo — e então envia tais dados através deste formulário. Isso é feito, geralmente, para que se possa enganar os sistemas em uso nos sites, de maneira que eles pensem que se trata de conteúdo enviado por um usuário válido, e assim acabem permitindo, sem querer, que dados sejam acessados, editados excluídos, ou que scripts mal intencionados sejam acessados e instalem vírus nas máquinas dos internautas desavisados.

Uma das técnicas básicas para um script injection é que uma máquina cliente submeta informações que contem tags, como a tag <script>. Isso nos leva  s diretivas abaixo, sugerida no artigo que li:

Options +FollowSymLinks 
RewriteEngine On 
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR] 
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR] 
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2}) 
RewriteRule ^(.*)$ index.php [F,L]

Ao serem adicionadas ao arquivo .htaccess, tais diretivas fazem com que qualquer requisição de acesso   uma página no blog seja verificada. Caso ela contenha referências   uma tag <script> ou, mais ainda, tenha tentado modificar o valor das variáveis GLOBALS ou _REQUEST do PHP, a requisição será bloqueada com um erro 403 (“Forbidden“) do Apache, ou seja, quem quer que esteja tentando realizar o acesso — neste caso, provavelmente alguém muito mal intencionado — será impedido de fazê-lo. Você pode até criar um documento personalizado para recepcionar alguém que tenha recebido o erro em questão:

ErrorDocument 403 /forbidden.php

Uma última palavra sobre as diretivas acima, é que estas podem ser facilmente modificadas para que incluam também as tags  <object>, <applet> e <embed>, também utilizadas em script injections. Desta maneira, reforça-se ainda mais a segurança.

Segunda coisa: Proteger o arquivo wp-config.php

Quando li o artigo da Smashing Magazine, vi que eles recomendam a proteção do arquivo wp-config.php — onde residem todas as configurações principais do WordPress, inclusive nomes de usuário e senha do banco de dados, que permitem a qualquer um com más intenções acesse todo o conteúdo do seu blog e faça com ele o que bem entender —, o que, afinal de contas, é uma excelente ideia.

O único problema é que eles, mais uma vez, se valem de alterações no arquivo .htaccess, da seguinte maneira:

<files wp-config.php>
order allow,deny
deny from all
</files>

Acredito, no entanto, que uma solução muito mais efetiva para impedir o acesso ao conteúdo do arquivo seja movê-lo para um lugar inacessível publicamente. Na prática, normalmente, isso significa movê-lo para antes da pasta public_html — onde fica tudo o que é visível para o mundo lá fora — em sua conta de usuário. Felizmente, desde a versão 2.6 do WordPress, isso é possível. Dessa maneira, basta que você utilize um programa de FTP de sua confiança e mova o arquivo em questão um nível acima.

De qualquer maneira, a dica dada pela Smashing Magazine ainda é válida se adaptarmos um pouco as coisas: Por exemplo, podemos aproveitar para proteger não o arquivo wp-config.php, mas sim o próprio arquivo .htaccess, da seguinte maneira:

<files .htaccess>
order allow,deny
deny from all
</files>

Conclusão

É óbvio que a proteção de um site contra ataques envolve uma série de outros passos e medidas de segurança, e muito mais leitura e estudo. Ainda assim, minha decisão de dividir estas duas simples alterações se deu porquê acredito serem realmente de grande valia para alguém que está pensando em proteger melhor seu conteúdo, e espero que, desta maneira, esteja prestando um serviço a quem se encontrar em uma situação difícil.

Para maiores informações, recomendo também a leitura do excelente artigo Hardening WordPress, disponível no próprio Codex da ferramenta.

Meu blog foi atacado pelo zettapetta.js

Depois de estar ausente do site por — praticamente três semanas seguidas, descobri hoje que meu site foi vítima de um ataque em massa a blogs que são movidos a WordPress. A descoberta não ocorreu instantaneamente: Tudo começou porquê, ao logar no dashboard do WordPress, percebi que a aparência das coisas estava um tanto quanto diferente, como se houvessem apagado todos os arquivos css (da área administrativa) do site. Intrigado por não entender a origem do problema — afinal, eu não havia feito grandes atualizações ou instalado novos plugins recentemente —, já havia me rendido   solução desesperada padrão, reinstalar a última versão da ferramenta.

Durante a reinstalação, graças a um vício que possuo — ficar apertando F5 freneticamente para ver todas as mensagens (temporárias) de erro que aparecem enquanto os arquivos estão sendo recolocados no lugar —, percebi que meu site estava se conectando ao domínio zettapetta.com, e logo imaginei que provavelmente havia mais caroços neste angu do que eu realmente gostaria. Um pouco de investigação me levou a descobrir que um script injection prejudicou vários sites que usam o WordPress a partir dos dias 6 e 7 de maio de 2010.

Dentre os possíveis comportamentos inadequados encontrados nos sites invadidos, identifiquei, com a ajuda de um programa de FTP, que próximo ao cabeçalho de todos os arquivos .php da minha instalação de WordPress havia um código malicioso que começava da seguinte maneira:

<?php /**/ eval(base64_decode("aWYoZnVuY3Rpb25fZXhpc3RzKCdvYl9z.

Este era um indicador claro de que eu havia sido vítima do malware MW:MROBH:1, que se infiltra em sites como o meu e tenta instalar, nas máquinas de usuários desavisados, uma série de códigos maliciosos. Percebi que eu deveria fazer alguma coisa imediatamente.

Quando já estava me conformando com o fato de que perderia todo o conteúdo deste blog — pois as instruções iniciais de recuperação citavam medidas realmente drásticas, como excluir todos os arquivos do site —, acabei encontrando uma solução de clean up muito simples, graças ao site de segurança digital sucuri.net. Tal solução pode ser aplicada com o uso de SSH ou baixando um arquivo texto de lá — neste último caso, é necessário mudar a extensão do arquivo para .php, fazer o upload para o servidor do seu blog e executá-lo a partir de qualquer navegador. Em alguns instantes, uma mensagem similar a esta será exibida:

Tirei duas grandes lições deste episódio. A primeira, que nem sempre rodar a última versão disponível de um software te garante imunidade a algumas ameaças. A segunda, que ficar muito tempo sem visitar o próprio blog pode fazer com que estejamos executando ameaças como estas sem nem mesmo sabermos disso. Neste último caso, peço desculpas a quem quer que tenha visitado meu blog neste período de infecção, e seriamente recomendo que passem um anti-vírus atualizado em seus computadores.

Agora, voltaremos   programação normal.

Mudanças no visual

Extremamente cansado de todo e qualquer visual anterior deste blog nos últimos tempos, tomei uma decisão que considero um tanto quanto radical: Alterei totalmente a aparência do site, simplificando-o e tornando-o mais limpo e agradável aos olhos. Para isso, depois de meses ensaiando voltar a mexer um pouco com CSS — o qual eu não domino totalmente —, coloquei no ar o tema que você está vendo agora.

É possível que eu ainda altere alguma coisa — e até mesmo que acrescente alguns detalhes a mais, de forma bem sutil, mas o formato geral em si não deve mudar. Confesso que optei pelo custom design, iniciado com base em algumas inspirações minimalistas, depois de não ter achado nada que se enquadrasse no que venho pensando já há algum tempo ser a nova cara do blog: Posts provavelmente mais curtos e direcionados, mas sempre escritos com a melhor qualidade possível.

Espero que meus 2 ou 3 leitores restantes apreciem 🙂

Adieu, Tweetbacks: Olá, Chat Catcher!

ccbblQuem me acompanha mais de perto sabe que eu venho tentando, através de plugins para o WordPress, integrar tweetbacks ao blog. Minha insistência se baseia no fato de que, caso eu venha a escrever algo interessante ou minimamente útil, essa informação será comentada por uma ou mais pessoas através do Twitter, e eu gostaria de saber a respeito. Neste aspecto, ocorre que a integração através do plugin Tweetback realmente funciona para a maioria dos serviços de URL shortening, mas falha gravemente quando alguém faz uso do migre.me, site que é cada dia mais popular entre os usuários de microblogging brasileiros.

Tal mau funcionamento recentemente me levou há alguns dias a pedir ajuda não apenas ao desenvolvedor do plugin, mas também ao desenvolvedor do serviço brasileiro. Depois de esperar por um tempo razoável sem que houvesse qualquer resposta — fato que eu honestamente compreendo perfeitamente, pois imagino que ambos estejam tão ocupados quanto eu, com seus afazeres profissionais —, resolvi voltar   batalha, buscando qualquer alternativa que me fizesse obter um maior grau de êxito com minha vontade. Foi quando esbarrei sem querer com um artigo de Ari Herzog, especialista em mídias sociais que contribui para o site americano Mashable,  onde ele descreve a forma que ele próprio utiliza para incluir citações a seus artigos em seu blog. Trata-se de um serviço chamado Chat Catcher, criado pelo programador norte-americano Shannon Whitley e introduzido no começo deste ano em um artigo de seu blog pessoal.

O título do artigo de Ari Herzog realmente diz tudo: O Chat Catcher é mesmo mais inclusivo do que os tweetbacks, uma vez que inclui em suas buscas não apenas as citações realizadas através do Twitter, mas também aquelas que estiverem dando sopa em serviços como o FriendFeed e o Identi.ca. Basta que um artigo do seu blog apareça em um destes serviços e pronto: Uma referência a ele se tornará um trackback — ou um comentário comum, se você assim preferir, postado de volta no blog original. Entre as vantagens do Chat Catcher está o fato de que ele funciona com qualquer plataforma de blog que suporte trackbacks, e, mesmo quando isso não é possível, são oferecidas alternativas de integração scriptless. Há também um plugin para WordPress, que eu já instalei e testei aqui no blog.

Integração entre o Chat Catcher e o migre.me

Uma vez realizada a instalação, o procedimento é realmente muito simples: Na verdade, a única coisa realmente necessária é ir até as opções da página do plugin e clicar o botão Register this blog. Opcionalmente você pode listar usuários que deseja excluir das pesquisas — como o seu próprio usuário do Twitter, ou algum engraçadinho que esteja lhe mandando spam — e escolher se deseja tornar cada citação a um artigo seu um trackback ou comentário comum. Uma opção que eu não poderia deixar de mencionar é a possibilidade de moderar as citações antes que apareçam no corpo do blog.

Para concluir, é importante dizer que minha decisão final por adotar o Chat Catcher e abandonar o plugin anterior se baseia no fato de que o serviço cumpre o que promete: Lidar com qualquer serviço de URL shortening, resgatando citações custe o que custar. Neste aspecto, como ilustra a figura que se encontra neste artigo, até mesmo uma citação que eu mesmo fiz através do migre.me foi competentemente capturada. E isso, meus amigos, finalmente põe fim   esta novela.

Tentando fazer Tweetbacks e migre.me se darem bem

Até hoje eu não podia chegar a dizer que possuo um compactador de URLs favorito. De qualquer maneira, reconheço que este tipo de serviço é extremamente necessário nos tempos atuais, principalmente para qualquer um que se encontre  s voltas com a arte do microblogging, sobretudo o Twitter.

Tenho acompanhado a crescente utilização, pelos blogueiros brasileiros, de um compactador de URL 100% nacional. Trata-se do migre.me, que não apenas reduz os endereços para que caibam junto  s mensagens de 140 caracteres típicas dos serviços de microblogging, mas também atua como uma espécie de Digg brasileiro, computando URLs, vídeos e fotos populares no Twitter, o que eu acho simplesmente genial.

No entanto, é justamente o migre.me que vem me tirando o sono há alguns dias, tudo porquê, usuário do plugin Tweetback para WordPress como me declarei recentemente, estive  s voltas com tentativas de ajustar o código PHP do autor para fazer com que eventuais citações a meus artigos através do serviço brasileiro também aparecessem por aqui, entre os últimos comentários.

Minha batalha começou quando, recentemente, percebi que o migre.me já possui uma API. É verdade que dá um pouco mais de trabalho mexer com ela pra obter as URLs compactadas, já que é preciso ler um arquivo XML para que a mágica aconteça, mas nada de outro mundo.

No arquivo principal do plugin para WordPress que eu estou usando para exibir os Tweetbacks aqui no blog — tweetback.php — há uma função chamada fh_tweetback_getshorturl, que é, como o nome diz, responsável por obter as URLs compactadas de serviços como o tinyurl, bit.ly e outros. Foi lá onde eu acrescentei algumas coisas por conta própria para fazer com que também as URLs compactadas pelo migre.me fossem levadas em conta na hora de verificar se houve citações do Twitter por aqui.

A função em si ficou assim — notem que todos os comentários em inglês do autor do plugin foram mantidos… eu só acrescentei mesmo a parte do migre.me:

 function fh_tweetback_getshorturl($permalink,$provider='tinyurl.com') {
 $permalink = urlencode($permalink);
 //http://blog.cli.gs/news/analysis-of-linking-patterns-on-twitter-cligs-scores-well
 switch($provider) {
 case 'tinyurl.com':
 return fh_tweetback_curl('http://tinyurl.com/api-create.php?url='.$permalink);
 case 'is.gd':
 return fh_tweetback_curl('http://is.gd/api.php?longurl='.$permalink);
 case 'bit.ly':
 return fh_tweetback_curl('http://bit.ly/api?url='.$permalink);
 case 'twiturl.de':
 return fh_tweetback_curl('http://api.twiturl.de/friends.php?output=txt&new_url='.$permalink);
 case 'migre.me':
 $xml = simplexml_load_file('http://migre.me/api.xml?url='.$permalink);
 return (string)$xml->migre;
 /* blearg, I really dont feel like all that signupapikeystuffpostcomplicated, what the hell.
 * Maybe I'll have more motivation later on to register or do post mechanism, for now on
 * its just like that. tinyurl ftw! 🙂
 * (and yes, I understand why registration and keys can make sense. however, I am still too lazy for that.)
 case 'twurl.nl':
 return fh_tweetback_curl('http://is.gd/api.php?longurl='.$permalink);
 case 'snipurl.com':
 return fh_tweetback_curl('http://is.gd/api.php?longurl='.$permalink);
 case 'snurl.com':
 return fh_tweetback_curl('http://is.gd/api.php?longurl='.$permalink);*/
 default:
 return false;
 }
 return false;
 }

Pois bem: Devo dizer que, antes de partir para a alteração do código do plugin, fiz um teste em arquivo PHP separado para verificar se a obtenção de URLs aqui do blog compactadas pelo migre.me estava funcional, inclusive levando em conta que elas devem ser tratadas pela função PHP urlencode.

Os testes funcionaram perfeitamente. Uma maravilha, mesmo. No entanto, depois de começar a postar uma série de testes a partir do TweetDeck, percebi que os tweetbacks ora aparecem, ora não aparecem no blog. E, sinceramente, estou numa dúvida violenta entre se tratar de um problema no plugin, ou algo que eu esteja fazendo errado com a própria API do migre.me.

A impressão que tenho é que eu quase cheguei lá, mas alguma coisa ainda parece precisar de ajustes. Como entendo um pouquinho de PHP mas no momento estou mais pra weekend programmer do que qualquer outra coisa, enviei o link deste texto para o desenvolvedor do migre.me, na esperança de que ele possa me apontar algum problema — caso aplicável. Também enviei um e-mail ao desenvolvedor do plugin Tweetback, Florian Holzhauer, asking for his advice:

Hi there, Florian!

My name is Daniel Santos, and I’m a Brazilian WordPress user. I came across your e-mail address thanks to your excellent Tweetback plugin for WordPress, which not only I’ve been using in my own blog, but also have been trying to extend.

Let me explain: A lot of Brazilian users have been exchanging abroad URL shorteners like http://tinyurl.com or http://bit.ly for http://migre.me, which is a 100% Brazilian-made URL shortener. Developers from http://migre.me have recently deployed an XML-based API (http://migre.me/blog/api-gerador-de-urls/) that can be used to retrieve shortened URLs to be used as one best fits.

After implementing some code using your PHP plugin file as a reference, I created a variation of it (which I’m sending you, attached to this message). Simple enough, I have added some lines of code to your fh_tweetback_getshorturl function, retrieving a XML file and getting one attibute out of it. Besides, I added http://migre.me to the Admin Panel backend, exactly as I noticed you yourself did with the other services your plugin works with.

Unfortunately, there IS a problem, as shortened URLs created by http://migre.me sometimes appear listed in my post’s comments, sometimes not. Fact is, I don’t know, out of three possible situations, which is actually happening:

(1) my changes to your code were not enough — or are possibly wrong;
(2) the problem might be located in my misuse of http://migre.me API itself.
(3) my PHP skill sucks (LOL)

As #3 is currently impossible to solve and I have contacted http://migre.me developers for help, I’m asking you to please help me figure out if the problem could be with the plugin itself.

Hoping that you will answer me as soon as possible, I would like to thank you in advance, and possibly expect my contribution to your plugin to be useful – as I think several Brazilian tweetbackers will find.

Best regards,

Daniel Santos
http://danielsantos.org/

No entanto, este meu artigo é também um pedido de ajuda pra quem mais quiser se habilitar a fazer a coisa funcionar. Uma vez que a popularidade do migre.me aumenta cada dia mais entre os internautas e blogueiros brazucas, penso que a integração com o plugin para WordPress seja uma ótima pedida.

Ah, é claro: A minha modificação do plugin pode ser visualizada através deste link.

Aderindo aos Tweetbacks

Qualquer um que já tenha escrito pelo menos meia dúzia de artigos em um blog sabe o que é  — ou, pelo menos, já ouviu falar de — um linkback: Também popularmente conhecido como pingback ou trackback, trata-se de um mecanismo que notifica um autor, em seu próprio blog, todas as vezes em que outras pessoas fazem menção a um ou mais artigos seus em outro endereço da Grande Rede de Computadores.

Exemplos de tweetback por aqui

Exemplos de tweetback por aqui

Pois bem: Depois de haver recentemente instalado e saudado com entusiasmo o TweetDeck, me dei conta de alguns links interessantes que mencionavam alguns artigos que eu havia escrito por aqui recentemente. Minha conclusão óbvia é de que, assim como alguns blogueiros têm evoluído para formas aleatórias de microblogging, as pessoas têm usado também seus serviços de microblogging — sobretudo o Twitter como forma de linkback. Esse novo tipo de link, chamado tweetback, foi na verdade introduzido no começo deste ano por Rachel Cunliffe, em seu post  10 Ways Twitter Will Change Blog Design in 2009, publicado no site Mashable:

Bloggers will start to add ââ?¬Å?Tweetbacksââ?¬Â to their blog posts. The simplest version will show the number of people who have tweeted this post (including all reverse engineered tinyurls). Tweetbacks are not yet available.

Options will include:

  • Showing what tweeters are saying about the post
  • Replies to those tweets from others
  • Showing who is tweeting the post
  • Showing the tweeters’ avatars
  • Ordering tweeters by Twitter influence
  • Mixing tweets in with comments, rather than displaying them separately

Imaginei logo que eu deveria aderir a algum tipo de integração dos assim chamados tweetbacks com o meu próprio blog: Minha motivação foi realmente o fato de acreditar que as pessoas efetivamente têm passado menos tempo visitando e comentando posts dos blogs, e que têm dado preferência ao Twitter, para tanto. Depois de procurar um pouco por aí, acabei fazendo algumas experiências e me decidi com relação ao plugin Tweetback, escrito por Florian Holzhauer.

De maneira resumida, ele é capaz de varrer o Twitter em busca de links que apontem para os artigos do blog, mesmo que eles estejam ocultos por serviços de URL shortening — atualmente, aliás, são suportados, além do tinyurlpadrão —,  o is.gd e o bit.ly, sendo que o autor já prometeu suportes adicionais em breve. Uma vez encontrados estes links, eles são transformados em tweetbacks, e publicados no blog acompanhados dos avatares de seus autores, no Twitter.

Opções do plugin

Opções do plugin

Para não dizer que a instalação foi totalmente plug and play, a única coisa que resolvi fazer foi uma edição no arquivo PHP fonte, apenas para aumentar o tamanho do avatar padrão, para que ele coincidisse com o tamanho que venho usando no blog.

Seja como for, o importante é saber que qualquer comentário ou reação aos meus artigos que venha via Twitter agora passará a ser capturados por aqui — figurando na barra lateral, junto aos comentários feitos direto no blog —-, o que me permitirá ter uma idéia melhor das reações com relação ao que eu escrevo. Espero ter boas surpresas… 🙂

Finalmente um TinyMCE ligeiro no meu WordPress 2.7

Desde o começo de dezembro do ano passado eu vinha enfrentando severos problemas ao tentar digitar meus artigos para publicação aqui no blog: Carregar o TinyMCE, editor WYSIWYG padrão que acompanha o WordPress, levava mais de 10 segundos na raposa de fogo, e, em seguida, digitar cada mera letra parecia uma tortura interminável, só perdendo para o tempo gasto ao ter que apagar alguma coisa usando o backspace ou formatando os textos.

Tentei, antes de qualquer coisa, usar uma versão recente do Opera para acessar o painel de edição de artigos, o que funcionou maravilhosamente bem, já que a lentidão desapareceu por completo na digitação. No entanto, não dava pra ficar usando um navegador diferente só pra criar artigos no blog e, assim sendo, cogitei a possibilidade de que pudesse se tratar de um problema qualquer com uma das inúmeras extensões que eu possuo instaladas no Firefox.

Infelizmente, após desabilitar todos os plugins e realizar um fresh setup, o problema não se resolveu: Cada caracter ainda levava uma eternidade para aparecer na tela ao digitá-lo. O próximo suspeito da minha lista foi o próprio WordPress. Pensei se tratar de algum bug da nova versão do WordPress, já que, afobado por testar novas funcionalidades, naquele momento eu vinha usando algumas versões beta.

Quando a versão 2.7 saiu oficialmente e eu reparei que o problema de lentidão ainda não dava o braço a torcer, comecei uma busca um pouco mais dedicada atrás de uma solução. Se na primeira quinzena de 2009 fiquei sem publicar uma palavra que fosse por aqui, foi por conta de estar ocupado atrás de cada pequena referência que pudesse representar uma luz no final do túnel.

No começo dessa semana encontrei essa luz, lendo um artigo do Andrew Ozz, chamado Troubleshooting TinyMCE in WordPress 2.7. Nele, Andrew lista alguns pontos que podem ser tentados por qualquer pessoa se seu editor resolve não aparecer ou funcionar corretamente. Alguns pontos eu já havia tentado, mas foi no sexto que eu parei, pois, recentemente havia encontrado diversos erros provenientes da página em que o TinyMCE é carregado no WordPress, examinando-a pelo console de errors do Firefox:

Delete both wp-admin and wp-includes directories and upload fresh copies from the WordPress installation package.

Precisei esperar até o final da semana para ter tempo de ver se a coisa funcionava, mas valeu cada segundo de espera: Eis que abri meu programa de FTP favorito e mandei bala na orientação. Após alguns minutos de upload, BINGO! O editor estava novamente lépido e veloz.

Ah, é claro, a explicação: Ao renovar sobretudo o conteúdo da pasta wp-includes, pude me certificar de que os diversos arquivos em javascript ali existentes estivessem em sua versão mais recente: Após o procedimento, não houve qualquer problema no console de erros da raposa, o que me fez pensar que alguma falha acidental deve ter ocorrido entre a migração da última versão beta do 2.7 para a oficial. Mea culpa.

Plainscape: Para começar 2009 bem

Precisava — como já precisei em outras vezes — de uma mudança de ares por aqui para dizer que poderia começar bem 2009 (ainda que começando a escrever 16 dias depois da virada do ano). Para isso, depois de muito procurar, acabei encontrando um tema que achei bacana, o Plainscape.

Para meus padrões atuais de gosto, o tema é genial: Totalmente clean, o que o torna sofisticado. Conta com uma barra lateral direita — ao contrário do Apricot, tema que eu vinha usando até então, onde as coisas são agrupadas na esquerda. Além disso, já possui suporte nativo ao novo — e, por mim, mais do que amplamente antecipado — recurso de comentários endentados (ou threaded comments) da versão 2.7 do WordPress.

Espero que o novo tema agrade, e que me inspire a escrever um pouco mais por aqui.

Infinite Scrolling: Adeus, links de navegação!

Uma das principais ferramentas de um site movido a WordPress são seus links de navegação. Afinal de contas, um visitante pode utilizá-los — entre outros mecanismos, é claro — para ter acesso a outros artigos escritos por você, quer ele navegue artigo por artigo, ou página por página.

Mesmo reconhecendo a importância de fornecer ao visitante recursos para que possa navegar tranquilamente pelo conteúdo aqui do blog, reparei, apenas recentemente, que o tema que venho usando atualmente por aqui não possuía essa navegação embutida. Assim que reparei nesse problema, pensei imediatamente não em criá-los no rodapé, mas sim, em fazer uso do excelente plugin WP-PageNavi, que, no caso do modelo de índice do blog, cria um estilo de navegação de páginas similar aos dos resultados de busca do Google, e que eu já adaptei a vários temas que usei por aqui no passado.

Antes de seguir adiante com a implementação, no entanto, considerei as mudanças que apliquei por aqui recentemente, com a finalidade de mesclar blog, microblogs e tumblelog. Mais do que paginar o conteúdo, não me agradou a idéia de, me colocando no lugar de um visitante que desse as caras por aqui, encontrar uma página principal listando os 10 últimos posts e estes posts serem todos referentes, por exemplo, a atualizações de microblogs. Ou seja, nada de artigos do blog, propriamente falando.

Imediatamente eu pensei que uma das maneiras de amenizar esta situação seria garantir que, entre os artigos listados na página principal, estivessem, além das atualizações relacionadas ao meu lifestream, também os últimos 10 artigos do blog. Na prática, seria como imaginar que o número de artigos que um visitante encontraria ao chegar   minha página principal seria não 10, mas sempre pelo menos 10. O problema foi que, ao procurar por meios de implementar mais este comportamento por aqui, dei com os burros n’água.

Com isso, quero dizer que o WordPress não possui uma forma padrão — não, pelo menos, que eu tenha conseguido descobrir após escavações demoradas nos fóruns e sites de suporte — para listar os últimos x artigos do blog, desde se garanta que entre estes artigos estarão, por exemplo, 10 artigos de uma categoria pré-especificada, qualquer que ela seja.

Filosofia do Infinite Scroll

Filosofia do Infinite Scroll

Estava quase desistindo da parada quando, ainda em meio  s minhas buscas, me deparei com o conceito de infinite scrolling. Este conceito, que, pelo que vi também recebe nomes como autopagerize ou unpaginate, na verdade se resume a garantir que o conteúdo da próxima página web — ou, na verdade, de uma ou mais páginas web subseq¼entes —  quela que o usuário está atualmente visitando seja pré-obtido e acrescentado   própria página atual automaticamente, sem que ele sequer se dê conta disso.

Seria como se, na prática, pudéssemos ler todo o conteúdo de um livro como se ele coubesse em uma única página, que seria gigantesca e estaria passando sempre diante dos nossos olhos, como em um rolo de pergaminho que fosse sendo desenrolado   medida em que a leitura progredisse.

No Swurl — mais um dos agregadores de redes sociais que, como o FriendFeed, existem por aí, e onde , aliás, eu também cheguei a criar uma conta —, a filosofia do infinite scrolling está em prática, o que implica no fato de que uma pessoa, por mais que navegue em uma página de usuário do serviço, nunca chegue ao final — ou ao rodapé — da página.

No fundo, aplicar este conceito num blog implica que, por mais que links de navegação sejam legais e importantes, eles se tornam obsoletos, e até mesmo desnecessários, pelo menos no que diz respeito   navegação na página principal do site.

Infinite Scrolling em ação por aqui

Infinite Scrolling em ação por aqui

Pois bem. Eu resolvi dar também este passo por aqui e instalei, a partir da própria página onde li a respeito do conceito de Infinite Scrolling, um plugin para WordPress que eles têm disponível. Neste momento, aliás, este plugin está ativo para qualquer visitante deste humilde blog, e, ao chegar ao rodapé da página principal, deve exibir uma simpática mensagem — um momento, por favor — para alertar o visitante de que mais artigos estão sendo carregados.

Ou seja, o período de testes está aberto. Por favor me dêem feedback caso achem necessário, para que eu possa saber como tudo está indo. E, caso não haja maiores problemas, será sinal de que poderei declarar, realmente, o fim dos links de navegação na página principal do Back-up Brain.

WordPress 2.7: Mal posso esperar por novembro!

Definitivamente deveriam organizar logo um Wordcamp Brazil. Para aqueles que não têm familiaridade com o termo, um Wordcamp é um tipo de evento que discute qualquer coisa relacionada   melhor plataforma para criação e gerenciamento de blogs da paróquia. Nestas ocasiões qualquer blogueiro como você ou eu tem a chance de ouvir blogueiros populares e desenvolvedores, e descobrir a quantas anda o universo WordPress.

Enquanto não organizam algo do gênero por aqui, encontrei em vídeo um dos trechos da palestra de Matt Mullenweg no Wordcamp NYC 2008, em que ele demonstra a novíssima versão 2.7 da ferramenta, que deve sair apenas em 10 de novembro. É desnecessário dizer que eu, um fã mais do que declarado da plataforma, fiquei literalmente de queixo caído com as novas funcionalidades apresentadas.

[viddler]91447bc[/viddler]

A interface para criação de novos artigos ficou muito mais funcional, totalmente operada com AJAX. Na prática qualquer uma das caixas em que estão localizadas as categorias, tags, status dos artigos e qualquer outra coisa pode ser reposicionada na tela. Aliás, há agora uma prática janela de opções que pode ser ativada a qualquer momento, permitindo que o usuário escolha o que deseja ou não que fique visível em sua própria interface.

Esta mesma janela de opções, aliás, está presente no gerenciamento de artigos: Pode-se optar por quais colunas deseja-se visualizar, e também optar por visualizar ou não a introdução de cada um dos textos. A edição rápida — para, por exemplo, corrigir algum erro de última hora — é outro trunfo da ferramenta: A versão 2.7 do WordPress permite que ela seja feita na própria lista de artigos, através de uma janela similar  quela que hoje é apresentada quando inserimos imagens em nossos artigos.

No que diz respeito   comentários, mais uma novidade: Agora será possível respondê-los diretamente a partir da tela de gerenciamento. Antes, para obter este tipo de funcionalidade, era preciso recorrer   plugins. Há ainda uma ponta do que parece ser fruto da recente aquisição do Intense Debate por parte do pessoal da Automatticembora Matt negue isso, por dizer que já estava sendo preparado pelo time de desenvolvedores para ficar no núcleo do WP: Qualquer resposta   um comentário poderá ser configurada para figurar abaixo da resposta original, criando os chamados threaded comments.

Com relação a esta última possibilidade, aliás, trata-se do que mais me deixa ansioso com relação ao novo WordPress: A possibilidade de contar com comentários aninhados nativos   ferramenta sempre povoou os meus sonhos, uma vez que até hoje nunca me satisfiz com qualquer plugin disponível para tanto. Espero que eu não me desaponte com tal ponto, especialmente por estar colocando expectativas demais nele.

WordPress 2.7

WordPress 2.7

No mais, o que mais chama a atenção é a nova interface de instalação de plugins: Eles podemagora ser filtrados na interface do seu site a partir de suas tags associadas, além de poderem ser diretamente baixados do repositório oficial e instalados automaticamente, o que, também, era possível até agora apenas com o auxílio de plugins. Isso, é claro, sem mencionar que a usabilidade do WordPress parece ter ficado ainda melhor.

Isso tudo só pra me deixar com mais água na boca ainda.

Mudando de solução anti-spam

Acima de qualquer coisa, a intenção principal deste artigo é me desculpar publicamente com uma série de leitores fiéis que me acompanham (e eu, a eles) de longa data. Entre essas pessoas estão a Patty Muller, o Thalis, o Rodrigo, a Vivi, o Neto e o Émerson.

O motivo da desculpa está ilustrado acima. Não sou de receber muitos comentários neste humilde blog, mas a falta deles vinha me incomodando nos últimos dias, mesmo sabendo que dei uma ligeira sumida da grande rede, e que não tenho escrito muita coisa nova por mês — poucos textos novos + poucas idéias = poucos comentários, vocês entendem.

Pois bem. Impelido por essa sensação de que havia sido esquecido pelo mundo, fui dar uma olhada na quarentena de spam do Defensio, ferramenta anti-spam que venho usando por aqui há longa data, e que vinha se mostrando muito eficiente até então. Infelizmente, a olhadela na fila me fez descobrir 15 comentários legítimos — realizados nos últimos sei lá quantos dias — que haviam sido considerados spam pela ferramenta.

Fiquei tão chateado — afinal de contas, sempre tentei responder cada comentário recebido nos últimos tempos, prezando pelo bom bate-papo entre mim e meus poucos leitores — que na mesma hora me deu vontade de despachar o Defensio. Sim, lembrem-se: Levam-se anos para conquistar um cliente, e segundos para perdê-lo. E foi nessa minha decisão que encontrei o Mollom.

Nomes esquisitos   parte, o Mollom me chamou a atenção por sua principal proposta: Eliminar o tempo que você precisa gastar para moderar comentários. Em resumo, ele analisa qualquer conteúdo — comentários, mensagens enviadas via formulário de contato, tracks e pingbacks — enviado para o servidor do serviço e retorna três tipos de classificação: spam, ham ou unsure.

 

Na primeira hipótese, a tratativa é óbvia. No segundo caso, o comentário é liberado e aparece instantaneamente no site. E em último caso — quando o Mollom não sabe precisar a resposta — aparece na tela de quem estiver no site uma proposição CAPTCHA. Por menos que eu seja fã desses tipos de teste, neste contexto elas têm sua utilidade.

Digo isso porquê é justamente a classificação unsure o que os desenvolvedores do serviço — Dries Buytaert, o criador, nada mais, nada menos, do Drupal Benjamin Schrauwen, especialista em aprendizado por máquinas — dizem ser o trunfo para acabar com a necessidade de moderação. Afinal de contas, sabemos que apenas seres humanos — ao menos em tese — têm capacidade para resolver um CAPTCHA, que o Mollom exibe em formato texto ou de áudio.

Se esta será a solução definitiva implantada por aqui, eu não sei. O fato é que fiquei animado com as estatísticas do serviço, que demonstram precisão de 99,94%, ou seja, apenas 6 entre cada 10 mil mensagens de spam infiltram-se no sistema, e acabei me inscrevendo no serviço — que tem, a exemplo do próprio Akismet e do Defensio, versões gratuitas e pagas, estas últimas voltadas para empresas —, e instalando o Mollom para WordPress.

Espero que realizando essa mudança, pelo menos, eu tenha chance de ser mais justo com aqueles que têm paciência para ler alguma coisa escrita por mim, respondendo e participando junto com eles de bate-papos bem interessantes. E quem por ventura testar o Mollom, me avise, pra trocarmos impressões sobre ele.

Novo WordPress 2.6: Problemas e soluções

Saiu esta semana e já está disponível para download o novíssimo WordPress 2.6 Tyner — nome emprestado, como de costume, de alguma celebridade do mundo do jazz, desta vez o pianista McCoy Tyner. O que mais me impressionou logo de cara nesta versão foi a rapidez com que ela veio. Os desenvolvedores falam de lançamento um mês antes do previsto, o que demonstra que eles estão produzindo a todo vapor.

Antes que eu diga qualquer outra coisa, devo fazer uma recomendação a respeito do processo de atualização. Minha migração da versão 2.5 para a 2.6 foi toda automática, graças ao excelente plugin Instant Upgrade, que eu venho usando já há algum tempo, e sobre o qual, inclusive, escrevi um artigo dedicado. Este plugin, além de substituir com total maestria o WPAUWordPress Automatic Upgrade, que parece abandonado —, ainda elimina totalmente a necessidade de baixar arquivos e fazer uploads manualmente, via FTP.

A seguir, minha visão, novamente, com relação a novidades e problemas.

Novidades

Controle de Revisões

O controle de revisões, uma das novidades desta versão, pode ser bom ou mau para o seu blog.

Este recurso pode se mostrar útil quando se comete algum erro no texto que se está escrevendo para um artigo ou página, e é necessário voltar atrás. No rodapé na página de edição estarão disponíveis todas as versões salvas do texto sendo escrito — tanto aquelas salvas pelo usuário quanto as que foram salvas pela auto-gravação.

Neste caso, pode-se comparar quaisquer duas versões do mesmo texto, num sistema visual que lembra muito o que já é usado em diversas plataformas de wiki, ou mesmo em softwares especializados na comparação de texto. A qualquer momento o usuário pode selecionar uma versão mais antiga do texto e substituir pela atual.

Para blogs que funcionam com a colaboração de diversos usuários, em que todos normalmente alteram um ou outro detalhe do texto, o controle de revisão chega ao nível de indicar que usuário alterou o quê, e quando isso aconteceu.

Pesando contra o controle de revisões está sua utilização em blogs com um único usuário ativo e editando textos, como é o meu caso. Ocorre que o processo de armazenamento de revisões de artigos funciona acrescentando um novo registro ao banco de dados — mais especificamente   tabela WP_POSTS — todas as vezes que um texto é editado ou salvo automaticamente.

Assim, com o controle de revisões, se o WordPress grava automaticamente o seu texto 10 vezes enquanto ele é editado, você logo terá 10 novos registros em sua tabela WP_POSTS. Significa dizer que rapidamene sua tabela ficará gigantesca.

Felizmente, conforme Lester Chan, existem algumas providências que podem ser tomadas. A primeira delas, alterar o intervalo de gravação automática utilizado pelo WordPress para gerar cópias dos artigos. Para isso, basta acrescentar a seguinte linha ao arquivo wp-config.php, sendo que o número 60 aqui se refere ao intervalo em segundos entre uma gravação e outra, e pode ser alterado a gosto.

define('AUTOSAVE_INTERVAL', 60);

Uma opção mais radical é desabilitar por completo o controle de revisões do novo WordPress 2.6. Para isso, também será necessário acrescentar uma linha ao arquivo wp-config.php:

define('WP_POST_REVISIONS', false);

Mudanças no painel de plugins

O painel de gerenciamento de plugins também tem uma novidade muito bacana: Agora os plugins ativos estão separados dos plugins inativos, sendo que estes últimos podem ser todos apagados ao mesmo tempo, diretamente através do painel, graças a caixas de seleção — checkboxes — posicionadas ao lado de cada item inativo, e de um botão apagar.

Para mim, que sempre adiei a limpeza dos plugins inativos na minha instalação de WordPress, não há mais desculpas para ficar postergando a hora da faxina.

Pré-visualização de temas

Na minha opinião, uma das coisas mais bacanas que surgiu com a nova versão 2.6 do WordPress foi a capacidade de pré-visualizar a aparência de um tema para o blog antes de ativá-lo definitivamente. Antes deste recurso, era necessária a utilização de plugins como o excelente Theme Test Drive para obter o mesmo resultado.

Pré-visualização de um tema para este blog

Pré-visualização de um tema para este blog

A partir de agora, uma vez instalado o tema desejado, basta clicar sobre seu thumbnail no painel de temas para que uma janela pop-up apareça com a pré-visualização já ativa. Os resultados poderão ser percebidos automaticamente, e, caso assim deseje, o usuário poderá confirmar a ativação do tema, usando para isso um link no canto superior direito da janela.

Para maníacos por novos temas como eu, que não consigo me decidir com relação a que tema deixar instalado ou não para meus visitantes, certamente isso será uma verdadeira mão na roda!

Edição de imagens facilitada

Reparei com surpresa em uma das novidades do WordPress 2.6. Ao editar um de meus artigos mais recentes e clicar sobre uma das imagens que o ilustrava, percebi o aparecimento de uma borda ao redor da figura, e de dois botões no canto superior esquerdo da mesma.

Um desses botões permite editar atributos da imagem — inclusive o tamanho, com uma moderna escala em tempo real — e o outro, excluir a imagem do corpo do texto. As tais bordas da imagem também têm uma função importante: Permitem flutuar com a imagem pelo texto, reposicionando-a a critério do usuário.

Gears

Eu não poderia deixar de mencionar a adoção, pelos desenvolvedores do WordPress, do Gears. Desenvolvido pelo Google, trata-se de um plugin que, instalado no seu navegador, é capaz de estender as plataformas de aplicações web, compartilhando recursos localizados localmente em seu computador.

Nos blogs movidos a WordPress a finalidade do uso do plugin é aumentar a velocidade de acesso a alguns arquivos da área de administração do blog, sobretudo imagens e folhas de estilo CSS, para evitar tráfego web desnecessário.

De qualquer forma, para comprovar por conta própria o quanto o Gears pode de fato influenciar na sua própria experiência com o WordPress, você deverá habilitá-lo. Para isso, deve ser utilizado o link Turbo, que agora se encontra no painel de administração do blog, no canto superior direito. Clicando sobre ele, uma janela aparecerá, solicitando que o plugin seja instalado.


Uma vez prosseguindo-se com a instalação do Gears, o navegador deverá ser reinicializado para que as alterações tenham efeito. Em termos de WordPress, uma vez concluído este processo, será necessário clicar novamente sobre o link Turbo do painel de administração do blog. Uma janela popup do próprio Gears aparecerá, perguntando se o usuário deseja habilitar o plugin para o site — no caso, o próprio blog.

Em seguida, será feito o download de aproximadamente 200 arquivos para o computador do usuário. Neste ponto, é importante lembrar que somente será interessante usar o Gears se isso for feito a partir do seu próprio computador — ou seja, não é legal baixar arquivos do seu site para máquinas públicas.

São estes arquivos, armazenados no seu computador em diferentes locais dependendo do sistema e do navegador internet utilizados, que farão a diferença de velocidade. Em alguns casos, segundo a equipe responsável pelo WordPress, após a ativação da ferramenta, as janelas e páginas chegam a aparecer instantaneamente na tela.

Particularmente, não notei grandes diferenças de desempenho com o uso do Gears. Pode ser que eu ainda não tenha reparado em tudo, mas por enquanto me parece que a diferença virá apenas no caso de conexões com a internet extremamente lentas.

Problemas

Felizmente, ao contrário do que aconteceu na minha migração para a versão 2.5 do WordPress, com a nova versão Tyner eu não me deparei com grandes problemas. Na verdade, tive apenas dois deles — até o momento —, sendo um devido   incompatibilidade de plugins, e o outro, com o envio de imagens para o meu servidor. Vou descrever as soluções encontradas a seguir.

Simple Tags

O plugin Simple Tags, que eu uso por aqui para me ajudar no gerenciamento das tags dos meus posts, parou de funcionar tão logo a migração para a versão 2.6 foi concluída. No entanto, a primeira providência que pensei tomar resolveu a questão: Através do próprio painel de gerenciamento de plugins, fiz a atualização de versão e instalei o Simple Tags 1.5.7, eliminando o problema.

Envio de imagens: Sem miniaturas, ou thumbnails

Com relação ao envio de imagens para o blog, uma coisa mais estranha aconteceu.

Ao atualizar um dos meus artigos recentes e tentar complementá-lo com uma imagem extra, percebi que a miniatura que normalmente é gerada após o upload não estava sendo gerada. Tentei configurar diversas opções do novo WordPress, inclusive alternando entre o uploader baseado em flash e o tradicional, mas nada disso adiantou. A miniatura de qualquer imagem não aparecia de jeito nenhum.

Felizmente, procurando pela internet afora, descobri no próprio fórum de suporte do WordPress, que havia uma solução para o problema. Ocorre que, para usuários que, como eu, têm configurado um diretório para upload de imagens diferente do padrão do WordPress (wp-content/uploads), agora é necessário preencher um campo adicional em Configurações » Diversos, especificando a URL completa para este diretório, conforme ilustro acima.

Por último, quero lembrar que, a exemplo do que já havia sido feito no lançamento da versão anterior, um screencast está disponível em inglês, contendo cerca de 3 minutos de informações sobre o WordPress 2.6. Acredito ser uma boa parada, caso você ainda não o tenha assistido.

[ratings]