web-dev-qa-db-fra.com

get_template_part vs crochets d'action dans les thèmes

Il me semble que ces deux possibilités offrent la possibilité à l'utilisateur final de modifier un thème sans éditer réellement les fichiers de thèmes (via des thèmes enfants).

Ma question est, est une méthode préférée sur l'autre.

Par exemple, prenez un thème sur lequel je travaille actuellement. Je suis en train de décider si aller avec des parties de modèle de crochets.

<?php get_template_part('before_sitecontainer' ); ?>
<div id="sitecontainer" class="sitecontainer" <?php //closed in footer ?>>

<?php get_template_part( 'before_topcontainer' ); ?>
<div id="topcontainer ">

    <?php get_template_part( 'before_topedge_navigation' ); ?>
    <?php get_template_part( 'topedge_navigation' ); ?>

    <?php get_template_part( 'before_site_header' ); ?>
    <?php get_template_part( 'site_header' ); ?>

    <?php get_template_part( 'before_second_navigation' ); ?>
    <?php get_template_part( 'second_navigation' ); ?>

    <?php get_template_part( 'after_second_navigation' ); ?>

</div><!-- end topcontainer div -->
<?php get_template_part( 'after_topcontainer' ); ?>

Ce qui précède permet à l’utilisateur du thème de remplacer n’importe quelle section de code existant en créant simplement un fichier bien nommé dans son dossier de thème enfant, ainsi qu’en ajoutant un nouveau code avant/après chaque section existante selon la même méthode - le modèle avant/après. les fichiers de partie n'existent pas du tout dans le thème parent et sont simplement là pour leur permettre d'insérer du code - et cette méthode n'exige pas qu'ils comprennent les points d'ancrage/filtres pour accomplir cela.

Bien sûr, je pourrais réaliser la même chose en utilisant des crochets et des filtres.

Y a-t-il un avantage à utiliser des crochets/filtres à la place? Garder à l'esprit que le public cible qui l'utilisera est clairement averti du code pas . Je peux leur donner des instructions relativement élémentaires à suivre pour utiliser la méthode du modèle, mais je vais certainement confondre le diable avec des crochets.

Ou existe-t-il des situations où l’un serait meilleur que l’autre dans le même thème?

theme-developmenthooksthemesactionsget-template-part
14
Ashley G

Je préfère les hooks, car ils sont plus flexibles: vous pouvez les accrocher à partir du fichier functions.php de votre thème, mais aussi à partir de plugins. J'essaie de mettre autant de logique dans les plugins, afin que les thèmes contiennent principalement des éléments de mise en page.

Si vous utilisez un hook d’action, il est toujours possible d’utiliser get_template_part() dans ce gestionnaire de hook . Cela vous donne le meilleur des deux mondes. Vous pouvez probablement même créer un hook par défaut qui appelle get_template_part(), de sorte que les personnes peu expérimentées en codage puissent ajouter des fichiers supplémentaires, tandis que d'autres peuvent supprimer ce hook s'ils ne le souhaitent pas.

En ce qui concerne les performances: get_template_part() utilise ( dans locate_template() ) file_exists() une, deux ou quatre fois (selon la façon dont vous l'appelez). Il semble que file_exists() est très rapide , et utilise la mise en cache dans PHP et peut-être même dans le système d'exploitation. Donc, ce n'est probablement pas un problème.

8
Jan Fabry

Je dirais que la principale différence est la lisibilité. Si vous voyez plusieurs parties de modèle bien nommées, vous pouvez facilement comprendre ce qui se passe. Si vous ne voyez qu'un crochet, vous devrez chercher dans le reste du thème pour déterminer ce qui est attaché au crochet.

4
Mild Fuzz

Il est (relativement) facile de supprimer une fonction du crochet dans le thème enfant, mais beaucoup plus difficile de le faire ignorer le modèle parent non désiré.

Essentiellement, travailler avec des hooks est plus proche du côté PHP et travailler avec des modèles est plus proche du côté HTML. J'utilise le thème parent hybride, qui est très orienté crochet. C'est un bonheur jusqu'à ce que vous ayez besoin de vous débarrasser du modèle d'un parent.

Pour les utilisateurs qui ne sont pas férus de technologie, l'option n'est pas très agréable. Pourquoi auraient-ils besoin de jouer avec de tels thèmes internes de toute façon?

PS note également des problèmes de performance. Les trucs avec des crochets se passent en mémoire, les trucs avec des modèles nécessitent de nombreuses recherches de disque. Surtout si vous écrivez quelque chose comme dans votre exemple.

PPS n'est pas la préférence de tout le monde ... mais au lieu d'écrire le thème parent à partir de rien, pourquoi ne pas utiliser le thème parent existant et fournir un thème enfant simple à l'utilisateur?

4
Rarst