Foram mudanças suficientes no site para atualizar sua versão de 3.1 para 3.9! A versão 4.0 virá quando eu limpar o código e fizer as alterações necessárias (para ver as versões anteriores, conheça um pouco mais sobre este site).

Agora, vou fazer uma nova parada para descanso e deixarei o site no “piloto automático”. Portanto, a aprovação dos novos comentários dependerá da facilidade com que eu terei acesso a um computador.

Antes, porém, proponho uma reflexão sobre o texto de Jair Cunha, no meu último post: Arde porque limpa!.

Agora, de volta à programação normal

Não é impressão sua a sensação de que a maior parte dos e-mails é lixo. Segundo o último relatório da Symantec, 91,89% de todos os e-mails no mundo são spam.

Não, você não leu errado! Quase todos os e-mails que circulam na internet são spam (pelo menos por enquanto)! E, segundo as estatísticas, o Brasil é um dos campeões na área.

O relatório não explica porque, mas creio que uma das razões seja a falta de cuidado dos brasileiros. No Brasil, abundam apresentações em powerpoint, na maioria das vezes, mensagens de auto-ajuda ou boatos infundados, invariavelmente terminadas com um apelo para encaminhar a todos os contatos da lista.

Ao receber uma dessas mensagens, o spammer passa a contar com uma lista novinha de vítimas porque a maioria dos internautas brasileiros não costuma zelar pela privacidade do próximo:

• usando o campo de cópia oculta; e
• removendo os endereços de destinatários anteriores do corpo da mensagem ao enviá-la.

Duas das principais medidas preventivas são:

• não divulgar seus e-mails a qualquer um ou a qualquer site; e
• evitar o formato comumente utilizado (fulano@dominio.com.br), ao escrever o endereço de e-mail em páginas pessoais ou no corpo de comentários.

Mesmo assim, aqui no jlcarneiro.com, em diversas ocasiões, precisei editar comentários para proteger comentaristas incautos que informaram seus e-mails para receber ajuda. Protegi a privacidade deles mas, infelizmente, posso ter atrapalhado seus apelos…

Para evitar isso, acabo de instalar uma rotina em javascript que transforma endereços de e-mail no formato textual (fulano arroba dominio ponto com ponto br) no formato tradicional (fulano@dominio.com.br). Caso os navegadores estejam com o javascript desabilitado, o e-mail ainda será exibido no formato textual, permitindo sua exibição mas sem facilitar a vida dos spammers.

A rotina baseia-se em um post do HTML-Advisor e, para aqueles interessados em implementá-la em seus sites, segue o código comentado:

// expressoes regulares para busca por TODAS as ocorrencias de 'arroba' e 'ponto'
var at = / arroba /g;
var dot = / ponto /g;
// percorre todas as tags SPAN
var spans = document.getElementsByTagName("span");
var hm = spans.length;
for (c = 0; c < hm; c++) {
	// altera apenas aquelas da classe 'email'
	if (spans[c].className == 'email') {
		newcnt = spans[c].innerHTML.replace(at, '@');
		newcnt = newcnt.replace(dot, '.');
		spans[c].innerHTML = '<a href="mailto:' + newcnt + '">' + newcnt + '</a>';
	}
}

Assim como o post anterior, este também foi um pouco mais técnico. Entretanto, penso que as reflexões sobre spam e divulgação de endereços de e-email são interessantes para todos.

Outro dia, um amigo meu perguntou por que alguns posts tinham um caráter tão técnico. Peço desculpas, é porque um dos objetivos iniciais deste site é armazenar macetes e dicas para mim mesmo:

• distribuir material de apoio para meus alunos;
• ajudar aqueles que não têm muita prática com informática com dicas;
• manter, num local de fácil acesso, pequenos macetes, dicas e endereços;
• guardar textos, mensagens, reportagens e notícias interessantes; e
• expressar minha opinião sobre algum assunto interessante.

Portanto, aviso que este post interessa mais àqueles que gostam de programação. Aqueles que o lerem e não compreenderem, não se preocupem: é apenas um registro pessoal para futuras consultas e não contém nenhuma informação de uso geral.

