Atualizações:

• O pessoal do feed vai ter que acessar o site para ler o post inteiro. Por algum motivo que ainda me foge à compreensão posts paginados não vão completos para o feed. Pensarei num jeito de corrigir isso.
• Como o artigo ficou extenso demais, tive de dividi-lo em páginas. No final de cada página tem uns linkzinhos numéricos (de 1 a 5); são os links para as diversas páginas do post.

Antes de mais nada, para aqueles que não entendem ironias explico que o título (“guia definitivo”) não passa de uma piada, pois jamais alguém poderá escrever um guia definitivo sobre aceleração do WordPress. O sistema é muito flexível, muito dinâmico, e a cada dia surgem novidades que tornam os guias anteriores obsoletos. Mas, acima de tudo, existe o fato de que cada caso é um caso, cada blog tem suas particularidades e o que é justo e perfeito para um pode não ser sequer útil para outro.

Na verdade, o presente artigo é uma resposta a dois outros artigos: Acelere o WordPress com o Plugin WP Super Cache, do Celso Lemes, e Como Acelerar ao Máximo Seu Site em WordPress: O Guia Definitivo, do J. Noronha.

Ambos os artigos tratam da utilização de um plugin de cache (ou cachê, como diz o Noronha) a fim de aliviar a carga de processamento do blog e acelerar a entrega do conteúdo para o visitante. O Noronha vai além, ensinando a configurar o W3 Total Cache para operar com CDN (rede de distribuição de conteúdo), o que na prática me parece uma medida ineficiente, a menos que seu site faça uso intensivo de imagens; para sites baseados em texto é desnecessário sequer pensar em CDN, assim como domínios “cookieless” (sem cookies) não são o que faz diferença na aceleração do WordPress.

Das muitas opções de cache existentes, o meu favorito continua sendo o WP-Super-Cache, que também foi o escolhido pelo Celso Lemes. Ele é melhor que o W3 Total Cache por um simples motivo, além de todos os outros: ele permite que as páginas constantes em cache sejam servidas mesmo que o interpretador de PHP morra, pois as regras de “rewrite” que ele insere no .htaccess (no caso de servidores Apache) fazem com que o webserver primeiro verifique se a página a ser servida existe fisicamente no cache, e somente se ela não existir o WordPress será instanciado.

Além do mais, o W3 Total Cache vai falhar miseravelmente no caso de um servidor modesto em recursos mas com muitas visitas, principalmente se forem utilizados os aceleradores mais radicais (APC e MemCache), que consomem RAM mais vorazmente do que o Maradona consegue aspirar o pó da mobília dele. A única grande vantagem que eu vejo no W3 Total Cache é o cache de banco de dados, mas isso pode ser facilmente obtido com a utilização de um outro plugin, o DB Cache Reloaded.

Mas instalar plugins de cache achando que são panaceia não vai resolver nenhum problema de performance de WordPress. É necessário prestar especial atenção também nos demais plugins instalados, bem como no tema do blog e nas chamadas externas que ele venha a fazer (como webservers de terceiros e contadores de visitas, por exemplo).

Assim, podemos fazer um roteiro simples de otimização do WordPress em apenas quatro passos.

Este post foi publicado no blog Viamão Lotado. Se você está lendo a partir de outro local, é bem provável que ele tenha sido plagiado. Por gentileza, nos avise.

WordPress de alta performance: o guia definitivo

Parece o caos, mas com um pouco de boa vontade é possível resolver este problema, sem nem precisar recorrer a plugins complicados: basta inserir um pequeno código no functions.php do seu tema em uso, e passar a utilizar os campos personalizados (custom fields) para inserir o que quiser em qualquer post.

A técnica usada para resolver este problema já foi explicada anteriormente aqui. Vamos criar um shortcode chamado [ field ] (os espaços entre os colchetes e a palavra field são para evitar que o meu shortcode field seja interpretado aqui) que fará simplesmente pegar o conteúdo de um campo personalizado qualquer e inseri-lo sem qualquer modificação no ponto exato do post.

Primeiro, o código abaixo deverá ser inserido em algum lugar do functions.php do tema em uso.

function field_func($atts) {
   global $post;
   $name = $atts['name'];
   if (empty($name)) return;
 
   return get_post_meta($post->ID, $name, true);
}
 
