WordPress : je t’aime moi non plus

Technique

24 fév, 2020

WordPress est l’une des solutions communément utilisées au sein de l’agence, et de façon plus générale sur le marché :Capture d’écran 2020 02 24 à 11.23.54 WordPress : je t’aime moi non plus

Cependant, c’est une technologie qui ne jouit pas toujours de la meilleure réputation auprès des développeurs… En effet, un rapide sondage autour de nous révélera qu’elle n’arrive pas en tête des solutions préférées

Dans cet article, nous allons tenter de voir pourquoi WordPress a cette réputation et s’il existe des solutions qui permettrait d’améliorer celle-ci.

N.B. Le but de cet article n’est pas de savoir si WordPress est ou non une bonne solution pour tel ou tel projet car, pour le déterminer, il faut pouvoir analyser le contexte et le besoin (client, budget, staffing, typologie de projet, etc)

Présentation rapide

WordPress c’est quoi ? Reprenons la définition de la fiche Wikipedia : 

WordPress est un système de gestion de contenu (SGC ou content management system (CMS) en anglais) gratuit, libre et opensource. Ce logiciel écrit en PHP repose sur une base de données MySQL et est distribué par l’entreprise américaine Automattic. Les fonctionnalités de WordPress lui permettent de créer et gérer différents types de sites Web : site vitrine, site de vente en ligne, site applicatif, blogue, ou encore portfolio. Il est distribué selon les termes de la licence GNU GPL version 2. Le logiciel est aussi à l’origine du service WordPress.com2.

En octobre 2019, WordPress est utilisé par 34,7 % des sites web dans le monde, ses concurrents directs sont à 2,7 % (Joomla) et à 1,7 % (Drupal) tandis que 43,6 % des sites n’utilisent pas de système de gestion de contenu.

Sur la papier, rien à signaler. WordPress semble une bonne solution pour développer un projet web. Une solution basée sur un socle plutôt solide. Elle met à disposition un back office, avec de nombreuses fonctionnalités et propose même des plugins qui permettent de gagner du temps pour le développement de certaines fonctionnalités.

Pour comprendre alors cette défiance, penchons-nous tout d’abord sur ce qui peut décourager un développeur devant l’utilisation d’une technologie plutôt qu’une autre.

L’architecture de WordPress

Un des points qui peut rebuter un développeur à utiliser WordPress est son architecture.

Prenons un cas concret : nous avons un projet web créé par un développeur. Pour des raisons de planning, un autre développeur est sollicité dessus. La première question va porter sur les technologies utilisées et c’est là que l’on va pouvoir mettre un avant un des défauts de WordPress.

Voici l’architecture de base d’un WordPress :

Capture d’écran 2020 02 24 à 11.37.44 WordPress : je t’aime moi non plus

Jusque-là, rien de problématique. Le dossier où nous sommes amenés à travailler est le répertoire wp-content/themes/votre theme.

Les premier ennuis surviennent. En effet, dans votre thème, WordPress n’impose aucune contrainte. Nous ne rentrerons pas dans les détails, mais pour simplifier il faut imaginer qu’une fois dans le répertoire de votre thème vous pouvez faire ce que vous voulez. WordPress propose une structure de templating mais cela s’arrête là.

Capture d’écran 2020 02 24 à 11.31.37 WordPress : je t’aime moi non plus

Mais cette structure ne vous empêche en rien d’ajouter votre propre structure. En comparaison, Symfony est moins permissif. Étant basé sur le modèle MVC, il sera beaucoup plus simple pour un développeur de prendre en main un projet Symfony (si bien entendu il connaît le framework) plutôt qu’un WordPress.

Pour détailler cela, voici un exemple :

– Si on demande à un développeur de travailler sur la homepage d’un site sous Symfony, il va chercher à quel controller est lié la route de la home. A partir de là, il pourra facilement identifier les templates de la homepage, etc