Em 2008, escrevi um script que atualiza o campo de data dos links, para contornar o já conhecido problema com a exibição do blogroll por ordem de atualização no WordPress.

Recentemente, verifiquei que os script havia parado de funcionar. Como parece que as versões recentes do WordPress não têm mais a variável use_linksupdate, aproveitei para adaptar o código às diferentes versões e formatos de feed, que armazenam a data em campos distintos:

global $wpdb;
require_once(ABSPATH.'wp-config.php');
include_once(ABSPATH.'wp-includes/class-snoopy.php');
include_once(ABSPATH.'wp-includes/rss.php');
$link_rsses = $wpdb->get_col("SELECT link_rss FROM $wpdb->links WHERE link_rss <> ''");
if ($link_rsses) {
	foreach ($link_rsses as $rssurl) {
		$feed = fetch_rss($rssurl);
		if ($feed) {
			$pubdate = $feed->channel['pubdate']; // Netscape RSS 0.91
			$lastbuilddate = $feed->channel['lastbuilddate']; // Netscape RSS 0.91
			$updated = $feed->channel['updated']; // Atom 1.0
			$items = array_slice($feed->items, 0, 1);
			foreach ($items as $item) {
				$item_pubdate = $item['pubdate']; // RSS 2.0
				$item_dcdate = $item['dc']['date']; // RSS 2.0 Dublin Core
				$item_updated = $item['updated']; // Atom 1.0
			}
			$last_update = max(strtotime($pubdate), strtotime($lastbuilddate), strtotime($updated), strtotime($item_pubdate), strtotime($item_dcdate), strtotime($item_updated));
			$wpdb->query("UPDATE $wpdb->links SET link_updated = FROM_UNIXTIME($last_update) WHERE link_rss = '$rssurl'");
		}
	}
}

Pronto! Agora que a Copa do Mundo 2010 acabou (pelo menos para a Seleção Brasileira), voltemos à programação normal…

No último dia 17, foi lançado o WordPress 3.0 (Thelonious Monk), com várias novidades. Foi muito festejada a possibilidade de manter vários blogs em uma única instalação WordPress, e é realmente um grande avanço. Mas, como já tenho pouco tempo para manter este site, interessei-me mais pelas outras mudanças.

A maior delas, é o novo sistema de taxonomia, que permite múltiplos critérios de classificação de posts. É uma mudança profunda, implicando não apenas adaptações no código, mas na organização dos posts.

Encontrei um ótimo tutorial (em inglês) sobre o assunto no Nettuts+. Para ter uma idéia da tentadora flexibilidade, vamos imaginar um blog com análises de notebooks:

• até o WordPress 2.2, uma análise teria que ser classificada simultaneamente em várias categorias: uma para o sistema operacional, outra para a capacidade de memória, outra para o processador, e assim por diante;
• no WordPress 2.3, surgiram os marcadores, permitindo um menor número de categorias amplas, como “Netbooks” e “Notebooks”, com uma classificação mais específica por meio de palavras-chave, como “webcam”, “jogos”, “3G” ou “teclado ABNT2″; já
• a nova taxonomia, introduzida no WordPress 2.8, e agora consolidada no WordPress 3.0, permite eliminar o conceito de categorias, adotando um esquema de critérios simultâneos, muito comum nos sites de comércio eletrônico. Nesse sistema, um equipamento poderia, do ponto de vista da memória, ter “Mais de 4GiB”, considerando o disco rígido, ter “Entre 160GiB e 250GiB” e usar o sistema operacional “Ubuntu Linux”. Isso tudo sem esquecer os marcadores específicos como “webcam”, “jogos”, “3G” e “teclado ABNT2″, já citados.

Associando à nova taxonomia os também novos tipos personalizados de posts que, no exemplo acima, incluiriam, por exemplo, “Análises”, “Comparativos” e “Lançamentos”, o WordPress transforma-se em um Sistema de Gerenciamento de Conteúdo (Content Management System – CMS) quase completo.

Minha costumeira falta de tempo me impede de implantar isso no jlcarneiro.com (pelo menos por enquanto). Mas, para não ficar para trás, implantei algumas novas funcionalidades (listadas com os links para referências futuras):

