Quando vamos criar um tema para o WordPress temos três opções de escolha para modelar a página inicial do site. E como a moda hoje é ter uma página inicial diferente, mesmo que você tenha apenas um simplório blog, é muito importante sabermos diferenciar quando estamos falando de Home ou de uma Front Page.

Por padrão o WordPress apresenta a página inicial do site como uma página básica de blog, mostrando os artigos mais recentes postados. Sendo assim, o primeiro arquivo na pasta do tema que o WordPress busca é o index.php. De fato, você pode criar seu tema todo através do index.php já que o WordPress sempre voltará nele caso não exista um arquivo de tema mais específico para apresentar.

Mas como somos organizados (eu espero!), é lógico que você não vai querer toda a estrutura do tema em um arquivo só. Voltando para a página inicial o WordPress pode usar dois outros arquivos como página inicial, o home.php e o front-page.php.

Mas qual a diferença dos dois? É bem simples, o Home é a página inicial que o WordPress irá mostrar se você não especificar alguma outra página como página inicial, já a Front Page é, obviamente, a página especificada como página inicial.

Não entendeu? É porque é realmente simples! Se você for no menu Configurações e no sub-menu Leitura, vai entender. A primeira configuração que aparecerá será A página inicial mostra com as opções Seus posts mais recentes (padrão) e Uma página estática (selecionar abaixo). Se você não selecionar uma página estática, deixando a opção no padrão, então você terá uma Home, mas se você definir uma página estática como inicial, então você terá uma Front Page.

Para deixar ainda mais fácil: se a página inicial possuir uma lista com os artigos mais recentes é uma Home, já se mostra o conteúdo de uma página, é uma Front Page.

Agora vem a parte realmente importante. Se você criar um tema com um layout diferente para a página inicial e coloca ele no arquivo front-page.php, ele só terá efeito se você escolher uma página estática como a página inicial. Fique atento, o loop de posts padrão que você chamar nesse arquivo só retornará o conteúdo da página estática em questão, assim você pode transformar qualquer página estática em uma página personalizada usando ela como página inicial.

Agora se você implementar o layout diferente da página inicial no arquivo home.php, ele só terá efeito se a opção padrão de página inicial (os posts mais recentes) estiver selecionada. Aqui sim, o loop padrão de posts conterá os posts mais recentes publicados no site. É óbvio que você pode criar loops customizados em ambas as opções, ou nem mesmo usar loop nenhum, mas é importante lembrar que a diferença de Home e Front Page implica diferença no resultado do loop padrão.

Há também duas funções de comparação muito usadas, inclusive em plugins, que merecem a atenção. Trata-se da is_home() e da is_front_page(). Como sugere, a is_home() retorna verdadeiro se a página em questão for a página inicial de posts recentes, já a is_front_page() retorna verdadeiro se a página em questão for uma página inicial estática.

Sabendo disso fica bem mais fácil programar a página inicial do seu tema. Lembrando que seu tema pode incluir os dois arquivos, home e front-page, que o WordPress vai pegar o correto conforme a configuração.

Até a próxima!

Bom, não sei se é realmente um bug, mas não funciona como deveria. A função em questão é a get_categories(), que serve para pegar uma lista com todas as categorias, de forma bem semelhante ao wp_query(). Acontece que no get_categories() o parâmetro ‘orderby’, que ordena a listagem, não funciona corretamente.

Fiz o teste usando tanto o ‘orderby’ definido para nome, slug ou count, em todos eles a listagem vinha em uma ordem totalmente errada. Tentei procurar alguém com o mesmo problema mas não encontrei nada no Google, então tive que ir atrás de ordenar eu mesmo a lista. E é aí que entra o tal do uasort.

Como você já deve ter percebido, 99% das funções do WordPress ao retornar algum dado faz isso usando um array de multinível, também conhecido como matriz, o que impossibilita o uso de funções mais simples como a sort, que é usada para ordernar arrays simples, ou vetores.

Um vetor basicamente é uma série indexada de valores, assim:

array ( [0] -> valor 1, [1] -> valor 2, [3] -> valor 3 );

Já uma matriz é uma série indexada de vetores, ou seja:

array ( [0] -> array ([0] -> valor 1, [1] -> valor 2), [1] -> array( [0] -> valor 1, [1] -> valor 2 ) );

E para que seja possível passar vários dados estruturados em uma única variável, como é o caso das categorias, já que cada categoria possui várias variáveis, o WordPress utiliza matrizes. Uma ótima escolha, mas e o tal do uasort?

