Tout ce que vous devez savoir sur la fonction get_template_part() de WordPress

J'ai lu une fois que la meilleure façon d'apprendre la programmation est de lire le code que d'autres ont écrit. Après tout, la plupart du temps que vous passerez en tant que développeur sera probablement consacré à la révision, au polissage et à la correction du code que vous ou un autre développeur avez écrit dans le passé. C'est précisément pour cela que j'aime tant les logiciels libres et open source : ils nous donnent accès au code source d'excellents outils et permettent d'apprendre d'eux.

Si vous êtes intéressé par le monde WordPress (et j'imagine que vous l'êtes, car vous êtes ici), le code source de WordPress Core ou celui de Gutenberg sont deux très bons moyens pour devenir un meilleur professionnel de WordPress et s'initier au développement backend et frontend.

Depuis la première version de Gutenberg, nous partageons tout ce que nous avons appris sur le développement frontal jusqu'à présent. Ainsi, par exemple, on a fait une série de posts où on vous a appris les bases de React, on a vu comment réutiliser des composants, on a expliqué comment étendre Gutenberg, et on a discuté de l'actualité JavaScript pour écrire un meilleur code source, pour ne citer que quelques articles nous avons écrit.

Eh bien, aujourd'hui, nous allons changer de vitesse et nous concentrer à nouveau sur WordPress Core. Pourquoi? Je ne sais pas, peut-être parce que l'annonce du prochain thème Twenty Twenty-One qui est sorti il ​​y a quelques jours est l'excuse parfaite pour le faire ?. Parlons donc de l'un des éléments les plus importants lors de la création de thèmes dans WordPress : la fonction get_template_part .

Thèmes WordPress

Tout d'abord, passons en revue le fonctionnement des thèmes WordPress, voulez-vous ? Essentiellement, un thème est une collection de fichiers qui définit la structure HTML et les styles CSS que notre site utilisera.

Si vous pensez au squelette de n'importe quelle page Web, vous verrez que le même schéma se répète toujours :

• Nous commençons par ouvrir les balises html et head . C'est là que nous ajoutons des scripts, des styles, des balises méta, etc.
• Ensuite, nous fermons la balise head et ouvrons la balise body , qui contiendra le contenu visible de notre site Web.
  • Habituellement, le corps d'une page comprend un en-tête avec le logo du web, un menu, etc.
  • Vient ensuite le contenu lui-même, qui peut être une page, un article de blog, une liste de publications, le résultat d'une recherche, etc.
  • Enfin, il se termine généralement par un pied de page.
• Enfin, une fois que toute la page a été rendue, nous fermons toutes les balises et nous avons terminé.

Donc, oui, il semble que chaque page Web suit plus ou moins une structure similaire : il y a une partie commune (c'est-à-dire un en-tête, un menu, un pied de page...) et une zone spécifique au contenu (un article de blog, l'ensemble des résultats que nous avons obtenus après une recherche , un produit WooCommerce, etc.).

Comme les programmeurs n'aiment pas répéter le code et que nous sommes (en général) des gens organisés, les thèmes WordPress suivent une structure de fichiers très structurée. Dans ce post que j'ai écrit il y a quelques mois, vous avez une bonne explication des différents fichiers dans un thème, mais gardez à l'esprit qu'il y a :

