Lorsque j’ai commencé à penser aux modèles dans WordPress, j’ai pensé à deux aspects :
- contenu spécifiquement pour les membres ,
- contenu qui pourrait se décomposer en un seul message.
Mais plus j’y pensais, plus je réalisais que cela pouvait (et devrait sans doute) être expliqué au cours de quelques articles.
Je vais donc décomposer l’état actuel des modèles WordPress et ensuite les moyens pratiques que nous pouvons prendre pour organiser, disons, nos plugins afin que nous utilisions PHP standard.
Après cela, dans une prochaine série, j’examinerai ce que cela signifie d’utiliser d’autres moteurs de templates (à la fois PHP et JavaScript dans le travail que nous faisons).
Pour commencer, cependant, je veux voir comment nous voyons souvent des modèles écrits dans le contexte des thèmes et des plugins WordPress.
Modèles WordPress pour les débutants
En fonction de votre expérience avec WordPress et d’autres systèmes basés sur PHP, votre définition des modèles sera différente de celle de quelqu’un d’autre.
Donc, pour essayer de créer une définition commune que j’utiliserai tout au long de cette série d’articles, je vais utiliser le WordPress Codex :
Les modèles sont les fichiers qui contrôlent la façon dont votre site WordPress sera affiché sur le Web.
La page poursuit en expliquant comment cela fonctionne en conjonction avec la base de données et d’autres actifs, et je vous recommande de lire à ce sujet si vous ne la connaissez pas.
Cependant, la définition ci-dessus fonctionne bien pour la façon dont je prévois d’aller de l’avant en y réfléchissant.
1 Comment c’est (en ce moment)
Quand il s’agit de penser aux modèles WordPress, je pense qu’il est utile de considérer un seul modèle avec un code qui ressemble à ceci :
<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 -->Le point du code ci-dessus est que vous voyez, c’est qu’il mélange PHP et HTML.
De plus, il est important de noter que chacun de ces fichiers est stylisé à l’aide de CSS et peut avoir un comportement supplémentaire contrôlé via JavaScript. À cette fin, vous pouvez le conceptualiser comme ceci :
Cela représente un modèle unique mélangeant à la fois HTML et PHP dans un seul modèle. Et ce modèle est ensuite stylisé avec CSS et contrôlé avec JavaScript.
Tous ces éléments fonctionnent ensemble pour fournir ce que l’utilisateur voit.
2 L’organisation de développeurs engendre-t-elle des performances ?
Mais la façon dont cela fonctionne est un peu désordonnée, et bien que cela puisse sembler bon pour l’utilisateur, cela soulève quelques questions :
- Est-il aussi performant qu’il pourrait l’être ?
- Est-ce facile à maintenir pour un développeur ?
- Quel est le processus de construction ?
- comment les actifs sont-ils entretenus et organisés ?
Bien sûr, la plupart de ce que vous lisez ci-dessus est très centré sur le développeur, mais je trouve que lorsqu’un code est organisé de telle manière qu’il est facile pour les développeurs de travailler avec, il peut souvent être facile encore plus rapide pour l’utilisateur.
Qu’est-ce que cela signifie, cependant?
- Présentons-nous Sass ?
- Minifions-nous JavaScript ?
- Comment combiner ces actifs et les importer ?
- Qu’en est-il des requêtes PHP personnalisées qui se produisent dans le contexte de chaque modèle ?
Et bien que les premières choses soient importantes et en valent la peine (et que je couvrirai peut-être une série après cela), séparer la logique d’un modèle, même sans moteur de modèles, peut aider à rendre le code plus centré sur le développeur.
Est-ce que cela rend les choses plus rapides pour l’utilisateur ? Pas nécessairement. Mais cela nous aide à faire le premier pas pour y parvenir.
Réorganisons-nous
Dans le prochain article de cette série, je décomposerai le contenu que nous avons l’habitude de voir dans les modèles WordPress à travers un exemple et commencerai à le réorganiser afin qu’il soit mieux organisé de manière à ce que les techniques puissent être utilisées dans différents projets.
Cela signifie déplacer les choses dans leurs fonctions (ou même dans leurs classes et donc leurs fonctions) et comment nous pouvons les appeler depuis le contexte de nos modèles.
En fin de compte, cela conduira à un code plus facile à lire, à une meilleure séparation des préoccupations et nous amènera vers des moyens de changer la façon dont les données sont injectées dans un modèle.