Olá pessoal, faz tempo que não posto nada aqui no blog, porém venho com uma dica que provavelmente vai ajudar muita gente. Há muitos tutoriais sobre como registrar posts e [...]
Usando taxonomia e posts personalizados no WordPress 3.0 is a post from: Marcelo Torres
O WordPress permite o armazenamento de diferentes tipos de conteúdo. Esses conteúdos são armazenados no banco de dados na tabela wp_posts e diferenciados pela coluna post_type.
Nas versões anteriores a 3.0 do WordPress, já era possível a criação de Tipo de Posts Personalizados(Custom Post Types), porém a partir da versão 3.0 foram implementados novos métodos com a finalidade de facilitar e popularizar o uso dos tipos de posts, que na verdade são tipos de conteúdos personalizados.
Um post (no banco de dados post) é o principal tipo de conteúdo utilizado, os Posts normalmente são exibidos em um blog ordenados cronologicamente. E também são usados na publicação dos feeds.
Uma página (no banco de dados page) é muito parecio com um post, porém não faz parte da mesma estrutura cronológica dos posts. Veja algumas diferenças importantes entre Posts e Páginas:
Um anexo (no banco de dados attachment) é um post especial que contém informações sobre arquivos enviados através do sistema de upload de mídia.
A revisão (no banco de dados revision), é usada para armazenar um rascunho de todos os posts (posts) e páginas (pages) existentes.
Um menu de navegação(no banco de dados nav_menu), é usado para armazenar todas as informações relacionadas aos menus de navegação, outra implementação que só está disponível a partir do WordPress 3.
Agora que já sabemos quais são os cinco tipos de posts padrão do WordPress, vamos ver como são criados novos tipos de posts personalizados.
Para adicionar um tipo personalizado no WordPress 3.0, é preciso usar a função register_post_type. Esta função permite que você defina o tipo de post e como ele se comporta dentro do WordPress.
[sourcecode language='php']
add_action( init, create_post_type );
function create_post_type() {
register_post_type( noticias,
array(
labels => array(
name => __( Notícias ),
singular_name => __( Notícia )
),
public => true,
)
);
}
[/sourcecode]
O código acima cria um tipo de post noticias, ou seja, toda vez que criado um post com este tipo, no banco de dados na tabela wp_posts na coluna post_type referente a este post, contará o valor noticias. A função register_post_type possui diversos parâmetros, no exemplo acima foram usados dois principais, o primeiro é o labels, que define o nome do novo tipo personalizado, o plural e o singular. O segundo é public, que é uma flag para mostrar o tipo de post na seção de administração do site, e para fazê-lo aparecer no site principal, se é adicionado nas queries ou não.
Você pode personalizar várias informações sobre o tipo personalizado, para saber mais sobre os outros parâmetros acesse a documentação da função register_post_type.
Para fazer consultas específicas e trazer apenas posts do tipo personalizado que você deseja, você pode utilizar o parâmetro post_type em um objeto WP_Query sempre que precisar, por exemplo:
[sourcecode language='php']
$loop = new WP_Query( array( post_type => noticias, posts_per_page => 10 ) );
while ( $loop->have_posts() ) : $loop->the_post();
echo
;
echo
;
endwhile;
[/sourcecode]
O código acima mostrará os 10 últimos posts do tipo noticias inseridos no painel administrativo.
Algumas vezes, na construção de um site em WordPress, você pode precisar criar algum tipo de estrutura fora da hierarquia padrão do WordPress e seus arquivos de template. No WP 3.0 com os post types personalizados, isso se tornou uma necessidade ainda mais frequente.
Você pode precisar, por exemplo, criar uma página com a listagens dos posts do tipo livros que você criou no seu código.
Este tutorial vai mostrar o funcionamento básico da classe WP_Rewrite() do WordPress que te ajuda a criar URLs customizadas e usá-las para extrair informações (sem precisar usar ?variavel=valor) ou para redirecionar para um arquivo de template criado por você.
Existem outras maneiras de interagir com essa classe, e aqui vou mostrar apenas uma. Por isso é sempre bom dar uma olhada na documentção completa depois.
Primeiro crie uma função que irá criar as suas regras e associe ela a um hook. Neste primeiro exemplo, vamos criar uma página de listagem para um custom post type.
1 2 3 4 5 6 7 8 9 10 11 |
function cria_minhas_regras$wp_rewrite $new_rules = array "livros$" => 'index.php?meu_template=livros', ; $wp_rewrite->rules = $new_rules + $wp_rewrite->rules; add_action'generate_rewrite_rules', 'cria_minhas_regras'; |
No código acima estou criando uma regra que diz que sempre que minha URL for meusite/livros, ele será direcionado para o index.php com uma variável meu_template setada com o valor livros. Note que este é o index.php da raíz do WordPress, e não do tema ativo.
As regras são definidas usando uma expressão regular. Se você não conhece expressões regulares, vá atrás pois são muito úteis. Vamos montar algumas regras mais complexas aqui só para termos de exemplo:
1 2 3 4 5 6 7 |
function cria_minhas_regras$wp_rewrite $new_rules = array "livros$" => 'index.php?meu_template=livros', "livros/autor/([^/]+)$" => 'index.php?meu_template=livros&autor=' . $wp_rewrite->preg_index1, ; $wp_rewrite->rules = $new_rules + $wp_rewrite->rules; |
Agora adicionamos uma regra nova. Se a URL vier meusite/livros/autor/qualquercoisa, o WordPress vai criar uma variável chamada autor e colocar essa qualquercoisa como seu valor.
Note que é preciso saber alguma coisa de expressões regulares, pois elas são a base da construção das regras. Explicar expressões regulares nesse artigo o deixaria muito extenso. Por isso, apenas para constar, vale dizer que essa expressão regular entre parênteses quer dizer: um grupo de um ou mais caracteres que não tenha o caractere /. Os parênteses servem para capturar e depois serem acessados pelo método preg_index() ali na frente. Se houver mais de uma captura na mesma expressão, basta ir passando os valores 2, 3, etc para este método.
Seguindo adiante, precisamos registrar essas variáveis que criamos nas variáveis públicas da classe WP_Query, para que possamos acessá-las através da função get_query_var().
1 2 3 4 5 6 7 |
function registrar_query_vars$public_query_vars $public_query_vars = "meu_template"; $public_query_vars = "autor"; return $public_query_vars; add_filter'query_vars', 'registrar_query_vars'; |
Pronto. Agora você pode acessar esses valores no seu código, usando, por exemplo:
1 |
$meu_template = get_query_var'meu_template'; |
Em alguns casos, isso já vai ser suficiente, pois tudo o que você precisa é pegar algumas variáveis e aí no próprio arquivo functions do seu tema você se resolve. Mas você pode fazer também um redirecionamento para forçar o WordPress a usar um arquivo de template diferente do seu tema, que esteja fora da hierarquia do WordPress. Para isso, faça o seguinte:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
function template_redirect_intercept global $wp_query; // verifica a variável if $wp_query->get'meu_template' == 'livros' // se tiver o valor que queremos, usa o nosso template if file_exists TEMPLATEPATH . '/tpl_livros.php' include TEMPLATEPATH . '/tpl_livros.php' ; exit; add_action'template_redirect', 'template_redirect_intercept'; |
E é isso. Agora crie o arquivo tpl_livros.php no seu tema e seja feliz.
Nota importantíssima: o hook generate_rewrite_rules onde colocamos nossa função para criar as novas regras é chamado quando você salva as configurações de Links Permanentes. É preciso que seus links permanentes estejam configurados para alguma coisa diferente da padrão e o módulo rewrite do apache esteja funcionando corretamente, com o arquivo .htaccess criado.
Nota importantíssima 2: Cada vez que você mudar alguma coisa no código das suas regras, é preciso salvar novamente a configuração de Links Permanentes para atualizar as regras. Isso acontece porque o WordPress guarda essas regras no banco, e não adianta simplesmente gerá-las dinamicamente no código. Você pode contornar isso, chamando na mão a função $wp_rewrite->flush_rules(), mas não é uma boa idéia chamar essa função toda vez que o site é carregado, pois ela é meio pesada.
Rewrite Rules rules!
Pois então você já tem seu site com WordPress instalado, mas você de fato quer montar é uma rede social. Isto é: um local onde os (futuros) membros de sua comunidade possam interagir de forma mais organizada e agradável.
Não apenas com posts e comentários, mas com grupos de discussão, fóruns e onde todos ainda utilizem o recurso de mensagens privadas. Hummm algo como o Facebook ou o Orkut. Mas não será muito complicado construir algo assim?, pensa você. Fique tranquilo: BuddyPress é exatamente aquilo que você está procurando, e sua instalação é muito simples.
De fato originalmente só era possível usar o BuddyPress em instalações com WordPress MU. De algum tempo para cá não mais! 
Mas vamos deixar o blá-blá-blá e ir direto ao que interessa: aos vídeos. O pré-requisito é ter o WordPress já instalado, com a estrutura de links permanentes já atualizada. Somente. Vamos lá:
Instalando BuddyPress Parte 1 por joao barroca em Vimeo.
Que tal colocar seu BuddyPress em português? E instalar seu fórum? Vamos lá
Instalando BuddyPress Parte 2 por joao barroca em Vimeo.
Traduzindo para o português, instalando fórum e outras configurações
* os vídeos tem resolução HD. Amplie (clicando nas setinhas) para assistir com essa resolução
A grande maioria dos sites com BuddyPress acaba por optar por colocar o fluxo de atividades como página principal. Mas você pode construir outra página e configurar seu site para exibi-la. Mas não esqueça de apontar que página vai conter seus posts sim você continua no WordPress! . Observe que a imagem abaixo mostra que, para o exemplo, crei uma página [Posts: Blogs] e fiz os ajustes nas configurações de leitura.
Abraços e Boa Sorte
O Hugo Cisneiros acabou de publicar um tutorial sobre a utilização de Proxy no WordPress e PHP. Segundo ele:
Todo mundo conhece o tal Proxy. Quer queira quer não, na maioria das vezes as empresas utilizam um proxy como intermediador entre seus usuários e a Internet em geral. Enquanto o firewall bloqueia todo o acesso externo, deixa apenas essa brecha para os clientes conectarem no Proxy, então este controla tudo o que entra e sai pela Web.
Continue lendo o tutorial no site do Hugo, o Devin.
O Hugo Cisneiros escreveu há alguns dias um tutorial para quem precisa usar o WordPress com mais de um banco de dados. Segundo ele:
Houve um certo trabalho em que participei, onde foi necessário instalar um WordPress-MU de alta disponibilidade, que utilizava além de dois servidores Web, dois servidores de banco de dados. Neste cenário, os arquivos do servidor Web estavam sempre replicados nas duas máquinas, e os bancos de dados também tinham seus dados sempre nas duas máquinas. Com os dados sempre replicados em várias máquinas, tivemos que customizar o WordPress para entender isso.
Continue lendo o tutorial no site do Hugo, o Devin.
O primeiro passo é o básico: procurar um bom serviço de hospedagem, recomendamos um servidor Linux, com php5 e versões novas do MySQL (os requisitos mínimos são php 4.3 e MySql 4.0). O que você vai ver nos vídeos a seguir foi feito em um servidor com o software chamado cPanel (software de gerenciamento de contas). Não é essencial, mas facilitará muito sua vida. O importante é que você tenha acesso suficiente para criar seu banco de dados e seu usuário, alterar os privilégios do usuário e, se possível, ao phpMyadmin.
Bom, você já tem tudo isso e seu espaço lá no servidor está vazio, pronto para começar. Neste primeiro vídeo, procuramos nos colocar na mesma situação que você: tem o domínio e tem os acessos. O que fazer agora? Então, assista ao vídeo:
Então vamos à segunda parte da instalação. Para começar e como já vi esse erro inúmeras vezes voltamos a falar da criação de senha para usuários de banco de dados. O melhor é deixar o sistema gerar uma senha beeeeem complicada e utilizá-la. Salve a senha no seu computador não na web em um arquivo a que somente você tenha acesso. Na sequência, mostramos:
Você está prestes a terminar. Neste terceiro e mais curto vídeo encerramos a instalação propriamente dita.
Vamos ao vídeo:
No futuro, alguns outros vídeos de como operar nosso já instalado WordPress.
*Deixe seu comentário para que possamos melhorar os vídeos ok?
Com a chegada do WordPress 2.7, a plataforma mostrou algumas boas novidades. Como todo mundo já deve saber disso, dispensarei grandes apresentações. Bem, dentre tais novidades, a que chamou bastante atenção foi a chamada sticky posts/posts fixos, que nada mais são do que posts que você pode manter fixos na página inicial e, principalmente, no topo do seu blog/site, se assim quiser. Ainda acho que a funcionalidade é muito básica, mas tais considerações eu deixo para um próximo texto. Por enquanto, a idéia é tentar detalhar um pouco as vantagens que a interessante novidade (não mais tão novidade, mas tudo bem) pode trazer para o seu site.
Basta você criar um novo post ou editar um antigo e marcar a opção Fixar este post na página inicial no painel Publicar e pronto, seu post será o primeiro da lista. Caso deseje usar a funcionalidade para mais de um post, sem problemas. O WordPress jogará todos os posts marcados como sticky/fixo pro topo do seu site. Só atenção: a ordem dos posts respeitará a ordem que foi usada para marcá-los. O último post fixado vai ser sempre o primeiro da fila, independente da data dos outros. E que fique claro, os posts continuam na ordem cronológica. Se você desmarcar a opção de fixar o post, ele simplesmente não aparecerá mais no topo das postagens.
Como a Cátia já escreveu em seu texto sobre o post_class(), o WordPress agora cria, através dessa função, várias classes para o post. E claro, era de se esperar que uma classe sticky fosse atribuída caso o post estivesse marcado assim. A minha estrutura ficou assim:
[sourcecode language="html"]
Agora, é só declarar a classe sticky no seu arquivo CSS e estilizá-la como bem entender.
Sendo redundante, a função is_sticky(), se usada dentro do The Loop, vai retornar verdadeiro caso o post tenha sido marcado como sticky. É, simples assim.
[sourcecode language="php"][/sourcecode]
Caso você precise saber se tal post é um sticky, basta colocar a ID do post desejado como parâmetro da função:
[sourcecode language="php"][/sourcecode]
Provavelmente você não vai querer que os posts fiquem fixos em todas as áreas do seu site, principalmente se você executa várias queries dentro do mesmo arquivo. Para ignorar os sticky posts e mantê-los na ordem cronológica, faça uso do parâmetro caller_get_posts=1 dentro da query:
[sourcecode language="php"][/sourcecode]
Não há muito o que explicar. Caso você não queira que a sua query mostre os posts marcados como sticky, faça:
[sourcecode language="php"]
$sticky)); ?>[/sourcecode]
Agora, se a idéia e mostrar apenas aqueles posts marcados, use o parâmetro post__in:
[sourcecode language="php"]
$sticky)); ?>[/sourcecode]
Por padrão, o query_posts() traz todos os posts fixados para o topo. Se você quiser apenas um desses posts no topo, isso pode ser feito da seguinte maneira:
[sourcecode language="php"]
[/sourcecode]
Essa query é perfeita para blogs que possuam espaço para um post destaque. Porém, ela traz o primeiro post marcado como sticky (é, o primeiro de todos), o que não me parece uma solução muito interessante. Para que a query retorne o último post fixado, apenas adicione a função array_reverse() para que assim a primeira ocorrência seja, na verdade, o último sticky post.
[sourcecode language="php"]
[/sourcecode]
E é isso. Resumidamente, estão aí todos (ou quase todos) os principais detalhes sobre sticky posts. É bem possível que este artigo não tenha mostrado nenhuma novidade perto de outros já escritos, mas ei, é mais uma referência. E sugestões, claro, são mais do que apreciadas.
Ilustração por Cátia Kitahara
Muitas vezes, quando fazemos um tema ou um plugin, precisamos carregar folhas de estilo ou arquivos javascript adicionais. Neste post, vou mostrar a maneira mais legal, charmosa e elegante de se fazer isso.
Antes de mais nada, vamos criar a função que vai carregar nosso javascript e adicioná-la ao hook correto do WordPress:
[sourcecode language='php']
function meuPlugin_addJS() {
// aqui vou carregar meu javascript
}
add_action(wp_print_scripts, meuPlugin_addJS);
[/sourcecode]
Agora, sempre que o WordPress imprimir as chamadas a arquivos javascript, vai rodar a sua função. Vamos ver como isso vai funcionar.
A função wp_enqueue_script() serve para colocar o script em uma fila de carregamento. Ela é extremamente útil para evitar que um script seja carregado mais de uma vez e também para carregar todas as dependências na ordem certa. Vamos ver um exemplo que usa todos os parâmetros desta função:
[sourcecode language='php']
wp_enqueue_script(meu_script, http://meusite.com/wp-content/plugins/meuplugin/script.js, array(jquery), 1.0);
[/sourcecode]
Esta função está colocando o seu script na fila para ser carregado, dizendo o seguinte
Você só precisa passar tantos parâmetros quando se trata de um script que o WordPress não conhece. Para carregar o jQuery, por exemplo, você pode simplesmente especificar:
[sourcecode language='php']
wp_enqueue_script(jquery);
[/sourcecode]
Note que jquery é apenas um nome fantasia para o script. Para saber quais são todos os scripts disponíveis por padrão no WordPress, dê uma olhada na documentação completa da função wp_enqueue_script().
Para encerrar este post, só falta esclarecer um ponto: não é bonito colocar o caminho para seu arquivo assim na mão, como fizemos no exemplo acima. Isso pode trazer vários problemas, porque, a partir do WordPress 2.6, é possível trocar o diretório wp-content de lugar. Seu plugin ou tema não vai funcionar corretamente em uma instalação em que alguém tenha movido este diretório. Além disso, não é raro as pessoas trocarem o nome da pasta do plugin, o que também quebraria o seu esquema.
Para contornar esse problema e deixar o seu código universal, vamos usar a constante WP_CONTENT_URL, que guarda o caminho da pasta wp-content, onde quer que ela esteja.
Vamos ver como ficaria nosso script completo:
[sourcecode language='php']
function meuPlugin_addJS() {
$meuPluginURL = WP_CONTENT_URL./plugins/.plugin_basename( dirname(__FILE__))./';
wp_enqueue_script(meuJs, $meuPluginURL . meuJS.js);
}
add_action(wp_print_scripts, meuPlugin_addJS);
[/sourcecode]
Note que, se meu plugin não depende de ninguém, não preciso passar os dois últimos parâmetros.
Importante: A constante WP_CONTENT_URL só foi introduzida no WordPress 2.6, portanto, se você quiser que seu plugin ou tema funcione em versões anteriores a esta, adicione uma linha para criar a constante, caso ainda não exista:
[sourcecode language='php']
if ( !defined(WP_CONTENT_URL) )
define( WP_CONTENT_URL, get_option(siteurl) . /wp-content);
[/sourcecode]
Nos temas, você pode fazer assim:
[sourcecode language='php']
// para garantir compatibilidade com versões anteriores ao WordPress 2.6
if ( !defined(WP_CONTENT_URL) )
define( WP_CONTENT_URL, get_option(siteurl) . /wp-content);
function meuTema_addJS() {
wp_enqueue_script(meuJs, WP_CONTENT_URL./themes/meuTema/ . meuJS.js);
}
function meuTema_addCSS() {
echo
;
}
add_action(wp_print_scripts, meuPlugin_addJS);
add_action(wp_head, meuTema_addCSS);
[/sourcecode]
Seu próximo passo é garantir que esses arquivos externos sejam carregados apenas quando realmente forem usados, para não sobrecarregar o site à toa. Existem várias maneiras de fazer isso, usando hooks específicos ou condições, mas é tema para outro post.
Abraços,
Leo