–  Sur WordPress, on va devoir aller dans le backoffice et identifier la homepage. A partir de là, on va devoir comprendre comment elle est montée (templating, plugin, etc). Grâce à cela, on arrivera à identifier dans le code les fichiers qui la gèrent. Mais une fois identifiés, rien ne nous dit que d’autres fichiers ne seront pas impliqués car, comme vu plus haut, WordPress étant permissif, on ne sait pas vraiment ce que le développeur a entrepris de faire.

Les thèmes

Le point que nous allons aborder ici est lié au point précédent. Un des avantages qui peut devenir un souci est l’utilisation de thèmes “tous faits”. Les avantages des thèmes sont qu’ils offrent à moindre prix un site prêt à l’emploi. L’inconvénient est que vous ne savez pas le code que vous allez récupérer ensuite. Il peut donc devenir très compliqué pour un développeur de comprendre comment cela fonctionne, d’autant plus (et ce sera notre point suivant) qu’un thème est souvent livré avec des plugins que l’on est obligés d’installer pour faire fonctionner le site.

Une fois de plus, l’idée n’est pas de dire que tous les thèmes sont mauvais, loin de là. Cependant, récupérer un projet qui est basé sur un thème est rarement une partie de plaisir.

On a souvent des découpages du code très (trop) segmentés, des fichiers “éponges” (script php) qui regroupent bon nombre de fonctions car un thème est souvent conçu avec beaucoup (trop) de fonctionnalités que l’on n’utilisera probablement pas et qui encombrent le code inutilement.

Les plugins, boîtes de Pandore

Les plugins occupent une place importante dans l’univers de WordPress car ils représentent souvent l’occasion d’ajouter des fonctionnalités ou d’améliorer des points sensibles sans pour autant passer par une phase de développement.

Un plugin est un élément externe et donc développé par une personne ou une entité qui n’a pas forcément en tête notre besoin et notre stack technique. 

Les problèmes que nous pouvons rencontrer avec les plugins sont nombreux. 

1- problèmes de compatibilité : comme nous l’avons vu plus haut, les plugins sont développés en grande partie par des entités externes à WordPress. On peut donc se retrouver face à une problématique de compatibilité avec un autre plugin, voire WordPress lui même si vous le mettez à jour.

Il va donc être demandé au développeur de régler le souci mais il se retrouve face à un sac de noeuds :

– il ne peut pas désactiver le plugin car cela voudrait dire supprimer une fonctionnalité

– il ne peut (doit) pas corriger le souci directement dans les fichiers du plugin car nos modifications seront écrasées à la prochaine mise à jour de celui-ci

Le développeur se retrouve donc “bloqué” et doit alors mettre en place une solution souvent complexe

2- problème de sécurité : un plugin c’est du code tierce. En installant un plugin, on s’expose potentiellement à des failles de sécurité.

3- problème de performance : les plugins et thèmes WordPress consomment du temps de traitement PHP. Plus vous avez de plugins, plus votre site WordPress risque d’être lent, que ce soit en back ou en front.

Il ne s’agit pas d’affirmer qu’il ne faut pas utiliser de plugins, mais que l’on se doit de les choisir avec parcimonie.

Nous préconisons d’installer seulement les plugins liés à la performance et à la sécurité (smush, w3tc, wordfence, …). En dehors de ce type de plugin, les seuls autres plugins que nous conseillons sont les plugins qui apportent une plus-value essentielle à WordPress (wpml, yoast, woocommerce, etc)

En revanche, nous déconseillons fortement d’installer un module pour créer un slider par exemple. Cela n’est pas indispensable et évite d’ajouter de la maintenance, de nuire à la performance et de s’exposer à des failles de sécurité.

Conclusion

Nous avons passé en revue les principaux points qui font de WordPress un outil parfois boudé par les développeurs. Bien évidemment, WordPress n’est pas une solution plus ou moins intéressante que les autres mais un projet WordPress réalisé de manière peu rigoureuse (chose qu’il permet plus facilement qu’un framework comme Symfony) peut devenir un vrai cauchemar pour les développeurs, et cette réalité est parfois source de défiance.

 

Sources :

Wikipedia

Kinsta

Laisser un commentaire.