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.
Neste mesmo post, ela também fala sobre a integração do WordPress MU ao WordPress:
Foi anunciado no WordCamp San Francisco, no ano passado que o WordPress e o WordPress MU iriam unificar seus códigos. Isto já aconteceu no 3.0-alpha, e nós estamos trabalhando na correção de bugs e limpando alguma telas. Se você estiver usando uma instalação única do WordPress, quando você atualizar para o 3.0 você não verá nenhuma das novas telas associadas à manutenção de uma rede de sites. Se você estiver usando o MU, quando você atualizar, você notará alguns rótulos mudando, mas a atualização deverá ser tão indolor quanto sempre foi. Se você for configurar uma nova instalação do WordPress, como parte do processo, será solicitado que você escolha um ou múltiplos sites, bastante simples. Se você quiser tornar uma instalação de um único site em uma que suporta múltiplos sites, você terá uma ferramenta que fará isso para você também. Portanto, se você estava preocupado com a unificação, tome uma chícara de chá de camomila e relaxe, tudo ficará bem.
(tradução do autor)
Ela ainda anunciou a data de feature freeze para o 3.0, ou seja, a data a partir da qual os esforços estarão concentrados em testes e correções de bugs e nenhum novo patch será acrescentado. Esta data será dia 1º de março, segunda-feira. Ela solicita aos desenvolvedores que ajudem, pois temos apenas uma semana para que os patches e tickets programados sejam feitos.
]]>