Jusqu’à présent, on a laissé le système de templates de WordPress gérer les différents cas de navigation dans le site :
- page d’accueil ->
home.php - archive mensuelle ->
date.php - catégorie ->
category.php - mot-clef ->
tag.php - page dédiée ->
single.php
Mais qu’en est-il des includes ? Ne sont-ils pas exactement les mêmes pour tous les templates qui les utilisent ? Pour l’instant, oui.
On va y remédier.
Des conditions pour les includes
Rappelez-vous… On a mis un <h1> pour le titre d’un Post sur la page single.php et du coup, on avait deux <h1> sur la même page (en comptant celui du header). Même si le W3C ne l’interdit pas, c’est une bien mauvaise pratique. Et un SEO Guru m’a déjà dit qu’il était préférable d’avoir des titres différents selon les pages que l’on visite. Et le <h1> joue ce rôle : c’est en quelque sorte le titre de la page. Du coup, en arrivant sur une page single.php, il n’y a qu’un seul Post, et le titre de la page est logiquement celui du Post, et pas celui du site.
On va reprendre le header.php pour l’améliorer :
<!DOCTYPE html>
<html <?php language_attributes(); ?>>
<head>
<meta charset="<?php bloginfo('charset'); ?>">
<title><?php the_title(); ?></title>
<link rel="stylesheet" href="<?php bloginfo('stylesheet_url'); ?>" type="text/css">
<?php wp_head(); ?>
</head>
<body>
<div>
<header>
<?php if (is_single()) : ?>
<p><a href="<?php bloginfo('home'); ?>"><?php bloginfo('name'); ?></a></p>
<p><?php bloginfo('description'); ?></p>
<?php else : ?>
<h1><a href="<?php bloginfo('home'); ?>"><?php bloginfo('name'); ?></a></h1>
<h2><?php bloginfo('description'); ?></h2>
<?php endif; ?>
</header>
On vient d’utiliser notre premier Conditional Tag. Il en existe énormément, et permettent, entre autres, de savoir :
- si on est sur la page d’accueil
is_home() - si on est dans une archive
is_archive,is_tag,is_category,is_taxonomy,is_date,is_year,is_month… - si on est sur une page auteur
is_author(un truc qu’on a pas vu mais qui est rarement utilisé étant donné qu’il y a généralement un seul auteur, ou alors leur différenciation n’est pas nécessaire) - si c’est une preview d’un brouillon
is_preview - si on est dans la boucle
in_the_loop - si un plugin est activé
is_plugin_active - si votre thème possède une certaine fonctionnalité
current_theme_supports
La sidebar est un fichier très friand de ces Conditional Tags.
Cumuler pour mieux régner
Comme pour toute condition PHP, Il est tout à fait possible de cumuler plusieurs conditions en les imbriquant.
<?php if (is_user_logged_in()) { ?>
<?php if (is_home()) { ?>
<p>Hello toi !</p>
<?php } ?>
<?php } ?>
Les opérateurs usuels sont bien sûr acceptés.
if ( is_home() || is_single() ) {
the_content();
} else {
the_excerpt();
}
Vous aurez remarqué que j’utilise ici des { accolades }. C’est juste pour vous montrer que l’on peut aussi utiliser de simples accolades, et c’est parfois plus pratique lors d’imbrication de conditions.
Eviter de se répéter
Le concept du DRY (cher notamment à ces Rubistes…) est toujours de rigueur, que ce soit en CSS, Python, ou dans le code PHP de notre thème.
Si l’on prend nos fichiers archive.php et category.php, ils sont quasiment identiques. Et pour cause : on a utilisé le premier pour créer le second. Il y a bien une raison à cette division : category.php contenait un bout de HTML supplémentaire qui contenait le nom de la catégorie (la fonction single_cat_title ). Et étant donné que archive.php était utilisé pour tout type d’archive (de date, de tag, de catégorie, de taxonomy…) mais que la fonction single_cat_title ne marchait pas pour toute (sans compter le mot « Catégorie » en dur dans le HTML), il fallait créer séparément category.php.
Mais avec ces Conditional Tags, quoi de plus simple de créer un bout de code conditionnel dans archive.php ?
<?php get_header(); ?>
<div class="main">
<?php if ( is_category() ) : ?>
<h1>Catégorie : <?php single_cat_title(); ?></h1>
<?php endif; ?>
<?php get_template_part('loop'); ?>
</div>
<?php get_sidebar(); ?>
<?php get_footer(); ?>
J’ai supprimé le query_posts('posts_per_page=20') qui n’était pas indispensable.
Supprimez category.php pour que WP utilise archive.php. Vous verrez que la partie « Catégorie : » ne s’affichera que lorsqu’une page de catégorie sera appelée.
Du coup, on peut imaginer un archive.php plus riche :
<?php get_header(); ?>
<div class="main">
<?php if ( is_category() ) : ?>
<h1>Catégorie : <?php single_cat_title(); ?></h1>
<?php elseif ( is_tag() ) : ?>
<h1>Mot-clef : <?php single_cat_title(); ?></h1>
<?php elseif ( is_year() ) : ?>
<h1>Année : <?php the_time('Y'); ?></h1>
<?php elseif ( is_month() ) : ?>
<h1>Mois : <?php the_time('F Y'); ?></h1>
<?php elseif ( is_day() ) : ?>
<h1>Jour : <?php the_time('j F Y'); ?></h1>
<?php endif; ?>
<?php get_template_part('loop'); ?>
</div>
<?php get_sidebar(); ?>
<?php get_footer(); ?>
Du coup, on évite de créer category.php, tag.php et date.php.
« Mais du coup bbx, on pourrait pas aller plus loin en utilisant uniquement index.php ? »
Petit scarabée, tu ne crois pas si bien dire…
Un seul index to rule them all
Admettons. Ce n’est pas quelque chose que j’ai déjà fait, mais admettons…
Admettons que l’on veuille regrouper tout notre système de templates en un seul fichier, est-ce bien possible ?
Oui c’est possible.
Du coup, étant donné que les includes header, loop, footer et sidebar seront appelés par un seul template (index.php), il sera inutile de créer des includes et donc préférable de mettre directement le code PHP de ces includes dans index.php.
Faites-le si vous le souhaitez, j’ai la flemme de faire la démonstration… Je vois d’ailleurs venir des problèmes de lisibilité du code, de maintenance, de performance…
Attardons nous plutôt sur les Widgets WordPress.