Bom, podemos utilizar o uasort para ordenar a matriz quando o WordPress não faz isso, seja por causa de bug ou por que ele simplesmente não oferece a opção. Note que se o WordPress oferecer a opção, o melhor é sempre usá-la, já que nesse caso ele ordenará o resultado ainda no Banco de Dados, otimizando o desempenho. Usar o uasort também pode ser muito útil quando você quiser apresentar dois resultados iguais em ordens diferentes sem precisar invocar a função de pesquisa novamente.

O PHP conta com várias funções de ordenação, mas apenas de nível simples, para vetores. Como as matrizes possuem diversos valores em diversos formatos em diversos índices, seria impossível uma função que descobrisse sozinha por qual índice seria a ordenação e qual formato seguiria. O uasort permite que nós criemos nosso próprio meio de ordenação, o que permite criarmos funções avançadas de ordenação.

Para usar o uasort é bem simples, precisamos criar uma função que recebe dois valores e chamar a função passando a variável, assim:

uasort($variável, "função_de_ordenação");

function função_de_ordenação($a,$b) {

//Como sabemos a estrutura da matriz, podemos comparar seu conteúdo. Aqui vou ordenar uma matriz que entre suas variáveis possui a 'count' que representa o número de posts dentro de cada categoria.

if ($a->count == $b->count)

return 0;

return ($a->count < $b->count) ? 1 : -1;

}

Note que a função obrigatoriamente tem que retornar 0 se os valores forem iguais, 1 se o primeiro valor for maior ou -1 se o primeiro valor for menor. Simples não?  Podemos deixar ainda mais interessante o exemplo acima, caso o ‘count’ seja igual, vamos deixar em ordem alfabética, usando a função de comparação strcmp:

function função_de_ordenação($a,$b) {

if ($a->count == $b->count)

return strcmp($a->name, $b->name);

return ($a->count < $b->count) ? -1 : 1;

}