add_shortcode('field', 'field_func');

Feito isso, e estando o functions.php devidamente salvo, vamos criar um campo personalizado, com um nome qualquer, que vai receber o conteúdo que vamos inserir em algum lugar no post.

Clique para ampliar

Na imagem acima, apenas mostramos que criamos um campo chamado flash, preenchido com o HTML fornecido pelo “embed code” de um vídeo qualquer do YouTube.

Agora, caso eu quisesse inserir o vídeo exatamente no próximo parágrafo bastaria eu escrever:

[field name="flash" /]

Isso mesmo: o shortcode chamado field recebe um parâmetro chamado name, que contém o nome do campo personalizado que vai ser inserido naquele ponto exato do post.

Com isso, você pode ficar sossegado, pois no modo HTML ou no modo visual seu conteúdo HTML ou de script nunca mais se perderá, embora seja à custa de perder um pouquinho do apelo e da facilidade do editor visual.

Este post foi publicado no blog Viamão Lotado. Se você está lendo a partir de outro local, é bem provável que ele tenha sido plagiado. Por gentileza, nos avise.

Insira qualquer conteúdo num post do WordPress

Deixar comentários com esse tipo de texto em um blog bem escrito é, acima de tudo, uma puta falta de sacanagem com quem se esforça para escrever direito, e me dá muita vontade de xingar muito no Twitter.

Para amenizar a raiva que passo diariamente moderando comentários de amebas antropomórficas que não respeitam as caixas de comentários alheias resolvi aplicar um “hack” bastante simples no WordPress, para evitar que este tipo de comentário seja enviado.

A ideia é simples: um script contém uma lista de palavras proibidas, e captura a submissão do formulário de comentários para verificar se alguma das palavras proibidas está contida no texto; em caso positivo o script emite um aviso ao comentador, e cancela a submissão dos dados para o servidor.

Para aplicar o “hack” é necessário editar o arquivo comments.php do tema em uso no WordPress, acrescentar umas poucas linhas de código e modificar uma outra. Vejamos.

Encontre no comments.php uma linha contendo o seguinte (dependendo do seu tema pode haver variações, por favor raciocine).

<form action="<?php echo get_option('siteurl'); ?>/wp-comments-post.php"
method="post" id="commentform">

Substitua pelo que segue.

<script>
	function ValidaComentarios(F){
		var Retorno = true;
		Comentario = F.comment.value.toLowerCase();
		BadWords = ["achu", "axu", "com tigo", "dificel", "eh", "dis",
		"k", "q", "tipow", "kkk", "bj", "bjs", "aki", "naum", "nao",
		"tb", "td", "qd", "qr", "qt", "pq", "add", "pow", "kra", "fik",
		"dae", "dik", "vc", "eh", "saum", "taum", "voce", "ki", "nunk",
		"nunka"];
 
		pt = '[^a-zA-ZÁ-öù-ÿ0-9]';
 
		for (PalavraProibida in BadWords){
			re = RegExp('(^|'+pt+')((' + BadWords[PalavraProibida] + ')s?)('+pt+'|$)', 'gi')
			if (re.test(Comentario)) {
				Retorno = false;
				alert("Seu comentário não foi aceito porque contém a palavra \"" + BadWords[PalavraProibida].toUpperCase() + "\". Corrija, por favor.");
				F.comment.focus();
				break;
			}
		}
		return Retorno;
	}
</script>
<form action="<?php echo get_option('siteurl'); ?>/wp-comments-post.php" 
method="post" id="commentform" onsubmit="return ValidaComentarios(this);">

O script é autoexplicativo, creio eu, podendo ser entendido até mesmo por quem não é programador.

Claro que se o miguxo além de retardado for mau caráter ele pode desabilitar o JavaScript no navegador para poder “trollar” o blog da gente. Nesse caso, recomendo que a mesma lista de palavras proibidas usada nesse script seja nformada na configuração do plugin NoSpamNX, sobre o qual já escrevi em WP: Acabe com os spams de comentários com o NoSpamNX.