1. barra de navegação sensível ao contexto (variando de acordo com o conteúdo exibido no momento);
2. uso de anexos nas mensagens enviadas meio do Formulário de Contato;
3. associação da URL do blog ao sistema OpenID (segui o tutorial do Dipping into the Blogpond);
4. tradução (via Google Translate™) na barra de navegação, à esquerda;
5. integrei a busca do Google ao site (na barra de navegação, ou diretamente no navegador, graças a uma dica de DeWitt Clinton);
6. alguns ajustes na indexação do site e na colocação de anúncios (para voltar a ter o PageRank 3);
7. por meio de um tutorial do Million Clues, menus de navegação em dois níveis e alteração da imagem de cabeçalho e da decoração de fundo (cores ou imagens), usando apenas o mouse; e
8. um pequeno aumento na velocidade de carregamento das páginas (ver meu comentário, abaixo).

Algumas mudanças (como o menu em dois níveis e a busca direto do navegador) estão disponíveis apenas nos navegadores mais modernos. Inclusive, usuários do Internet Explorer 6 há algum tempo vêm sendo aconselhados a atualizar o seu navegador.

A iniciativa parece estar surtindo efeito: hoje, o IE6 é usado por apenas 17% dos meus leitores/visitantes. Antes, era usado por 97%!

O que isto significa?

Com relação ao conteúdo, nenhuma mudança. Apenas a aprovação dos novos comentários dependerá da facilidade com que eu terei acesso a um computador (o que significa que terei uma pilha de mensagens e comentários para responder quando voltar)…

Sistema em manutenção preventiva
Agora, de volta à programação normal

Encontrei dois textos interessantes sobre marcadores de blogs (no Blog for Profit e no Jasor Better). Segundo eles, os marcadores funcionam como palavras-chave, ligando até mesmo posts de diferentes categorias de forma intuitiva.

Por outro lado, em excesso, os marcadores podem confundir o leitor, tornando-se prejudiciais. Sendo assim, decidi verificar quantos marcadores meus posts têm.

Pesquisei na internet, mas não encontrei nenhuma solução para esse problema. Então, usando a documentação do WordPress e contando com a ajuda de uma colega de trabalho (obrigado, Luciana!), cheguei ao comando abaixo:

SELECT post_title, COUNT(db_term_relationships.object_id) AS num_tags FROM db_term_relationships
LEFT JOIN db_posts ON id = object_id
LEFT JOIN db_term_taxonomy ON db_term_relationships.term_taxonomy_id = db_term_taxonomy.term_taxonomy_id
LEFT JOIN db_terms ON db_terms.term_id = db_term_taxonomy.term_id
WHERE db_term_taxonomy.taxonomy = "post_tag"
GROUP BY db_term_relationships.object_id
ORDER BY num_tags DESC

Por outro lado, se o interesse for apenas uma lista com os marcadores mais usados, pode-se usar o comando abaixo:

SELECT db_terms.name, COUNT(db_term_relationships.object_id) AS qtd FROM db_term_relationships
LEFT JOIN db_term_taxonomy ON db_term_relationships.term_taxonomy_id = db_term_taxonomy.term_taxonomy_id
LEFT JOIN db_terms ON db_terms.term_id = db_term_taxonomy.term_id
WHERE db_term_taxonomy.taxonomy = "post_tag"
GROUP BY db_terms.term_id
ORDER BY qtd ASC

Fica como lembrete para mim e sugestão para outros que tenham a mesma dúvida…

Atualização: Acrescentado o comando SQL para exibir a lista dos marcadores mais usados.

Gostei muito das últimas atualizações do WordPress porque adicionaram funcionalidades que eu obtinha apenas por meio de plugins. O gerenciamento de imagens, por exemplo, faço agora pela Biblioteca de Mídia. O sistema oferece ferramentas básicas de edição de figuras, galerias automáticas e a geração automática de miniaturas de figuras com grandes dimensões.

As miniaturas são sinalizadas por meio de sufixos acrescentados aos seus nomes. Contudo, os sufixos são criados a partir das dimensões (largura x altura) das miniaturas, dificultando uma identificação rápida e eventuais alterações futuras.

