Mateus Neves, graduado em Produção Digital é web designer, designer gráfico, Wordpress theme developer e preletor. Aplica Workshops sobre Wordpress para web designers e interessados na ferramenta. Hoje é lider da equipe de desenvolvimento da empresa Quartel Design.
Em um projeto em que eu trabalhava, eu precisava de alguma forma de mais dados relacionados com a Categoria, eu já conhecia um plugin que inseria um campo de imagem nas categorias, mas acabei encontrando o plugin , que é simplesmente muito melhor, é claro que acho que ele ainda tem que ser mais aperfeiçoado em alguns itens, mas ele já funciona perfeitamente.
Com o você pode adicionar campos do tipo, imagem, textarea, text e checkbox, que vão ser integrados no cadastro das categorias de também de custom taxonomys.
Depois de instalar o plugin, no painel do WordPress em Configurações clique no item Catetory Meta e crie seus campos personalizados para suas categorias. Depois para exibir os valores dos campos customizados da categoria use com nos exemplos abaixo.
if (function_exists('get_terms_meta'))
{
$metaValue = get_terms_meta($category_id, 'nome-do-campo-personalizado');
echo $metaValue[0];
}
Para pegar todos os valores dos campos personalizados use o exemplo abaixo.
if (function_exists('get_all_terms_meta'))
{
$metaList = get_all_terms_meta($category_id);
}
A função get_terms_meta() e get_all_terms_meta() retorna uma Array com os valores dos campos personalizados. No caso da função get_all_terms_meta() você pode usar a função do php para visualizar as posições de cada campo na Array para poder exibir da forma que quiser depois pode retirar a chamada da função .
VoicePress, é um novo plugin que veio para revolucionar ainda mais o uso do CMS WordPress.
Com o VoicePress você não escreve mais os seus post você fala e o VoicePress escreve para você. Sim é isto mesmo ele escreve para você, a acessibilidade que isto vai trazer para pessoas por exemplo com dificuldades motoras vai ser revolucionario dentro do próprio WordPress.
O plugin ainda esta na sua faze beta e por enquanto só funciona usando o navegador Google Chrome, se quiser fazer um download acesse site e use a chave VP-WP-DEV para poder fazer o download da versão beta.
Eu fiz o teste e para uma versão beta esta muito bom, na tela de cadastro do seu post ou page ele adiciona um icone de um microfone onde é só clicar e começar a falar.
Com a chegada do WordPress 3, ganhamos a fantástica funcionalidade dos Custom Post Types que aumentou ainda mais o poder do CMS WordPress. Para quem ainda não conhece os Custom Post Types permite que possamos criar novos paineis de gerenciamento de conteúdo no WordPress, além dos nativos do sistema que são os Posts e as Pages. Com os Custom Posts Type podemos por exemplo criar um painel de cadastro de produtos com cadastro de título, descrição, preço, peso e outros campos que você precisar.
Eu me acostumei a criar meus Custom Posts Types através das linhas de código e funções próprias do WordPress inseridas no arquivo function.php dos meus temas, se você fizer uma busca no Google vai achar vários tutoriais de como criar seu Custom Post Type na unha.
Hoje precisei criar um Custom Post Type, mas como eu estava com pressa, resolvi procurar um plugin que facilitasse isso, eu já havia encontrado alguns antes e testado mas nenhum era completo então nem valia a pena, isto até hoje quando encontrei o plugin , este me deixou de queixo caído.
O plugin é realmente fantástico, com uma interface simples de usar, você cria em instantes seus Custom Post Type com seus campos padrões e campos personalizados, com suporte a aplicar categorias para seu Custom Post Type ou tags. É simplesmente fantástico.
Segue abaixo alguns vídeos de demonstração, criado pelos autores do plugin. Um obrigado especial aos autores deste plugin!
Criando um novo Custom Post Type
Adicionando campos personalizados ao seu novo Custom Post Type
Grandes notícias, hoje saiu a versão beta 1 para download do WordPress 3.2, uma versão com grandes novidades. Segue a baixo algumas destas grandes novidades.
Melhorias de desempenho como você nunca viu. O que isso significa? As coisas vão ficar mais rápidas!
Menos distração na escrita. Experiência em tela cheia. O editor visual teve uma grande reformulação, e agora está disponível no modo HTML também. Mais do que nunca, o WordPress permite que você se concentre no que mais importa – o seu conteúdo.
Atualização da interface do usuário Admin. A última grande reformulação do WordPress foi em 2008. Esta não é uma grande remodelação, foram feitas algumas modificações para nos sentirmos mais jovens. WordPress vai fazer 8 anos neste mês se você não sabe.
Novo tema padrão. Apresentando Twenty Eleven, com base no popular tema Duster. Com imagens de cabeçalho, formato de postal, e muito mais.
Procure feliz. WordPress é feito para trabalhar com navegadores modernos. Se você visitar o seu Painel usando um navegador desatualizado, vamos deixar você saber que há uma nova versão disponível para o seu navegador.
Barra de Admin. Nós adicionamos mais links na barra de administração para torná-la ainda mais útil.
WordPress tem novos requisitos do sistema: PHP 5.2.4 e MySQL 5.0.
E agora uma das notícias que me deixou mais orgulhoso ainda do WordPress:
O WordPress não vai ter mais suporte para o Internet Explorer 6
Sempre fiz muito uso da função query_posts() para realizar novas solicitações de conteúdo customizadas e algumas vezes usando o objeto WP_Query(), mas pelo costume e comodismo sempre usei mais a função query_posts() para gerar as query’s que eu queria em temas de WordPress e pelo que já vi de outros desenvolvedores é de costume usar a função query_posts().
Bom, se os dois modos usando query_posts() ou o objeto WP_Query resovem nossas questões, porque existem duas maneiras. Fiz uma pesquisa pelo WordPress Codex e outros sites de desenvolvedores WordPress para saber a diferença destes dois modos de criar querys que são as solicitações que fazemos ao banco de dados do WordPress para nos retornar o conteúdo que queremos exibir.
query_posts()
A primeira e importante informação sobre a função query_posts() em que encontrei na sua descrição no site do WordPress Codex é: “A função query_posts é destinada a alterar a query principal do loop. Para a criação de query’s secundárias, você deve fazer uma nova instância do objeto WP_Query”. Isto quer dizer que, a função query_posts() não foi feita para criar várias querys dentro de um arquivo de template, a função dela é de ser usada uma vez somente em um arquivo de template quando você quer alterar a query padrão de um loop do WordPress onde ele realiza através dos parâmetros vindos da URL da página.
Um exemplo simples e prático é um loop simples de uma página principal de um blog onde o WordPress irá listar todos os posts de todas categorias do blog, paginados pelo número definido no painel do WordPress em Configurações > Leitura, que normalmente são de 10 posts por página.
O loop deste template seria como o exemplo abaixo.
Agora em que caso usaríamos a função query_posts() neste template? Vamos supor que na minha página principal eu não quero que sejam exibidos os posts da categoria de ID=5. É neste caso que faríamos o uso correto da função query_posts(). Nosso código ficaria assim:
Dica: se você quiser preservar a query principal em que o WordPress gera através dos parâmetros vindo da URL e adicionar mais alguns parâmetros extras na query principal utilize como no exemplo abaixo:
Você pode se perguntar, como eu me perguntei também: mas qual o porquê de ter que usar a função query_posts() somente uma vez em meu arquivo de template para alterar o loop principal se já usei várias vezes para poder criar mais de uma query em meus templates?
Resposta: Primeiro se o próprio site do WordPress Codex diz e recomenda que esta função seja usada apenas uma vez em por arquivo de template quando se quer mudar o loop principal, já é um bom argumento, mas mesmo assim não basta veja alguns dos argumentos que encontrei e que realmente me lembraram de experiências causadas pelo mau uso da função query_posts().
Segue alguns dos argumentos para que a função query_posts() seja usada da forma correta:
“Ela define uma série de variáveis globais e por isso pode levar a erros obscuros e horríveis se usada em qualquer outro lugar e para qualquer outra finalidade”
“O uso de query_posts () em um loop que não seja o principal pode causar um resultado incorreto no seu ciclo e possivelmente exibir coisas que você não estava esperando.”
A grande diferença então entre a função query_posts() e o objeto WP_Query() é essa, a função query_posts() deve ser usada somente para alterar a query do loop principal e se o seu template necessitar de outras querys para exibir conteúdos diferentes em outros loops você deve criar uma nova instância do objeto WP_Query() para criar suas querys secundárias.
WP_Query()
Vamos falar agora o objeto WP_Query().
O WordPress Codex define o WP_Query() da seguinte maneira: “Para a criação de loops secundários, você deve fazer uma nova instância da WP_Query e usar em outros loops”
Segue abaixo um exemplo do uso da WP_Query() para se criar um loop secundário em um arquivo de template de um tema de WordPress.
Segue alguns argumentos sobre o uso correto do objeto WP_query:
“Para a criação de loops secundários, você deve fazer uma nova instância da WP_Query e usar neste loop: A razão importante disto é que você não acabe de alguma forma alterando ou interferindo com o loop principal utilizado nessa página”
“Um pouco mais complexa, mas com menos restrições e também seguro de usar em qualquer lugar.”
A WP_Query() não afeta de nenhuma maneira a query principal, por isso foi feita para ser usada na criação de query’s secundárias dentro de um mesmo documento.
Importante: Trabalhe sempre com uma instância do objeto WP_Query() para criar suas query’s secundárias, para que não fiquem várias query’s abertas com o banco de dados, que pode prejudicar a performance do site.
Uma das maneiras muito usadas que não é a correta e melhor prática de se usar quando se quer usar a função query_posts() mais de uma vez em um mesmo documento é de usar a função wp_reset_query() que limpa a query anterior retornando com a original, eu já fiz isso várias vezes. Mas como em qualquer outra ferramenta cada objeto tem sua função específica e o melhor e mais seguro é usar cada objeto para sua finalidade real. Isto vai sempre tornar seu projeto final mais consistente e seguro.
Então vamos deixar o comodismo de lado e fazer bom uso das melhores práticas no desenvolvimento com o WordPress e vamos continuar sempre buscando as melhores práticas.