Quando comecei a pensar em templates no WordPress, pensei em dois aspectos:
- conteúdo especificamente para membros ,
- conteúdo que pode ser dividido em um único post.
Mas quanto mais eu pensava sobre isso, mais percebia que poderia (e provavelmente deveria) ser explicado ao longo de alguns posts.
Então, vou detalhar o estado atual dos modelos do WordPress e, em seguida, maneiras práticas de organizar, digamos, nossos plugins para que usemos PHP padrão.
Depois disso, em uma série futura, examinarei o que significa usar outros mecanismos de modelagem (PHP e JavaScript no trabalho que fazemos).
Para começar, porém, quero dar uma olhada em como muitas vezes vemos modelos escritos no contexto de temas e plugins do WordPress.
Modelos WordPress para Iniciantes
Dependendo da sua experiência com o WordPress e outros sistemas baseados em PHP, sua definição de template será diferente da de outra pessoa.
Então para tentar criar uma definição comum que estarei utilizando ao longo desta série de posts será utilizado o WordPress Codex:
Modelos são os arquivos que controlam como seu site WordPress será exibido na Web.
A página continua falando sobre como ele funciona em conjunto com o banco de dados e outros ativos, e recomendo ler sobre isso se você não estiver familiarizado com ele.
No entanto, a definição acima funciona bem para como pretendo avançar pensando nisso.
1 Como é (agora)
Quando se trata de pensar em modelos do WordPress, acho que ajuda considerar um único modelo com código parecido com este:
<div id="content-container">
<p>
Oh! The garbage chute was a really wonderful idea. What an incredible smell you've discovered! Let's get out of here!
Get away from there... No! wait! Will you forget it? I already tried it. It's magnetically sealed! Put that
thing away! You're going to get us all killed.
</p>
<h2>List of Post Titles For Acme Post Type</h2>
<?php
$args = array(
'post_status' => 'publish',
'post_type' => 'acme',
'posts_per_page' => '10'
);
$custom_query = new WP_Query( $args );
if ($custom_query->have_posts()) {
echo '<ul>';
while ($custom_query->have_posts()) {
$custom_query->the_post();
echo '<li>'. get_the_title(). '</li>';
}
echo '</ul>';
wp_reset_postdata();
}
?>
<p>
Absolutely, Your Worship. Look, I had everything under control until you led us down here. You know, it's not
going to take them long to figure out what happened to us. It could be worst... It's worst.
There's something alive in here! That's your imagination. Something just moves past my leg!
Look! Did you see that? What? Help!
</p>
</div><!-- #content-container -->O ponto do código acima é que você vê é que ele mistura PHP e HTML.
Além disso, é importante observar que cada um desses arquivos é estilizado usando CSS e pode ter um comportamento adicional controlado por JavaScript. Para isso, você pode conceituar assim:
Isso representa um único modelo misturando HTML e PHP em um único modelo. E esse modelo é então estilizado com CSS e controlado com JavaScript.
Tudo isso funciona em conjunto para fornecer o que o usuário vê.
2 A organização do desenvolvedor gera desempenho?
Mas o modo como isso funciona é meio confuso e, embora possa parecer bom para o usuário, levanta algumas questões:
- É tão performático quanto poderia ser?
- Quão fácil é para um desenvolvedor manter?
- Qual é o processo de construção?
- como os ativos são mantidos e organizados?
Claro, a maior parte do que você está lendo acima é muito centrada no desenvolvedor, mas acho que quando um código é organizado de tal forma que é fácil para os desenvolvedores trabalharem com ele, muitas vezes pode ser ainda mais rápido para o usuário.
O que isso significa, no entanto?
- Apresentamos Sass?
- Minimizamos o JavaScript?
- Como combinamos esses ativos e os importamos?
- E as consultas PHP personalizadas que acontecem no contexto de cada modelo?
E embora as primeiras coisas sejam importantes e valham a pena (e eu posso cobrir em uma série depois disso), separar a lógica de dentro de um modelo, mesmo sem um mecanismo de modelagem, pode ajudar a tornar o código mais centrado no desenvolvedor.
Isso torna as coisas mais rápidas para o usuário? Não necessariamente. Mas isso nos ajuda a dar o primeiro passo para fazer exatamente isso.
Vamos nos reorganizar
No próximo post desta série, vou detalhar o conteúdo que estamos acostumados a ver nos templates do WordPress através de um exemplo e começar a reorganizá-lo para que fique melhor organizado de forma que as técnicas possam ser usadas em diferentes projetos.
Isso significa mover as coisas para suas funções (ou mesmo dentro de suas classes e, portanto, suas funções) e como podemos chamá-las de dentro do contexto de nossos modelos.
Em última análise, isso levará a um código mais fácil de ler, melhor separação de interesses e nos levará a maneiras de alterar a forma como os dados são injetados em um modelo.