• une feuille de style : style.css ,
• un fichier header.php pour "ouvrir" la page Web (c'est-à-dire sortir la balise head et, normalement, la partie initiale du body qui est commune à toutes les pages),
• un autre fichier footer.php qui "ferme" la page (c'est-à-dire qu'il ajoute le pied de page et ferme la balise html ), et
• beaucoup de fichiers supplémentaires pour les différents types de contenu que nous voulons rendre.

Qu'est-ce que la fonction get_template_part et à quoi sert-elle ?

La première chose à faire lorsque vous tombez sur une nouvelle fonctionnalité est l'inverse de ce que vous faites lorsque votre père vous demande de l'aider à programmer son nouveau robot Roomba : lire la documentation. Faisons donc cela avec notre fonction en regardant le Codex :

get_template_part fournit un mécanisme simple permettant aux thèmes enfants de surcharger des sections de code réutilisables dans le thème.

Inclut la partie de modèle nommée pour un thème ou si un nom est spécifié, une partie spécialisée sera incluse. Si le thème ne contient pas de fichier {slug}.php alors aucun modèle ne sera inclus.

Le modèle est inclus à l'aide de require, et non de require_once, vous pouvez donc inclure la même partie de modèle plusieurs fois.

Pour le paramètre $name, si le fichier s'appelle "{slug}-special.php" alors spécifiez "special".

Remarque : get_template_part() échoue silencieusement

documentation get_template_part sur WordPress.org

Voir? En moins d'une minute, nous avons obtenu toutes les informations dont nous avions besoin. Nous savons maintenant que cette fonction est utilisée pour créer des "parties réutilisables" dans un thème (évitant ainsi la duplication de code) et qu'elle le fait de manière à ce qu'un thème enfant puisse les adapter. Nous avons également des informations sur ses paramètres, son fonctionnement interne (il utilise la fonction require de PHP) et ce que nous pouvons en attendre (il "échoue en silence").

Malheureusement, certaines choses ne sont toujours pas claires, comme ces fichiers {slug}.php et {slug}-special.php qu'il mentionne. Que sont-ils? Que contiennent-ils ? Que font-ils? De nombreuses questions difficiles auxquelles il est difficile de répondre en ne consultant que la documentation, il est donc temps de passer aux exemples.

Comment créer des modèles partiels dans notre thème

Jetons un coup d'œil au thème Twenty Twenty-One pour savoir s'il utilise ces "modèles partiels" et, si c'est le cas, à quoi ils ressemblent et ce que vous devez faire pour les implémenter dans votre propre thème.

Si vous avez lu mon article sur la hiérarchie des fichiers d'un thème WordPress, vous saurez que « index.php est le template par défaut de notre thème. Il est utilisé pour afficher tout contenu sur notre site Web, tant que ledit contenu n'a pas de modèle spécifique conçu pour lui. Comme il s'agit d'un modèle par défaut, je pense que c'est une bonne idée de commencer par là. Voici le contenu de index.php dans le thème Twenty Twenty-One :

 get_header(); if ( have_posts() ) { // Load posts loop. while ( have_posts() ) { the_post(); get_template_part( 'template-parts/content/content' ); } // Previous/next page navigation. twenty_twenty_one_the_posts_navigation(); } else { // If no content, include the "No posts found" template. get_template_part( 'template-parts/content/content-none' ); } get_footer();

Comme vous pouvez le voir, nous avons toutes les parties que nous avions précédemment commentées :

• Il inclut l'en-tête à l'aide get_header .
• Il rend le contenu lui-même.
• Il ferme la page avec get_footer .

La chose intéressante ici, évidemment, est la zone "contenu" dans index.php . Concrètement, nous voyons que nous avons un petit contrôle pour savoir si nous voyons ou non un contenu valide ( fonction have_posts de la boucle WordPress) et, selon que nous en avons ou non, nous chargeons un modèle partiel ( …/content ) ou un autre ( …/content-none ).

Si nous examinons maintenant le modèle partial content.php , nous verrons à peu près ce qui suit :

 <article <?php post_class(); ?>> <header class="entry-header alignwide"> … the_title( … ); … </header> <div class="entry-content"> <?php the_content( … ); wp_link_pages( … ); ?> </div> <footer class="entry-footer default-max-width"> <?php twenty_twenty_one_entry_meta_footer(); ?> </footer> … </article>

Assez simple, n'est-ce pas? Tout ce que nous avons est un petit modèle conçu pour rendre le contenu WordPress générique comme, par exemple, un article de blog. Notez que le squelette HTML résultant n'est rien de plus qu'une balise d' article avec un titre, son contenu et un pied de page, tous utilisant des balises de modèle WordPress pour extraire le contenu réel.

Pourquoi l'API WordPress est géniale

Même si vous ne saviez pas que toutes ces fonctions existent ( get_header , get_footer , ou l'étoile d'aujourd'hui : get_template_part ), je suis presque sûr que vous auriez organisé votre code en suivant une approche similaire. Après tout, il semble assez logique de créer un modèle pour l'en-tête, un autre pour le pied de page, un autre pour le contenu… et puis d'avoir un fichier spécial ou quelque chose qui colle le tout, non ?

Si vous aviez suivi une telle approche, je parie que votre fichier index.php aurait ressemblé à ceci :

 require_once 'header.php'; if ( have_posts() ) { // Load posts loop. while ( have_posts() ) { the_post(); require 'template-parts/content.php'; } // Previous/next page navigation. twenty_twenty_one_the_posts_navigation(); } else { // If no content, include the "No posts found" template. require 'template-parts/content-none.php'; } require_once 'footer.php';

qui est très similaire à celui que nous avons dans le thème Twenty Twenty-One. Alors, à ce stade, vous vous demandez peut-être : qu'est-ce que je gagne à utiliser des fonctions WordPress spécifiques ? N'est-ce pas la même chose d'utiliser directement un PHP require , d'autant plus que, selon la documentation de WordPress, c'est précisément ce que ces fonctions d'assistance utilisent ?

Eh bien, la raison principale est en fait mentionnée dans la documentation elle-même : cela facilite la création d'un thème enfant. Ainsi, si vous créez un thème enfant et que vous utilisez get_template_part , WordPress cherchera le template dans l'enfant et, si ce n'est pas le cas, il utilisera celui du parent.

Mais ce n'est pas tout! Les fonctions de WordPress regorgent généralement de filtres et d'actions qui permettent d'adapter le résultat final. Par exemple, si nous regardons la fonction interne get_template_part dans le fichier wp-includes/general-template.php :

 function get_template_part( … ) { do_action( "get_template_part_{$slug}", … ); … do_action( 'get_template_part', … ); if ( ! locate_template( … ) ) { return false; } }

nous verrons que nous avons quelques actions que les plugins et le thème lui-même peuvent exploiter. Et si nous continuons à tirer le fil, nous pourrons même voir comment WordPress localise ( locate_template ) et charge le modèle qu'il finira par utiliser :

 function locate_template( $template_names, … ) { $located = ''; foreach ( $template_names as $name ) { if ( file_exists( STYLESHEETPATH . "/$name" ) ) { $located = …; // in child theme break; } else if ( file_exists( STYLESHEETPATH . "/$name" ) ) { $located = …; // in parent theme break; } else { … } } if ( $located ) { load_template( $located, $require_once, $args ); } return $located; }

J'espère que le post d'aujourd'hui vous a aidé à comprendre un peu mieux le fonctionnement des thèmes WordPress. J'espère également qu'il vous a montré comment en savoir plus sur WordPress en lisant sa documentation et en parcourant son code source. Et si vous l'avez aimé, partagez-le avec vos amis et laissez-nous un commentaire.

Image sélectionnée par Joshua Sortino sur Unsplash.