Por fim, programadores mais experimentados ou dedicados podem conseguir em muito menos linhas de código fazer o que meu script faz, inclusive com mais eficiência (pois ele apenas testa substrings, e não palavras dentro do texto, por exemplo), ou mesmo transformá-lo num plugin ou script para uso geral, evitando que se tenha de “hackear” manualmente um arquivo do tema em ouso, ou permitindo que usuários de outras plataformas se beneficiem dele. A minha parte, contudo, já está feita.

Atualização: o script foi melhorado e agora usa uma Expressão Regular para identificar palavras em vez de meras “substrings”. Ou seja, se alguém quiser falar num comentário que comeu temaki não será mais barrado pela presença da partícula “aki” (aqui, em miguxês).

A nova versão do script pode ser encontrada (e testada) aqui: Abaixo o Miguxismo nos blogs!

Este post foi publicado no blog Viamão Lotado. Se você está lendo a partir de outro local, é bem provável que ele tenha sido plagiado. Por gentileza, nos avise.

Combata o miguxismo no seu blog com JavaScript

Entretanto, existem muitas tentativas, desde o famoso e indispensável Akismet até plugins de “captcha” (aquelas “letrinhas” que devem ser digitadas a cada vez), mas ainda assim a eficiência acaba se mostrando baixa após o impacto inicial.

Descobri por acaso um plugin para WordPress que é uma verdadeira mão na roda, pois além de reconhecer spambots sem a necessidade de uso de Javascript implementa uma “lista negra” de palavras proibidas, que se estiverem presentes em um comentário enviam-no diretamente para lugar nenhum (eu ia dizer que mandam para o inferno, mas aí os evangélicos poderiam não entender a piada — que nem é tão engraçada — e eu acabar me incomodando).

Como os spammers veem o seu blog

O nome do plugin milagreiro é NoSpamNX. A maneira mais simples de instalá-lo é pela Dashboard do WordPress: vá em Plugins, Adicionar Novo, e pesquise pela palavra “nospamnx” (sem as aspas, claro). Na página seguinte clique em instalar, confirme na janela de confirmação, e pronto, agora é só ativar como você sempre fez.

Há três configurações que importam no NoSpamNX.

A primeira diz respeito a como o plugin deve tratar os spams que ele vier a reconhecer: jogando-os na “pasta” de spams de comentários, ou bloqueando-os permanentemente. Antes de decidir por recomendar o plugin a outros eu o usei por um tempo apenas marcando os spams, e não encontrei nenhum falso positivo. A partir de então deixo o plugin apagar tudo automaticamente. A escolha, claro, é sua, mas apenas marcar os spams como tal não vai diminuir o volume de trabalho, pois você vai continuar tendo de ver aquele lixo todo.

A segunda configuração é um pouco mais delicada, pois nem sempre funciona com todo mundo (mas o autor do plugin foi bacana o suficiente para incluir um teste da funcionalidade): é a que faz com que o plugin verifique se o comentário foi enviado a partir de uma página no seu próprio blog ou não (o que o plugin chama de “referer check”). Clique no link que diz Referer-check, na página de configuração, e veja a mensagem de retorno: se o plugin disser que o “referer” funciona no seu servidor, habilite esta opção.

Por fim, a configuração mais interessante, em minha humilde opinião: a lista de palavras bloqueadas.

Existem alguns comentários que são extremamente irritantes, como as correntes de “transforme seis reais em sei mil” (incrível como sempre tem otário que acredita nisso), as orações poderosas para amarrar marido, e os piores de todos: comentários deixados por outros blogueiros apenas com dizeres do tipo “visite meu site”, sem agregar conteúdo algum.

O WordPress tem um recurso semelhante a esse, nativo, mas em vez de apagar ele apenas marca como spam. O NoSpamMX deleta (caso você o tenha configurado para excluir os spams automaticamente).

Minha lista negra contém as seguintes palavras:

mentalidade.com
detetive-particular.net.br
Oxycodone
Without Prescription
?????
mentalidade.com
yougetsex.com
cashfiesta.com
www.awsurveys.com/HomeMain.cfm?RefID=
ganhardinheirointernet.hd1.com.br
TRANFORME R$ 6,00 EM R$ 6.000,00

Com estas configurações consegui reduzir o volume de spam nos meus blogs para dois ou três por semana (que passam pelo NoSpamNX e pelo Akismet).

