Comme dans tout projet web, une bonne organisation est clef ! Nous allons rapidement passer en revue la hiérarchie des fichiers d’un site WordPress et voir ensuite comment organiser notre code.

La racine

On ne va pas tout décrire de manière détaillée, mais sachez que index.php, sans surprise, est le point d’entrée de toutes les requêtes du site. Comme dans tout framework PHP effectuant du routing, nous avons un fichier qui reçoit toutes les requêtes et appelle ensuite les bonnes fonctions en conséquence.

Le seul fichier qui nous intéresse à la racine est le wp-config.php, c’est en effet là que l’on entre nos informations de connexion à la base de données et que l’on définit certaines constantes de configuration. Les autres fichiers sont des fichiers du core et nous n’y toucherons jamais.

Petite exception par rapport à une installation WordPress de base, nous avons ici wp-cli.phar (souvent renommé en wp-cli sans extension). Il s’agit de l’exécutable de la ligne de commande WordPress. Nous l’invoquerons directement pour accéder à la CLI.

En ce qui concerne les répertoires, wp-admin/ et wp-includes/ ne sont pas non plus d’un grand intérêt pour nous. Ils renferment en effet des centaines de fichiers contenant tout le code de WordPress. Tout ce qui est contenu dans ces deux répertoires n’est à modifier sous aucun prétexte, car toute modification serait perdue à la première update.

La seule exception à cette règle est si vous souhaitez proposer une modification au code de WordPress. Cependant, rien ne vous empêche d’aller fouiller dans le code pour voir comment telle ou telle chose fonctionne.

En dernier lieu, nous avons wp-content/, c’est là que se trouvent les fichiers uploadés (images, pdf…), les plugins, les thèmes et les traductions et c’est donc naturellement là que nous allons travailler.

Le thème : notre terrain de jeux

Il y a deux endroits où l’on peut ajouter du code pour programmer dans WordPress :

• le thème,
• les plugins.

Le même résultat peut être produit à l’aide d’un plugin ou de functions.php. Si vous créez de nouvelles fonctionnalités qui devraient être disponibles quel que soit l’aspect du site Web, il est recommandé de les mettre dans un plugin.

WordPress Developer

Les plugins permettent d’encapsuler de la logique de manière totalement indépendante du thème et rapidement réutilisable d’un projet à l’autre. Néanmoins, les plugins doivent être activés pour fonctionner et un administrateur peut les désactiver, provoquant des bugs si le projet en dépend.

Par ailleurs, lorsque l’on perçoit WordPress comme un framework servant de base à un projet, tout se passe dans le thème. Le projet n’a pas de sens sans son thème. Ce serait un peu comme se dire que l’on travaille sur un projet Symfony et que l’on veuille à un moment ne garder que Symfony tout en remplaçant le code métier.

Dans notre cas, si l’on veut par exemple faire évoluer le design, on fera évoluer le code correspondant au design de notre thème, tout en conservant la logique métier.

Hiérarchie d’un thème

Dans un thème WordPress, le code est divisé en de nombreux fichiers, chacun étant responsable de certains types de contenus (pages, articles…) ou partie de contenus (header, footer…). Cette fameuse organisation s’appelle la template hierarchy.

Ce système est à la fois simple et extrêmement puissant. Je ne vais pas ici rentrer dans les détails, mais la documentation officielle explique parfaitement comment s’articlent ces différents fichiers.

Si la création de thème WordPress vous est totalement étrangère, vous devriez vous familiariser avec les différents fichiers constitutifs d’un thème. Comme le monde est bien fait, il y a un cours officiel sur tout ce qu’il faut savoir pour la création de thèmes.

En outre, ce cours vous délivre les secrets de certains mécanismes essentiels :

• les template tags & template parts,
• la fameuse loop,
• le fichier functions.php,
• les tags conditionnels,
• les taxonomies.

Par ailleurs, il y a une autre notion indispensable au travail dans WP : les hooks. Ces hooks sont des évènements, déclenchés et écoutés partout dans WordPress. Certains sont créés dans le core, d’autres dans des plugins et ils sont également écoutés à divers endroit.

Vous pouvez les écouter depuis le thème mais aussi créer les vôtres. Ce système permet de réagir à certains évènements en exécutant vos fonctions à des moments précis, de créer vos propres évènements mais aussi de modifier les données précédemment générées.

On distingue les actions et les filtres :

• une action récupère des informations et déclenche une action à partir de ces dernières (sauvegarde en BDD, envoie d’un email…),
• un filtre récupère des informations, les modifie et les retourne au flux normal (par exemple modification du code des commentaires).

Lier le CSS et le JS

La bonne pratique de WordPress est d’utiliser les fonctions wp_enqueue_style et wp_enqueue_script pour ajouter des styles et des scripts.