As miniaturas deveriam ser nomeadas, de acordo com seu tamanho, com sufixos padronizados como “large”, “medium” e “thumbnail”. Ou, idealmente, com sufixos definidos pelo usuário. Infelizmente, devido à forma como essa rotina foi implementada, até o momento não há plugins para este fim.

Encontrei uma gambiarra um paliativo, proposto por Jstn Ryan, que estou usando no momento:

1. procurar, no arquivo /wp-includes/media.php, pela definição da variável $suffix:

   if ( !$suffix )
   	$suffix = "{$dst_w}x{$dst_h}";

2. substituí-la pelo código abaixo:

   if ( !$suffix )
   {
   	switch ($max_w) {
   		case (intval(get_option('large_size_w'))):
   			$suffix = 'large';
   			break;
   		case (intval(get_option('medium_size_w'))):
   			$suffix = 'medium';
   			break;
   		case (intval(get_option('thumbnail_size_w'))):
   			$suffix = 'thumbnail';
   			break;
   		default:
   			$suffix = 'other';
   	}
   }

Está funcionando muito bem. Mas como envolve a edição de um arquivo do WordPress, precisa ser refeito a cada atualização de versão. Nem tudo é perfeito…

Fiz algumas mudanças para testar, mas não consegui decidir qual tendência seguiria. Resolvi perguntar, aos leitores, qual o melhor local para a barra lateral. A enquete durou 30 dias, de 24 de julho a 24 de agosto, oferecendo duas respostas:

• Lado esquerdo; e
• Lado direito.

Das 33 respostas recebidas, 19 (57,58%) apontavam o lado esquerdo como o mais indicado.

Sendo assim, a barra lateral fica à esquerda. Se quiser ter uma idéia da aparência e das vantagens de cada opção, veja o post da enquete.

Uma curiosidade: o gráfico acima é resultado de meus primeiros testes com a API do Google Chart. Ela é poderosa, versátil, não ocupa espaço de armazenamento e é atualizada automaticamente, tornando-se a escolha ideal para gerar os gráficos das estatísticas do site. Assim que eu tiver algum tempo, faço isso.

Há mais de dois anos atrás, encontrei um texto sobre como, na web, as pessoas tendem a ler em formato de “F”. Fiz alguns testes e terminei mudando a barra lateral para a esquerda. Confesso que gostei do resultado, acho mais lógica a navegação pela direita, mas algo me aconselhava a por o conteúdo no local de destaque.

Recentemente, encontrei dois textos questionando a localização da barra lateral no Pro Blog Design e no Webmaster-Source. Apesar de um pouco datados, esses texto aconselham que barras voltadas para navegação fiquem localizadas à esquerda.

Por outro lado, o Webpoint, traz um texto sobre a navegação em um site. Há inclusive os resultados de testes de usabilidade realizados no site da Audi, segundo os quais, não há grande diferença em usar um lado ou outro.

E agora?

Ainda não sei se farei essa alteração, mas seguem fotos representando cada uma das situações e uma enquete para colher algumas opiniões. Quem quiser explicar sua opção, fique à vontade para postar um comentário.

Alguns argumentos para cada lado:

Esquerda	Direita
Tradicional como menu de navegação	Maior enfoque no conteúdo
Menos comum em blogs, “diferenciado”	Mais comum em blogs
—	Maior proximidade da barra de rolagem

Fiz algumas mudanças no site nos últimos dias. Como tenho andado muito atarefado, infelizmente elas foram levadas no meu tempo vago (que tem se tornado cada vez mais raro): começaram há alguns dias e acabaram (espero!) hoje à tarde. Não sem antes me deixarem com mais alguns cabelos brancos: quem acessou o site entre as 15 e as 18 horas encontrou-o sem nenhum post, fruto de problemas para importar a cópia de segurança dos registros.

Há quase um ano, desabilitei duas funcionalidades do WordPress 2.6: o controle de revisões e o auto-salvamento de posts. Apesar de serem ótimas idéias, resultam num aumento desnecessário do banco de dados, tornando-o lento. Essa semana descobri que essas funcionalidades foram reativadas (na instalação da versão 2.7 ou 2.8, não sei ao certo) e fui corrigir o problema.

