RETOUR
En effet, on pourrait considérer WordPress comme étant relativement archaïque dans sa conception; que ce soit au niveau de l’architecture de sa base de données (tous les posts types dans une même table, pas de système de migration ni d’ORM …) que de son architecture interne (-quasi- absence de système de routage, pas de séparation des responsabilité au niveau du code, pas de moteur de template, …).
Pour faire simple, WordPress propose une administration plutôt agréable, une souplesse dans la création de contenus et leur récupération depuis la base de données, mais vous laisse un peu vous débrouiller pour faire quelque chose de propre avec tout ça dés lors que vous voudrez toucher au code et faire quelque chose d'un peu complexe.
Ainsi, lorsque vous installez un nouveau WordPress, vous n’avez à disposition que quelques fichiers PHP simples où se mêlent l’HTML et le PHP - un peu comme l’on faisait dans les années 2000 - dans lesquels il sera de plus en plus difficile d’intervenir et d’y apporter de nouvelles fonctionnalités à mesure que du code y est ajouté. Cela peut rapidement devenir une gageure à maintenir si l’on n’y prend pas garde, et y perdre un temps certain, voire même casser des fonctionnalités en en modifiant une autre.
Voici un exemple de ce à quoi peut ressembler une page HTML qui serait utilisée dans un Wordpress classique:
On peut constater, si l’on est un oeil averti, que ceci est une aberration et doit absolument être évité, car ici nous avons un code très simple mais on sent déjà qu'il est un peu confus et qu’il va devenir compliqué à maintenir s’il faut ajouter plus de complexité à l’application.
Une question s’est alors imposée à nous : Comment améliorer la qualité et la maintenabilité de nos applications WordPress ?
Dés lors, il a été question de s’inspirer des meilleures pratiques du domaine et de parvenir à les appliquer, à savoir : respecter les principes SOLID.
Cet acronyme désigne toutes les bonnes pratiques qui devraient être mises en oeuvre dans les projets de développement modernes, pour gagner en propreté, clarté, flexibilité et vitesse.
Pour respecter cela, notre réflexion s’est faite en plusieurs temps :
D’abord, exit les thèmes préfabriqués, nous ne faisons que des thèmes sur-mesure. Ensuite, il nous faudrait nous passer au maximum de plugins, afin d’avoir la main sur un maximum de logique métier; chaque client ayant évidemment ses besoins propres, nous devons pouvoir adapter n’importe quoi facilement, sans devoir se battre avec le code legacy du plugin ou du thème.
Certains plugins restent cependant incontournables, comme WPML pour l’internationalisation ou encore ACF pour l’utilisation de champs personnalisés dans les différents types de contenus. Cependant, tout ce qui doit passer par une configuration en backoffice devra être évitée si possible, comme par exemple la configuration et création des champs ACFs, ou la création et gestion de formulaires, pour lesquels aucun plugin ne sera utilisé.
Ensuite, il nous fallait rationaliser la manière dont les pages sont rendues. En effet, par défaut WordPress se contente de charger simplement un fichier .php ayant un rapport avec la page que vous désirez consulter, vous incitant ainsi à coder toute votre logique dans ce même fichier.
Pour nous aider avec tout ça, nous avons opté pour un patron de conception bien connu : le MVC, grâce auquel nous allons pouvoir séparer proprement notre application en plusieurs petits modules réutilisables.
Une architecture de projet MVC est modélisée comme suit:
Pour faire simple, voici comment le processus de rendu de page devrait se dérouler lorsqu’un utilisateur interroge le serveur :
Le client demande une page ⇒ le contrôleur qui lui est associé s’occupe d’agréger les données qui seront nécessaires à son affichage en appelant d’autres classes qui s’occuperont d’un travail en particulier ⇒ un moteur de rendu de template compile un fichier qui ne contiendra que des balises HTML et l’affichage des variables qui viennent du contrôleur.
Voici un exemple succinct de ce à quoi pourrait plutôt ressembler notre page en respectant ces principes SOLID.
Ainsi nous obtenons une séparation propre de la logique métier et le fichier final qui est rendu est épuré de toutes balises autres qu'HTML, facilitant grandement la souplesse de notre application, chaque classe pouvant ainsi être réutilisée facilement par une autre, on évite ainsi la duplication de code.
Bien sûr, il existe également d'autres possibilités et bonnes pratiques à adopter, qui feront l'objet de futurs articles.