La raison derrière l’usage de ces fonctions est qu’elles peuvent être appellées depuis n’importe où (thème, plugin…). De ce fait, il peut être intéressant par la suite de pouvoir vérifier, modifier ou même supprimer tel ou tel script ou feuille de style.

Cependant, ce n’est pas parce que c’est une bonne pratique dans WordPress qu’il faut impérativement la suivre. Notre approche et nos impératifs sont un peu différents. Nous voulons par exemple pouvoir proposer nos scripts en deux versions :

• version ES6+ pour les navigateurs récents,
• version ES5 pour les navigateurs anciens.

Pour nos scripts, nous voudrons peut-être ajouter un attribut async ou defer dans l’optique d’optimiser les performances.

Concernant les styles, nous souhaiterons les séparer en fonction des différentes parties du site : on ne charge pas tous les styles du blog sur les fiches produits. Par ailleurs, nous voudrons en charger certains de manière prioritaire : le style du header est prioritaire, celui du footer peut être chargé en asynchrone.

Tout ça n’est pas possible via les deux fonctions de WordPress. Pour ces raisons, et comme nous maîtrisons la chaîne de bout en bout pour les fichiers de notre thème, nous les ajouterons manuellement dans le head.

Pour ce faire, on utilisera la fonction get_template_directory_uri, laquelle nous facilite la tâche afin de ne pas avoir à préciser le chemin complet de nos répertoires d’assets dans le wp-content/.

Diviser pour mieux régner

Qu’il s’agisse des fichiers de template, de style.css ou du functions.php, si on place tout à la suite sans faire attention, ça finit irrémédiablement par être in-maintenable. C’est pourquoi on va intelligemment organiser notre code.

Les templates

Par défaut, WordPress n’a pas d’architecture MVC. La logique et le HTML sont joyeusement mélangés comme au bon vieux temps. S’il n’y a pas trop de logique, on arrive à s’y retrouver, mais tout projet d’envergure conduit forcément à en avoir une quantité non négligeable.

Certains projets forcent cette organisation et adjoignent des langages de template, c’est le cas de Timber que j’ai déjà mentionné. Il n’est cependant pas utile d’apprendre une nouvelle syntaxe pour profiter d’un code propre. Il suffit d’observer quelques règles.

• Les fichiers de templates contiennent le HTML. Le PHP dans ces fichiers doit se limiter à récupérer quelques variables, à vérifier des conditions et à faire des boucles.
• La logique doit rester dans des fichiers de fonctions dédiés à cet effet.
• Il ne faut pas hésiter à diviser le code en sous-templates et à faire usage de get_template_part, pour les templates qui deviennent trop volumineux et/ou complexes.

Les styles

C’est un pré-requis de tout thème WordPress, on doit avoir un fichier style.css. Cela ne veut pas dire qu’on doit obligatoirement y mettre tous nos styles les uns à la suite des autres. Pour un site un tant soit peu complexe, c’est ingérable !

Dans mon framework Steroids, ce fichier est là juste pour faire plaisir à WordPress et les styles sont regroupés dans un répertoire séparé. Ils sont divisés en autant de fichiers qu’il y a de templates (voir plus) et tout est géré à la compilation par Less (mais vous pouvez utiliser Sass ou autre).

/*
    Theme Name: Steroids
    Description: Steroids, a blank WordPress theme with modern tooling
    Version: 2.0
    Author: Buzut
    Author URI: https://buzut.net
*/

/* This is just to please WP, the real stylesheet lies in styles/ */

C’est tellement plus clair d’aller se référer aux styles du footer dans un fichier dédié que de fouiller dans un fichier global. Si ce n’est pas la méthode que vous utilisez jusque là, vous allez vous demander pourquoi vous n’y avez pas pensé plus tôt !

Les fonctions

On applique la même logique que pour les styles. L’idéal est de regrouper toutes les fonctions par thématique dans un répertoire dédié, je l’appelle inc car c’est une appellation assez standard (inc pour include), mais libre à vous de changer si vous préférez autre chose.

WordPress requiert un functions.php, aucun problème. On va justement s’en servir pour charger nos fichiers contenus dans inc via require – sans quoi ils ne servent à rien. Il n’y a là aucune obligation stricte en terme de séparation et de naming, j’aime cependant avoir quelques fichiers par défaut :

• navigation.php,
• sidebar.php (au besoin),
• template.php (pour les fonctions qui affichent des choses au lieu de return et d’exécuter des actions),
• theme-support.php (pour gérer les options du thème),
• image-management.php,
• assets-management.php (pour le CSS & JS),
• admin.php (au besoin pour la partie admin).

Ouf ! Voilà encore un chapitre bien chargé. Cette fois nous avons les bases pour attaquer le code à proprement parler. Dans le chapitre suivant, nous allons parler des solutions pour booster notre productivité et ne pas créer son thème depuis zéro à chaque fois.