Tour d’horizon des possibilités
Ce guide explore les différentes règles à respecter pour personnalisation « effort-less » des thèmes WordPress et ainsi offrir un thème aux pages variées et au code mutualisé au maximum.
La question qu’il faut se poser en tête de toute réflexion autour de la personnalisation de thème :
Quels fichiers WordPress va-t-il utiliser en fonction des pages à afficher?
Voici la liste des pages qui vont permettrent une personnalisation contextualisée (nous avons rajouté le numéro de version noyau qui a vu la peronnalisation sur cette page apparaître) :
- Page d’accueil
- Page d’atterrissage (3.0)
- Affichage d’un article
- Affichage d’une page (2.9)
- Affichage d’un cutom content type (3.0)
- Affichage des contenus (article, page, custom content type) liés à une catégorie
- Affichage des contenus (article, page, custom content type) liés un mot-clé (2.3, 2.9)
- Affichage des contenus (article, page, custom content type) liés à une taxonomie personnalisée (3.0)
- Affichage d’une page d’archive (3.1)
- Affichage des auteurs (3.0)
- Affichage des dates de publication
- Affichage des résultats de recherche
- Affichage des pages 404
- Affichage des pièces jointes (2.0)
Ne réinventons pas la roue : le codex WordPress publie un document très bien fait qui montre le process que suit le noyau lors du service d’une page. Par ailleurs, la fonction de détermination associée pour notre code (ex : is_page()) y est associée :
Organigramme de choix de fichier thème par le noyau WordPress
Les fonctions get_header(), get_footer() et get_sidebar()
Depuis la version 2.7 du noyau, il est possible de passer en paramètre à get_header() et get_footer() un nom pour appeler différents headers & footers. L’intérêt : pouvoir charter différemment les éléments structurants que sont un header et un footer en fonction du contexte. Exemple avec un 404 :
if ( is_home() ) :
get_footer('home'); // cherche le fichier footer-home.php dans le répertoire du thème actif
elseif ( is_404() ) :
get_footer('404'); // cherche le fichier footer-404.php dans le répertoire du thème actif
else :
get_footer();
endif;
Le get_sidebar() prenant en paramètre un nom est un peu plus ancien (version 2.5) et fonctionne de la même manière : un paramètre « nom » passé lors de l’appel résultera une recherche du fichier sidebar-[nom].php. La différence réside ici dans la déclaration (ou non) de la sidebar dans le fichier functions.php (via register_sidebar(), nécessaire si l’on veut pouvoir ajouter des widget via l’interface d’administration :
Sans déclaration :
get_sidebar('right'); // cherchera et chargera le fichier sidebar-right.php
Avec déclaration :
get_sidebar('right'); // cherchera et chargera le fichier sidebar-right.php
Dans le fichier sidebar-right.php :
dynamic_sidebar('ma-sidebar-droite'); // chargera les widgets placés sur l'encart prévu à cet effet dans l'administration des widgets, si la sidebar 'ma-sidebar-droite' a été préalablement déclarée dans functions.php
// Suite du fichier avec les widgets/code "en dur"
La fonction « get_template_part »
Une fois que nous avons pu déterminer l’arborescence des fichiers nécessaires à notre thème, une fonction apparue dans la version 3.0 du noyau permet de créer des fichiers contenant des portions de code réutilisables dans plusieurs endroits du thème. get_template_part systématise ce que beaucoup d’entres nous faisaient manuellement à l’aide des « include » en php.
Elle prend 2 paramètres : un slug et un nom. Par exemple :
get_template_part('loop','projects'); // Cet appel chargera à la manière d'un include le fichier loop-projects.php dans le répertoire du thème actif
Vous en voyez l’utilité : la mutualisation du code réutilisable, avec à la clé une plus grande maintenabilité.
Pour aller plus loin : modification du moteur qui régit l’ordre d’affichage
Si votre besoin était très spécifique, ou que vous ayez besoin systématiquement d’un organigramme de choix de fichier différent de celui présenté dans le schéma ci-dessus, des filtres ont été positionnés afin de vous permettre de réorganiser tout ça. Ils utilisent cette syntaxe de nommage de fichier : [type]_template_hierarchy.
Voici quelques types réogranisables par ce biais :
- single_template_hierarchy
- page_template_hierarchy
- category_template_hierarchy
- …
Et pour finir, un exemple : comment faire en sorte que le noyau recherche des fichiers de themes « author » par rôle avant tout (à ajouter dans le fichier functions.php):
function author_role_template( $templates ) {
global $role;
// création de l'entrée correspondant au nouveau masque de recherche
$new_template = array( "author-$role.php" );
// Ordre initial de recherche par le noyau, contenu dans la variable $template :
// - author-{nicename}.php
// - author-{id}.php
// - author.php (defaut)
$templates = array_merge(
array_slice( $templates, 0, -1 ), // before
$new_template, // inserted
array_slice( $templates, -1 ) // after
);
return $templates;
}
add_filter( 'author_template_hierarchy', 'author_role_template' );
Vous savez à présent comment composer au mieux avec mes fichiers de thèmes WordPress. N’hésitez pas à réagir ou a poster via les commentaires vos bonnes pratiques!
A propos de Nicolas BONNIOT
Titulaire d'un DUT Génie Electrique & Informatique Industrielle et d'un diplôme d'ingénieur généraliste ECAM Rennes, Nicolas a débuté sa carrière dans les systèmes d'information (recette, développement client lourds, flux...) puis s'est spécialisé à présent dans le développement web (boutiques, sites vitrines, CMS...). Un fort intérêt personnel pour l'écologie et l'écriture l'ont rapidement conduit vers le blogging puis la pige magazine, notamment sur l'éco-construction et les énergies renouvelables. Il a par ailleurs toujours voulu garder une pluri-disciplinarité qui s'apparente fortement à la mécatronique : conception mécanique, électronique et informatique pour répondre à des besoins/fonctions d'automatisation simples & complexes.
