One Chapter A Day
ONE CHAPTER A DAY Un chapitre... presque tous les jours !
© Jordan Whitfield

Mieux concevoir WordPress : plugins vs thèmes

Depuis quelques mois, je travaille sur la refonte de ce blog.
Fonctionnalités et design, tout va y passer !

Pour ce faire, je me suis mise à réfléchir à comment je pourrais améliorer mon utilisation de WordPress au quotidien. En tant que développeuse, il y a plein de petites choses que j’avais pris pour habitude de faire dans le code du thème que j’utilise.

Un thème est ce qui permet à un blog WordPress de changer d’apparence et d’apporter une sensibilité autre à l’expérience utilisateur. Un thème peut de ce fait proposer certaines particularités qui lui sont propres, telles que la possibilité de changer la structure de la page d’accueil, la qualité de personnaliser les tailles des images ou le pouvoir de disposer de pages responsives ou adaptatives par exemple.

Les vraies fonctionnalités d’un blog WordPress sont plus généralement pourvues grâce à des plugins. Ce sont ces mêmes plugins qui permettent d’activer et de désactiver à tout moment une fonctionnalité sur un blog.

En faisant un rapide état des lieux de mon organisation sur WordPress, je me suis rendue compte d’une chose : au cours de ces trois, presque quatre années, à utiliser ce même template WordPress, j’ai souvent répondu à mes besoins en ajoutant des lignes de code supplémentaires à mon thème original. En bref, le code de mon thème est devenu de moins en moins dissocié de mes besoins en termes de fonctionnalités. Je m’explique.

 
Au fil du temps, j’ai ajouté des fonctionnalités à ce blog par le biais du fameux fichier functions.php de mon thème. C’était simple, rapide et efficace. Du moins… en théorie ! Je me suis rendue compte que ce blog est devenu totalement dépendant de ce thème créé en 2013 lors d’une précédente refonte. En gros, si aujourd’hui je devais changer de thème et en utiliser un plus en accord avec la dernière version à jour de WordPress, je ne pourrais pas le faire aussi rapidement que je le voudrais, juste en cliquant sur un bouton. Enfin si, je pourrais, mais alors une partie des fonctionnalités que je propose sur ce blog ne serait plus disponible.

Que certaines spécificités n’existent plus, c’est une situation plus ou normale : certains thèmes proposent la possibilité de réorganiser la page d’accueil d’un blog, et pas d’autres par exemple. Il faut accepter que chaque thème possède ses propres qualités. Là où j’apprends aujourd’hui de mes erreurs passées, c’est que j’arrive plus facilement à faire la distinction entre une fonctionnalité qui doit faire partie d’un thème WordPress et une fonctionnalité que je souhaite pouvoir conserver à jamais pour le blog, qui doit par conséquent figurer dans un plugin.

 
Pour vous illustrer mes propos, je peux vous parler des copyrights des photos utilisées sur ce blog, probablement un détail pour certains, mais une information plus qu’importante à mes yeux. Si je n’avais pas revu la manière dont j’avais pensé ces copyrights courant 2012-2013, ceux-ci ne s’afficheraient pas sans ajouter un gros – très gros – morceau de code au nouveau thème que j’utiliserai. Bien sûr, le jour où je changerai de thème, il faudra également que j’ajoute une ligne sur la page de mes articles pour les voir s’afficher, mais ce sur quoi je veux insister, est sur l’effort produit pour faciliter cette addition.

Auparavant, j’utilisais des attributs HTML data-author et data-url que j’insérais sur chacune des balises d’images de mes articles. Je parsais ensuite le contenu de chacun de mes articles pour réécrire le copyright et le lien de celui-ci dans un figcaption. Ça fonctionnait super bien… mais autant vous dire que la lecture de ce code était compliquée ! Et si j’avais envie d’inviter quelqu’un qui ne code pas à écrire sur mon blog, j’étais obligée de « finaliser » son article pour avoir les copyrights au bon endroit. C’était un travail fastidieux qui m’obligeait à être parfaitement rigoureuse sur l’écriture de chacun de mes articles.

J’ai depuis créé un petit plugin pour cette fonctionnalité qui permet par une simple fonction d’obtenir ces informations.

J’ai plein d’autres exemples qui me viennent à l’esprit. J’ai toujours proposé aux utilisateurs de ce blog la possibilité de lire un article sélectionné au hasard parmi tous les articles écrits à ce jour. Cette fonctionnalité était également pourvue dans le fameux fichier functions.php de mon thème. En clair, désactiver ce thème aurait supprimé cette fonctionnalité également. Ce n’était plus possible de continuer ainsi.

 
Alors j’ai commencé à réfléchir.
Comment aurais-je écrit mes fonctionnalités si elles devaient être pensées pour des personnes qui n’ont aucune idée de ce qu’est un attribut HTML ? Comment aurais-je fait en sorte que ces mêmes personnes puissent s’en sortir sans que j’aie à intervenir à chaque fois qu’elles écrivent un nouvel article ?

J’ai ainsi décidé d’améliorer le back-office de WordPress de façon à ce que tout soit plus facilement administrable. L’idée c’est de repenser chacune de mes fonctionnalités comme si un utilisateur non-développeur devait se retrouver à utiliser mon back-office. Ça paraît bête ainsi, mais c’est véritablement important de savoir que ce que l’on code peut être utilisé par d’autres. Probablement que même un autre développeur en aurait eu marre d’ajouter des attributs HTML là où il le faut pour que tout s’affiche comme il faut (vous me suivez encore ? :)).

Cela me permettra également d’éviter d’avoir à faire de trop grosses migrations de données à chaque fois que je souhaite changer de thème. Si tout est bien organisé au moment où je souhaite utiliser un nouveau thème, alors je n’aurais plus qu’à introduire une fonction par-ci, une autre par-là, et tout marchera de la manière la plus optimale possible.

Donnez votre avis