Depois de instalar um plugin que desativa essas funções de maneira mais rápida do que a edição direta de arquivos, excluí as entradas indevidas. Só depois dei-me conta que o comando que usei (DELETE FROM wp_posts WHERE post_type = "revision") apagava apenas as entradas na tabela de posts e páginas, mas não as referências a elas (marcadores, categorias e séries, por exemplo). O correto seria usar um comando mais complexo, mas que fizesse o trabalho simultaneamente em todas as tabelas:

DELETE a,b,c
FROM wp_posts a
LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id)
LEFT JOIN wp_postmeta c ON (a.ID = c.post_id)
WHERE a.post_type = 'revision'

Ao restaurar a cópia de segurança de ontem, recebi mensagens de erro por quase duas horas enquanto via meu trabalho dos últimos anos desaparecer. Acreditem, não é uma sensação agradável…

Resolvido problema (e anotado o comando correto, para não esquecê-lo mais), aproveito para comunicar que integrei a busca do Google ao meu tema, como sugerido no pBlog. Perdi alguns relatórios, inclusive um com as buscas mal-sucedidas para apontar os desejos dos leitores, mas o banco de dados diminuiu consideravelmente e o site ficou mais rápido.

Aumentei também a largura dos posts: antes dispunha de cerca de 550 pixels, atrapalhando a exibição de charges, por exemplo. Reduzi também o número de imagens na barra lateral e fiz algumas alterações nos gráficos das estatísticas.

Ainda tenho alguns comentários para responder, algumas alterações para fazer na seção de Perguntas e Respostas e reorganizar a seção de Sites recomendados. Fora uma revisão nos códigos do site para torná-lo mais leve.

Há cerca de uma semana, sugeri um script que atualizava o campo de data dos links do WordPress, tornando possível a exibição do blogroll por ordem de atualização.

Porém, o Planeta Ubuntu Brasil ficava sempre em último lugar na lista, apesar de ser atualizado frequentemente. Observei então, que o feed traz as datas em português, impedindo na conversão por meio da função strtotime() (que espera datas em inglês).

Assim, alterei o script que sugeri aqui há uma semana: ele agora tenta identificar datas válidas no cabeçalho do feed e no primeiro item exibido. E, para atender casos como o do Planeta Ubuntu Brasil, procura datas tanto no formato RSS 2.0 quanto no formato RSS 1.0.

Atualização: Veja o código atualizado em Blogroll por ordem de atualização (3).

Para tornar o script mais independente, decidi colar o código diretamente no WP-Crontrol, ao invés de incluí-lo como uma função no arquivo functions.php do meu tema.

Atualizei o WordPress para a versão 2.7 (codinome Coltrane), que trouxe várias vantagens, como a possibilidade de reduzir o número de plugins ativos, já que comentários aninhados, personalização do painel administrativo e atualização de plugins (e do próprio WordPress) agora são nativos. Recomendo!

A implementação de comentários aninhados exigiu alterações na aparência do site. Então, aproveitei para fazer algumas pequenas mudanças:

1. implementei o envio de anexos no formulário de contatos (ainda em testes);
2. o campo atual nos formulários agora recebe cores diferentes para maior destaque (exceto no internet Explorer…); e
3. a pedidos, alterei a seção Sites recomendados (blogroll), classificando os sites por ordem decrescente de atualização.

A exibição de sites recomendados por ordem de atualização, usando o parâmetro orderby=updated, é um problema antigo no WordPress.

As atualizações deveriam ser controladas pelo Ping-O-Matic, dos desenvolvedores do WordPress, entretanto isso não ocorre.

Pesquisando sobre o assunto, encontrei um tutorial ensinando como basear controlar as atualizações pelos feeds RSS. Fiz algumas alterações pequenas no código fonte e, usando o plugin WP-Crontrol, configurei execuções periódicas.

É possível colar este código diretamente no WP-Control ou incluí-lo como uma função no arquivo themes.php functions.php, associando-a a um evento (hook) do WordPress.

Atualização: Veja o código atualizado em Blogroll por ordem de atualização (3).