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%!

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…

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).

Post rápido, apenas para explicar a recente instabilidade no site: ao instalar o WordPress 2.6 (codinome Tyner), fiz algumas modificações no .htaccess que resultaram em repetidas páginas em branco.

Espero que agora tudo esteja de volta ao normal.

Post rapidinho só para comunicar que passei a usar um novo conjunto de emoticons: como são brancos, combinam mais com o tema do meu site.

Obrigado a Leo Bolin pelo ótimo trabalho e a Taha Paksu por me informar o site do autor!

Ah! Taha Paksu desenvolveu o pngfix, um plugin para corrigir o problema do internet Explorer 6 com transparência em figuras PNG usando CSS.

1. instalei o WordPress 2.5 e não tive muitos problemas com plugins: apenas o TinyMCEComments e o ImageManager apresentaram alguma incompatibilidade e ambos já estão com novas versões prometidas…
2. por outro lado, tive problemas com meus feeds no FeedBurner. Precisei recriá-los e perdi a relação de inscritos…
3. revisei o formulário de comentários, facilitando o uso de smilies e melhorando sua aparência;
4. o formulário de contato também passou por uma reforma: não ganhou atalhos para os smilies, mas permite a inclusão de campos diversos para identificar os remetentes.

Assim, no formulário de contato, peço que informem se são:

• meus alunos (Aluno);
• professores (Professor); ou
• alunos de outras instituições (Estudante).

Ao escrever sobre assuntos polêmicos como pirataria, drogas ou discriminação, torna-se necessário indicar sites sobre o assunto, mas não é desejável a associação a eles. É aí que entra a tag rel="nofollow": ela instrui os mecanismos de busca (como o Google e o Yahoo!) a não indexarem a página apontada por um determinado link.

Em teoria, é um grande recurso. Entretanto, a fim de se proteger de comentários de terceiros, o WordPress a adota em todos os links existentes nos comentários. E isso prejudica o intercâmbio entre os diversos blogs.

Há alguns meses, venho tentando encontrar uma solução para esse dilema: remover a tag dos comentários sem me expor a links desfavoráveis. Em fevereiro, alterei o código do plugin encontrado no Simple Thoughts, em minha solução para o nofollow. Depois de encontrar um erro no meu código, fiz as devidas correções e publiquei o código-fonte.

Há poucos dias, descobri o plugin NoFollow Free, de Michele Marcucci. Esse plugin:

• remove a tag do link autor do comentário;
• remove a tag do texto dos comentários de autores registrados;
• remove a tag do texto de autores com uma quantidade mínima de comentários autorizados;
• recoloca a tag se palavras de uma “lista-negra” forem encontradas; e
• exibe uma faixa no topo da página para divulgar a campanha.

Como o código que eu usava era menos capaz, eu o aposentei e passei a usar o NoFollow Free.

Recomendo!