Uma força extra

Apesar de o NoSpamNX e o Akismet serem produtos ótimos, nem sempre eles terão “a manha” de apagar todos os spams automaticamente. É quando o URL Nuker entra em ação.

Embora não sofra mais atualizações desde já há muito tempo, o plugin ainda funciona com as versões mais recentes do WordPress, e faz exatamente o que promete: exclui automaticamente comentários já marcados como spam mas que contenham mais do que n URLs (sendo n um valor qualquer que você configura).

Este post foi publicado no blog Viamão Lotado. Se você está lendo a partir de outro local, é bem provável que ele tenha sido plagiado. Por gentileza, nos avise.

WP: Acabe com os spams de comentários com o NoSpamNX

Embora a função primária de um plugin de cache não seja acelerar o carregamento das páginas, e sim evitar processamento duplicado, economizando ciclos de processamento, uma boa solução de cache pode significar, sim, algum ganho de velocidade.

Tendo em vista esse parâmetro efetuamos um teste simples (e sem nenhuma pretensão de ter valor científico, e ainda menos de servir de guia para a escolha de ninguém.

Plugins considerados

Testamos o WordPress em sete cenários diferentes, envolvendo três plugins.

1. Sem plugin algum de cache;
2. Hyper Cache;
3. WP Super Cache em modo Half;
4. WP Super Cache em modo Full;
5. WP Super Cache em modo Full servindo HTML direto do cache;
6. Quick Cache;
7. Quick Cache com gzip ativado.

Cabe dizer aqui que o Quick Cache sequer havia sido cogitado; em seu lugar, neste teste, pretendíamos usar o W3 Total Cache, que ficará para uma próxima oportunidade tendo em vista que ele é menos trivial de se fazer funcionar, requerendo configurações de servidor que talvez sejam menos fáceis para o blogueiro comum.

Entretanto, quando fomos instalar o WP Super Cache acabamos encontrando por acaso o Quick Cache, e sua proposta de ser uma alternativa àquele plugin agradou; experimentamos e gostamos (mais detalhes abaixo).

Blog testado

O blog que escolhemos para fazer o teste foi o Emagrecer, e testamos a página inicial e mais dois posts escolhidos aleatoriamente.

1. “Gene da Obesidade” pode ser superado com exercícios (Post 1);
2. Diário de um gordo (Post 2).

Ferramenta de medição

Utilizamos a ferramenta de teste de página completa do Pingdom para medir o tempo total de carregamento das páginas.

Metodologia

A metodologia adotada foi muito simples.

A cada teste, em cada cenário, instalávamos o plugin e o configurávamos de acordo, e num outro navegador acessávamos cada uma das três páginas para garantir que elas estivessem em cache, e então efetuávamos o teste pelo Pingdom.

Os tempos de carregamento total foram anotados e são reproduzidos na tabela abaixo.

Resumo dos Resultados

Interpretação dos Resultados

A tabela acima demonstra que tempos de carregamentos de página isolados não querem dizer muita coisa, haja vista um post que foi bem num cenário foi mal em outro, e outro post que foi mal no primeiro foi bem no segundo. Por exemplo: o Post 2 se saiu bem com o Hyper Cache (3,3s) e foi mal no WP Super Cache em Full Mode servindo HTML direto; entretanto, o Post 1 se saiu melhor neste cenário de plugin, mas se saiu pior com o Hyper Cache.

A tabela demonstra também que variações nos tempos de carregamento são comuns, e seria necessário uma amostragem muito maior para ser possível chegar a valores estatisticamente mais úteis e expressivos.

Por fim, demonstra também que em situações normais todos os plugins de cache se comportam de maneira semelhante, cabendo mais a cada blogueiro decidir pelo que lhe for mais simpático, agradável, fácil de instalar, ou qualquer outro critério; ou seja, o que é ótimo para mim pode não ser para você, e vice-versa.

Entretanto, é notável que o Quick Cache tenha apresentado menos variações nos tempos de carregamento das três páginas, e obtido a menor média (3,2s na média), o que nesse caso é desejável. Considerando o fato de que o Quick Cache nem deveria ter entrado no teste, podemos dizer que ele foi uma grata surpresa.

Outras Considerações

A ativação e desativação do Quick Cache não é tão simples e sem falhas como deveria; aparentemente a rotina de “coleta de lixo” ainda tem algum bugzinho não resolvido, causando mensagens de erro estranhas de tempos em tempos da “Dashboard”.

Apesar disso, vale a pena testar o plugin.

As principais diferenças do Quick Cache para o WP Super Cache são as seguintes, retiradas da documentação do plugin e livremente traduzidas para privilegiar a simplicidade.

• O Quick Cache tem menos código, logo tende a ser mais eficiente, e não requer nenhuma regra de reescrita de URL no .htaccess, e para usar basta ativa o plugin (não tenho certeza de que o WP Super Cache exija as regras de reescrita, mas como consta na documentação fica aqui o item).
• O Quick Cache já vem preconfigurado com as opções mais típicas, enquanto que no WP Super Cache o usuário precisa decidir por um entre três modos, além de precisar, segundo eles, criar regras de .htaccess para perfeito funcionamento do plugin.
• O Quick Cache alega ter um controle melhor, mais inteligente e mais eficiente de quem vê páginas em cache ou não, garantindo que o autor do blog sempre seja servido com páginas que não estejam no cache.

O próximo teste

Em nosso próximo teste (sem previsão de data) incluiremos o W3 Total Cache em seus vários cenários, inclusive medindo a economiza de tempo ao usar o recurso de “minify” (compactação de JavaScript e CSS), levando a rapidez de carregamento à proximidade do limite máximo teórico de velocidade, comprovando ou contestando sua autoproclamada fama de ser o melhor e mais rápido plugin de cache para o WordPress.

Este post foi publicado no blog Viamão Lotado. Se você está lendo a partir de outro local, é bem provável que ele tenha sido plagiado. Por gentileza, nos avise.

Comparativo entre plugins de cache — tempo de carregamento

Uma das expectativas que os leitores de feed têm é de terem sempre notícias e novidades absurdamente fresquinhas em seus programas de leitura de RSS, dos quais o mais comum e utilizado é o Google Reader.

Uma novidade que vai interessar muito quem quer atingir o objetivo de ter seus feeds publicados imediatamente no Google Reader dos seus leitores é o protocolo PubSubHubBub, que funciona como uma espécie de “ping” anabolizado: em vez de seu feed ficar lá, quietinho, publicadinho, esperando que o leitor de feeds o resgate, o protocolo permite que o feed “se empurre” para dentro do Google Reader. O resultado, que é o que interessa, é que os posts publicados são disponibilizados em tempo real no Google Reader.

Tudo que você publicar no Tumblr, no Posterous, no Blogger, no WordPress.com e em outros sites, automaticamente se beneficiará do PubSubHubBub.

E se você quiser fazer o seu WordPress em domínio próprio tirar proveito da novidade também, é muito simples, basta instalar um plugin, ativá-lo e produzir conteúdo. O Viamão Lotado usa o WP-PubSubHubBub.

Agora, uma situação não testada, e se alguém que fizer o teste quiser postar as impressões aqui agradecemos, diz respeito a quem faz uso do FeedBurner, que tem seus próprios sistemas de ping e de cache, que já causaram algumas dores de cabeça a todo mundo que já tenha feito uso da ferramenta.

Este post foi publicado no blog Viamão Lotado. Se você está lendo a partir de outro local, é bem provável que ele tenha sido plagiado. Por gentileza, nos avise.

Atualize o Google Reader instantaneamente ao publicar um post

A mais recente discussão diz respeito à política de distribuição de plugins, que de acordo com o que tem sido publicado podem vir a ser comprados numa espécie de “WP Store” (numa alusão aos métodos de venda de aplicativos para plataformas móveis como Nokia — que tem a OVI Store —, e iPhone — ganha um doce quem lembrar de Apple Store.

Embora a maioria das pessoas que usam plugins em seus blogs (inclusive eu, naturalmente) não seja muito afeita a pagar, essa discussão acerca da possível criação de um modelo de negócios para o mercado de plugins é algo muito saudável. Basta ver a quantidade de excelentes projetos que são abandonados porque o autor precisou do tempo que investia neles para ganhar o sustento de sua família.

As discussões pendem para todos os lados, desde o extremo que não admite a cobrança por plugins do WordPress até o extremo que acha que tudo deve ser cobrado.

Naturalmente, a posição mais equilibrada não pende nem para um nem para outro lado. Algum meio termo é que precisa ser encontrado, para que mais gente fique feliz enquanto brinca de blogar.

Particularmente, acho que assim que passar a fase de choro e ranger de dentes as coisas vão se acalmar, e dentro de pouco tempo ninguém nem lembrará mais porque terá existido essa discussão.

De fato, existem muitos plugins “premium” no mercado hoje, que só chegam aos blogs dos meros mortais por meio de pagamento de taxas de setup, manutenção, ou seja do que for. E quem quer paga, quem não quer procura a alternativa gratuita e priu!

A discussão está longe de acabar, naturalmente, e eu arrisco que o ponto de discórdia haverá de ser a licença GPL ou sua variação, que rege o WordPress.

Até lá, blogueiros do planeta inteiro seguem como se nada estivesse acontecendo, tornando-se mais popular o mais popular dos posts plugins populares, pouco importando se é comercializado ou não, pois o próprio mercado trata de selecionar os sobreviventes, a massa de manobra e os líderes.

Este post foi publicado no blog Viamão Lotado. Se você está lendo a partir de outro local, é bem provável que ele tenha sido plagiado. Por gentileza, nos avise.

Vem aí uma nova política de plugins para o WordPress

Para tentar convencer os mais renitentes, preparamos uma listinha com dez motivos para Atualizar seu WordPress para a versão 2.9, sem nenhuma ordem específica de importância ou do que for.

1. Muitos bugs corrigidos
Esta é a mais óbvia das razões. Sempre que um software é atualizado, muitos bugs e pequenos problemas das versões anteriores são corrigidos. E novos problemas são criados (é bom experimentar algumas novidades).

2. Segurança
Como as versões antigas do WordPress param de receber melhorias e consertos, caso alguém descubra uma falha de segurança e resolva explorá-la no seu blog você estará perdido, pois apenas a versão nova vai receber atualizações de segurança constantemente.

3. Autorreparação de tabelas
Quando se usa um aplicativo que faça uso intenso do banco de dados, como é o caso do WordPress, as constantes inserções e exclusões dos dados das tabelas vão automaticamente inchando os arquivos correspondentes, e em casos mais extremos (e nem tão raros assim) levando à necessidade de efetuar reparos no banco de dados para voltar a ter performance, ou mesmo operar com o banco.

Agora o WordPress conta com um recurso interno de reparação automática das tabelas do banco de dados, sem depender de plugins para isso.

Para ativar esse recurso é só incluir o seguinte código no wp-config.php.

define('WP_ALLOW_REPAIR',true);

4. Suporte a oEmbed
O oEmbed é uma tecnologia que facilita a inclusão de mídias externas no corpo de um post.

Por exemplo, para incluir um vídeo do YouTube você só tem que inserir o link para o vídeo sozinho numa linha, e automaticamente o WordPress vai tratar de descobrir como se faz para exibir o vídeo na página, e vai fazê-lo.

Para entender melhor: na linha abaixo vou inserir apenas a URL http://www.youtube.com/watch?v=qqkNPmOpu3Q, e na hora de exibir o post você verá:

Veja a imagem para comprovar.

Caso queira, você também poderá usar o shortcode “embed” para obter o mesmo efeito.

[embed]URL a ser inserida[/embed]

A lista de sites suportados é grande, e não é nosso objetivo dissecar o oEmbed, mas basta saber que os principais sites de vídeo funcionam, bem como o PollDaddy (usado para enquetes online) e o Flickr.

5. Miniaturas de Imagens para Posts
Já falamos sobre esse recurso (WordPress 2.9: como usar as miniaturas automáticas), que permite a inclusão de uma imagem para cada post, que será usada posteriormente como ilustração onde o programador do tema o definir.

6. Editor de Imagens
E por falar em imagens, vale ressaltar que o WordPress 2.9 agora conta com um editor básico que permite sem abandonar o ambiente de edição de post recortar, redimensionar, girar e espelhar as imagens que venhamos a subir para o blog. É claro que não tem todo o poder de outras soluções (mesmo web) mais completas, como aplicação de efeitos ou processamento mais avançado das imagens, mas já quebra um galho imenso.

7. Atualização de plugins em lote
Sempre é um saco atualizar plugins, apesar de as versões mais recentes do WordPress contarem com a atualização automática.

Entretanto, o WordPress 2.9 agora conta com um recurso de atualização em lote: você marca os plugins que deseja atualizar, clica um botão, e pronto, o WordPress atualiza todos de uma vez só, sem complicação.

8. Lixeira de posts
Agora, quando você apaga um post (vale para arquivos da galeria de mídia também) ele não é removido imediatamente. Em vez disso, ele vai para uma lixeira, e caso você se arrependa ou precise por qualquer motivo do objeto deletado, será possível proceder a restauração.

É possível programar o WordPress para limpar a lixeira automaticamente. Basta inserir o código abaixo no wp-config.php.

define('EMPTY_TRASH_DAYS',7);

Da maneira como está, o código acima instrui o WordPress a excluir automaticamente da lixeira todos os objetos que estejam lá por mais de sete dias.

9. URLs canônicas automáticas
Agora o WordPress automaticamente insere o atributo rel=’canonical’ nas URLs que vier a gerar, o que deve ter impacto direto na indexação do site e na maneira como os buscadores lidam com conteúdo duplicado.

10. Código da área administrativa melhorado
Por fim, para encerrar essa listinha (que está bem longe de cobrir todas as mudanças da nova versão — veja o changelog), vale dizer que a área administrativa foi reescrita, tornando-a mais veloz para carregar e executar, embora visualmente quase não se notem mudanças.

Conclusão
Todo mundo vai ter mesmo que atualizar seu WordPress, mesmo que demore um pouquinho mais para alguns. Esperamos com esta listinha ter incentivado os mais resistentes a pelo menos olhar para a nova versão com olhos de que talvez valha a pena o investimento.

Este post foi publicado no blog Viamão Lotado. Se você está lendo a partir de outro local, é bem provável que ele tenha sido plagiado. Por gentileza, nos avise.

Dez Motivos para Atualizar para o WP 2.9

O que pode ser fonte de expectativa pra muita gente, também certamente vai ser fonte de decepção: o recurso de “post thumbnails” requer um tema preparado para eles, e não vai funcionar “fora da caixa” para qualquer tema instalado no site.

Entretanto, não é muito difícil de adaptar o seu tema para que o recurso das imagens de posts fiquem disponíveis.

O primeiro passo é habilitar no seu tema o suporte aos thumbnails, que é o que vai habilitar o painel de configuração da miniatura do seu post. Para fazer isso basta inserir em algum lugar do functions.php do tema o seguinte código:

<?php add_theme_support( 'post-thumbnails' ); ?>

Ao salvar esta alteração no functions.php, quando você entrar na página de edição de posts haverá um novo painel, como mostra a imagem abaixo.

Para definir o thumbnail de cada post, basta clicar em Set Thumbnail e fazer o upload de uma imagem, ou escolher uma imagem das previamente enviadas para o blog, como você está acostumado a fazer para inserir uma ilustração no post. Só que em vez de clicar para inserir no post, você vai clicar na nova opção “set as thumbnail”.

Na imagem acima você vê um post que já teve seu thumbnail definido.

Essa é a parte fácil. Agora vem a parte difícil, que é preparar o seu template para exibir o thumbnail correspondente a cada post.

Nota: pressupomos que você tenha conhecimento suficiente de PHP e de personalização de templates para fazer as modificações abaixo descritas. Não é nosso objetivo ensinar o básico do básico.

Na verdade, a função the_post_thumbnail() é quem faz todo o trabalho de encontrar, dimensionar e exibir as imagens de cada post, já com a tag IMG corretamente formatada.

Ela pode ter os seguintes formatos:

the_post_thumbnail("small");
the_post_thumbnail("medium");
the_post_thumbnail("large");
the_post_thumbnail(array($widht, $height));

Os strings small, medium e large acima vão fazer com que o WP exiba um thumbnail no tamanho padrão (que você configura nas opções do WP).

O quarto formato é o mais versátil de todos, do ponto de vista dos codificadores de temas para WordPress, porque permite que o designer defina tamanhos arbitrários exatos para as imagens, independentes das configurações do WordPress.

Caso você precise usar o HTML inteiro da imagem para algum outro fim, pode usar a forma abaixo.

<?php
$img = get_the_post_thumbnail(array(200,200));
?>

O código acima foi retirado do template do site Das Fútil, que usa uma versão Beta do WP 2.9, e com diversos tamanhos de post thumbnails na home page.

É só isso.

Há uma série de hooks para modificar o comportamento das imagens nos posts, mas quem sabe lidar com eles também saberá como encontrar a documentação necessária para utilizá-los no próprio WordPress.

Esperamos que com esta breve explicação mais gente possa usar o novo recurso de imagens de posts no WordPress 2.9, contribuindo com uma web mais bonita e mais simples de manter.

Este post foi publicado no blog Viamão Lotado. Se você está lendo a partir de outro local, é bem provável que ele tenha sido plagiado. Por gentileza, nos avise.

WordPress 2.9: como usar as miniaturas automáticas

Entretanto, nem sempre existe um plugin pronto para o que precisamos fazer, principalmente quando se trata de algo aparentemente simples, e quando existe a complicação envolvida é muito grande.

Nestes momentos, saber um mínimo de programação e do funcionamento do WordPress ajuda muito.

Eu tinha uma necessidade muito simples, mas que não encontrava em nenhum plugin pronto uma solução aceitável: eu queria produzir “olhos” (acho que assim que se chama, sou um zero à esquerda em tipografia), ou seja, aquelas caixinhas de texto com um trecho do texto principal em destaque. Tem plugin pra isso, mas usando “custom fields”, um horror de entender a mecânica, nem me animei a implementar. Além disso, eu queria que esses olhos fossem conteúdo adicional, complementar ao post, e não um mero destaque de um excerto. Ou seja, eles precisariam aparecer no feed também!

Escolhi resolver o problema utilizando shortcodes do WordPress, na verdade a mesma técnica já descrita em outro artigo de minha autoria: Monetize seus posts antigos no WordPress.

Assim, criei o shortcode que resolvi chamar de infobox, e que tem o seguinte formato.

[infobox]Texto que vai aparecer destacado[/infobox]

Simples, não?

O efeito visual pode ser conferido “ao vivo” na página Como funciona o GPS do Xperia X1, ou pela imagem abaixo (só da parte que interessa).

Para obter o mesmo resultado em seus posts você só tem que inserir o seguinte código no arquivo style.css do seu tema.

.infobox {
float: right;
font-style: italic;
font-face: Arial;
margin: 12px 0 12px 9px;
border-left: 3px solid #c00;
padding-left: 5px;
width: 240px;
width: 35%;
padding: 4px 0 4px 8px;
font-size: 80%;
clear: right;
background-color: #ffffff;
}

E no arquivo functions.php do tema insira o seguinte código (antes do ?>, naturalmente).

// Meus shortcodes
function janio_infobox($atts, $content=''){
  if (!is_singular())
    return "<em>$content</em>";

  $before = "<div class=\"infobox\">";
  $after = "</div>";

  return $before . $content . $after;
}

add_shortcode('infobox', 'janio_infobox');

O código realmente é muito simples e fala por si.

Primeiro criamos a função que vai interpretar o shortcode, e em seguida a registramos no WordPress.

A nossa funçãozinha então recebe o texto que está no shortcode, e verificamos se estamos numa página singular (um post ou uma página no site), pois não queremos correr o risco de bagunçar o layout da página incial, tampouco queremos deixar o feed bagunçado.

Então, se não for uma página singular, o código apenas o envolve numa tag de itálico (poderia ser um blockquote também), ou poderíamos fazer um return “” para fazer o infobox simplesmente sumir.

Caso seja uma página singular, o código cria a tag DIV com a classe CSS infobox, e retorna a tag inteira, com o conteúdo, para que o WP trate o conteúdo normalmente.

Quais os outros usos que você gostaria de ver para os shortcodes do WordPress? Os comentários são seus!

Este post foi publicado no blog Viamão Lotado. Se você está lendo a partir de outro local, é bem provável que ele tenha sido plagiado. Por gentileza, nos avise.

Diferencie seu blog usando recursos do próprio WordPress