Simples não é? Então fica aí a dica do uasort. Você pode precisar dele quando menos esperar (e ele vai te livrar de uma dor de cabeça enorme

Até a próxima!

Mas até então não havia encontrado nenhum realmente completo, com todas as reais funções de uma página de login. Até que precisei criar um para um tema de compras coletivas na qual fui contratado como freelancer e tiver que buscar informações na raça em vários sites. Por isso, vou facilitar a vida de vocês e demonstrar minha solução.

O Template

Primeiramente você irá querer criar um Page Template para sua página de login, no meu caso o arquivo se chama template-login.php , bem direto né? Para definir ele como um Page Template, basta adicionar os comentários de identificação no topo do arquivo:

/**
* Template Name: Page – Login
*/

Aqui você irá criar sua página de login com as devidas tags HTML que você precisar. Eu espero que você saiba como fazer isso, senão aprenda em outro lugar antes.

 O Formulário

Vamos criar o formulário, a parte mais “visível” de nossa página. O código é bem simples, basicamente você vai criar um formulário com dois campos (usuário e senha) e o botão de submit.

O primeiro diferencial do meu código ao dos outros tutoriais, é que no meu código o formulário de login aponta para a minha própria página de login, enquanto nos outros apontam para o wp-login.php do próprio site. Funciona, mas se o login falhar por algum motivo (como senha errada) o usuário acaba vendo o formulário padrão de login, que é o que estamos tentando evitar.

Alguns poucos tutoriais ainda citam o uso do hook wp_login_failed, que deveria redirecionar o usuário para outra página caso o login desse errado, mas nos meus testes e em buscas no fóruns, vi que o hook não funciona na maioria dos casos (não me pergunte o porquê!).

Então vamos lá, criando o nosso simples formulário:

<form method="post">

<input type="text" name="log" value="Usuário"/>

<input type="password" name="pwd" value="" />

<input type="submit" value="Logar" />

</form>

O Header

A mágica acontecerá no header do nosso Page Template. É aqui que tentaremos logar o usuário. Por isso, é importante colocar o código abaixo antes de qualquer impressão e antes mesmo do get_header(), porque precisaremos definir valores de cookies.

Antes de executarmos a função, obviamente vamos querer ver se estamos recebendo um login e uma senha. Afinal, não há porque tentar fazer um login sem essas duas informações, não é mesmo? Para isso, usaremos comparações padrões de if. Note que usaremos a variável $message para guardamos possíveis mensagens de erro:

if ($_POST['log'] || $_POST['pwd']){

if (!$_POST['log'])

$message = 'Cadê seu nome de usuário tapado?';

elseif (!$_POST['pwd'])

$message = 'O campo senha não é opcional.';

else {

//1º Passo = Done!

}

}

Simples até então, certo? Temos o usuário e a senha, agora vamos usar a própria função do WordPress de conferir usuário e senha, a wp_authenticate. Se o usuário e senha existirem, teremos a classe user com todos os dados daquele usuário, caso contrário receberemos uma mensagem de erro. Perceba que o próprio wp_authenticate faz o serviço sujo de anti-injections.

$user = wp_authenticate($_POST['log'],$_POST['pwd']);

if ($user->ID>0) {

//2º Passo = Done!

} else {

$message = 'Tá errado! Não vai me dizer que esqueceu a p** da senha de novo?';

}

Se o usuário e senha existirem, ótimo, caso contrário informamos o usuário de que a senha ou usuário está errado. Agora vem uma parte importante, salvar a sessão do usuário. Para isso teremos que usar outra função, a wp_set_auth_cookie que precisa saber apenas o ID do usuário que terá a sessão salva.

wp_set_auth_cookie($user->ID);

Finalmente, após salvar a seção, basta jogarmos o usuário para a página que quisermos, como a página inicial do site, por exemplo. Para isso, vamos usar a função wp_redirect, lembre-se sempre de usar o exit após ela.

wp_redirect( home_url() );

exit;

Pronto! Confere o resultado final:

if ($_POST['log'] || $_POST['pwd']){

if (!$_POST['log'])

$message = 'Cadê seu nome de usuário tapado?';

elseif (!$_POST['pwd'])

$message = 'O campo senha não é opcional.';

else {

$user = wp_authenticate($_POST['log'],$_POST['pwd']);

if ($user->ID>0) {

wp_set_auth_cookie($user->ID);

wp_redirect( home_url() );

exit;

} else

$message = 'Tá errado! Não vai me dizer que esqueceu a p** da senha de novo?';

}

}

Deixando mais interessante

O nosso formulário de login está pronto, basta criar uma página, definir o template dela com o que acabamos de criar e mudar os links de Logins do seu site para ela.

Mas ela é bem básica, não é mesmo? Você provavelmente irá querer fuçar nela de várias formas, por isso vai algumas dicas do que eu já fiz nas minhas:

• Checkbox de “Lembrar-me” – Bem útil e simples, basta colocarmos um checkbox no fim do nosso formulário. Na nossa função de logar, verificamos se o checkbox está marcado, se sim, ao salvarmos a sessão usamos true como segundo argumento da função wp_set_auth_cookie, assim aumentamos a vida do cookie de 2 dias para 2 semanas.

<input name="rememberme" type="checkbox" value="forever" />Lembrar

if ($_POST['rememberme']=="forever")

wp_set_auth_cookie($user->ID,true);

else

wp_set_auth_cookie($user->ID,false);

• Redirecionamento personalizado: No meu caso, o formulário poderia ser carregado em qualquer página. Nesse caso, após logar, voltar para a página inicial nem sempre faria sentido, por isso criei um campo escondido no formulário para salvar a atual URL e redirecionar para ela após logar. Note que salvo ela entre tentativas consecutivas de login. Na nossa função, basta usar o valor dela na hora de redirecionar, note também que no meu caso eu não quero nunca que o usuário volte para a página de login após logado, por isso, se houver login na URL do redirecionamento, eu mando ele pra página inicial.

<input type="hidden" name="redirect_to" value="<?php echo $_SERVER['REQUEST_URI']; ?>" />

if (!strpos($_POST['redirect_to'], 'login')){

wp_redirect( site_url($_POST['redirect_to']) );

} else

wp_redirect( home_url() );

• Função de Deslogar: Podemos também criar a função para deslogar o usuário de forma simples. Antes da nossa função podemos verificar uma variável qualquer, como a action, caso ela seja logout, deslogamos o usuário. Assim, basta criarmos um link para a nossa página personalizada com um ?action=logout na URL para deslogarmos o usuário.

if ($_GET['action'] == 'logout') {

wp_logout();

$message = 'Vaza!';

}

<a href="<?php echo site_url('/login/?action=logout'); ?>">Logar</a>

Conclusão

O formulário de login não foi tão difícil de criar, o mais difícil foi apenas descobrir essas funções do WordPress relacionadas ao login que, apesar de estarem documentadas, não estão relacionadas.

O código completo para o arquivo criado neste artigo você confere aqui. Note que eu não cheguei a testar, porque no meu projeto meu template está bem mais cheio de códigos, com jQuery, outras funções e etc. Mas deve funcionar

Usando técnica semelhante, também consegui criar páginas próprias para refazer a senha e registrar, tem alguns outros detalhes, mas isso fica pra outro post.

Até a próxima!

Dentre as novidades temos uma muito interessante, que é o input type=”number”, atualmente quando queremos receber um valor do usuário, usamos apenas o input type=”text”. Se ele for um valor numérico cabe a nós fazer a validação através de código, muitas vezes em javascript.

O type=”number” vem para acabar com isso, o próprio navegador impedirá o usuário de digitar um número naquele campo. E não para por aí. O type number também possui três propriedades muito úteis:

• min: para definir um valor mínimo para o campo.
• max: para definir um valor máximo para o campo.
• step: para definir os incrementos de valor daquele campo.

Essas propriedades podem receber qualquer valor numérico ou real. As duas primeiras propriedades acima são bem simples e funcionam perfeitamente, já a terceira pode causar alguma dor de cabeça pois não funciona tão simples como podemos supor.

Antes de mais nada, é importante citar que a propriedade step ainda só funciona no Chrome e no Opera, no Safari também funciona, mas apenas no Mac. Ainda assim é uma propriedade que devemos começar a usar nos casos em que se aplique.

Primeiro vamos mostrar como o step funciona (os exemplos abaixo só funcionarão em um dos navegadores citados acima, vale a pena usar um deles para ver como funciona). Digamos que temos uma página de venda de produtos e o usuário deve escolher a quantidade de peças que irá comprar. O mínimo de produto é 1 e o máximo 10, podendo comprar qualquer quantidade entre esses valores. Nesse caso basta definirmos os valores e o step em 1. Confira:

Simples e perfeito, não? Agora vamos supor que o produto seja daqueles de pacote, digamos 3 em 1. O mínimo possível para comprar é 3, o máximo 30 e só pode comprar pacotes de 3 em 3, ou seja, step = 3. Dê uma olhada:

Caso não tenha testado, tente colocar manualmente o valor 5 acima, ou qualquer outro não múltiplo de 3 e aperte Enviar. Legal não? O step é uma propriedade muito interessante, mas devemos tomar cuidado com sua aplicação. Vamos a outro exemplo onde o uso do step não é recomendado.

Suponhamos que agora temos uma página de leilão onde o usuário precisa definir o valor de seu lance, mas queremos que o incremento mínimo seja de R$ 1,50. Muito simples, vamos criar o valor mínimo de R$ 5,00 (o valor atual do leilão) e o step em R$ 1,50. Vejamos:

Funcionou perfeitamente? Beleza, mas digamos que o usuário queira dar um lance de R$ 2,00, como ele vai fazer? Experimente no box acima. A propriedade step não só define os incrementos automáticos dos botões do input, mas sim restringe os incrementos, mesmo manuais, feitos no input. É muito importante se lembrar disso para não implementar o step errado.

No final, o uso do step acaba deixando o input number bem semelhante ao input range, já que restringe os valores que o usuário pode definir. Não encontrei uma maneira de usar o step mas sem restringir, como a validação é feita pelo próprio navegador não sei nem mesmo algum código javascript para ignorá-lo.

Agora vem a parte crítica da propriedade step. O valor padrão do step é 1, ou seja, se em algum momento você já implementou um input number e não declarou o step, saiba que nos navegadores em que ele já foi implementado, esse input só está aceitando valores inteiros. Se você quiser desabilitar a propriedade step não basta apenas não declará-la, mas sim definir o valor “any” para ela. Note que os incrementos automáticos ainda serão de 1, mas o campo aceitará qualquer valor:

Já vi muitos formulários aí pela web utilizado o input number mas sem se preocupar em declarar o valor any para o step, o input number ainda não foi implementado no Firefox e no Internet Explorer, mas devem estar presentes muito em breve, com o step também funcionando.

Vale lembrar que, o step funciona também no input de type range, date, datetime, month, time e week. Caso o usuário não esteja utilizando um navegador que suporte esses novos types de input, aparece para eles o velho e bom input text, por isso, nada de deixar de validar as entradas, tanto no back quanto no frontend.

Até a próxima!

Hoje encontrei a solução para um problema que estava já há muito me incomodando. Trata-se de um erro que ocorre quando você compartilha a URL de uma página que passa por regras de rewrite usando a hook generate_rewrite_rules do WordPress.

Para que serve?

Essa é a "Casa 1"... não minha, obviamente...

Para quem não tem conhecimento, usamos essa hook quando queremos criar URL amigáveis em casos especiais. Por exemplo, vamos dizer que você tenha um plugin para manter e organizar informações sobre residências. O plugin funciona usando apenas uma página do seu site, por exemplo, “Casas”, que fica na URL http://seusite.com/casas/.

Ao entrar na página Casas, o usuário verá uma lista com todas as casas cadastradas no plugin. Até aí tudo bem, quando o usuário clicar em uma das Casas ele irá para a página individual da casa, que também é controlada pelo plugin. Nesse caso a URL da página individual seria http://seusite.com/casas/?id=casa1 . A mesma página, mas com conteúdo diferente, já que a variável “id” está sendo passada e indica que o usuário quer ver mais informações da Casa 1.

Para deixar essa url mais amigável, usamos uma regra personalizada no WordPress através do hook anteriormente citado, a nova regra irá passar tudo que vier após /casas/ como uma variável de nome id usando o método GET. Ou seja, a URL será http://seusite.com/casas/casa1/ mas o WordPress irá interpretar como se fosse a página http://seusite.com/casas/?id=casa1.

Simples e bem útil, não é mesmo? Nesse caso pode até ser supérfluo, mas imagine por exemplo se ao invés de:

http://seusite.com/casas/?id=casa1&regiao=curitiba&pais=brasil

Você tiver apenas:

http://seusite.com/casas/brasil/curitiba/casa1

Bem melhor, não?

O Problema e sua Solução

Voltando ao problema, o que ocorre é que quando você vai compartilhar a URL http://seusite.com/casas/casa1/ no Facebook, ele reconhece o redirecionamento que passa a variável “id” e ao invés de pegar as informações como título, descrição e imagens, da página Casa 1, ele pega as informações da página Casas. E isso é muito impróprio. Afinal, ele estará considerando todas as páginas individuais de casa que você tiver, como a mesma página que  a página de listagem geral das casas.

Debugger do Facebook é uma mão na roda na hora de encontrar problemas nas meta tags de seu site.

Felizmente o Facebook oferece uma ferramenta de debug que mostra as informações que ele coleta de uma URL. Se você já está acostumado com as meta tags do Open Graph, já deve conhecer as tags “og:title”, “og:description” e “og:image”. Acontece que o Facebook também aceita uma outra tag, e até pede para que ela sempre seja informada, se trata da “og:url”.

Em um primeiro momento eu até pensei: “Qual o sentido dessa tag? Afinal ele pega esses dados de uma URL!”. Mas então resolvi fazer o teste, coloquei a tal tag no Header da página passando sempre a exata URL da página e… funcionou!

Não sei se o objetivo da tag “og:url” é exatamente esse, passar a URL de onde o Facebook deve extrair as demais tags, mas obviamente deve ser algo assim. Também não sei se esse bug de ignorar as regras do rewrite é intencional ou não. O Google Plus, por exemplo, funciona perfeitamente sem necessitar de qualquer adaptação. Enfim, sempre adicione a tag “og:url”, poderá te livrar de algumas dores de cabeça no futuro!

Até a próxima!

A nova versão do WordPress 3.3, a famosa Sonny, é maravilhosa, não é mesmo? Mas algumas pessoas estão enfrentando uma verdadeira dor de cabeça com a atualização. Após a atualização, o seguinte erro pode aparecer e bloquear o acesso à área de administração:

I'll not teach you how to fix your site.

Fatal error: Call to undefined function is_rtl()

Há grandes chances desse erro estar ocorrendo por causa do plugin Popup Domination. Para resolver o problema, basta acessar seu FTP, ir até a pasta dos plugins (wp-content/plugins/) e renomear a pasta “popup-domination” para qualquer outra coisa. Isso desativará o plugin e você terá acesso novamente à área de administração.

Se ainda assim o erro persistir, então o problema é com algum outro plugin ou até com seu tema. Então renomeie a pasta “plugins” para qualquer outra coisa para desativar todos os plugins, se resolver, renomeie a pasta de volta para “plugins” e vá ativando plugin por plugin até encontrar o causador do erro.

Como corrige o erro com o Popup Domination? Ah, aí já é outra conversa, mas como o plugin é comercial, você provavelmente poderá contar com o suporte oficial do plugin.

Até a próxima!