Je vous propose aujourd'hui d'en apprendre un peu plus sur le CMS WordPress et d'essayer de comprendre plus en profondeur les critiques qui sont faites à son égard.
WordPress c’est plein de failles !
La première critique qui revient assez souvent lorsque l'on parle de WordPress est son manque de sécurité. Ce défaut est amplifié par la popularité du CMS qui en fait une cible de choix pour les personnes à la recherche de failles de sécurités. L'impact d'une faille est aussi beaucoup plus important vu qu'elle va automatiquement affecter des milliers de sites.
Cependant, la popularité ne suffit pas à expliquer les problèmes. WordPress, par sa conception, amène certains risques en terme de sécurité (surtout dans sa configuration par défaut).
PHP
Le premier problème est l'utilisation de PHP. La méthode de fonctionnement de PHP fait qu'il est possible d'exécuter un fichier en connaissant l'URL permettant d'y accéder. Cela ne constitue pas un problème en soi mais amplifie l’impact d'autres problèmes. En effet, si un utilisateur arrive à obtenir les droits d'écriture sur un dossier il va être en mesure de créer un fichier PHP malicieux qu'il pourra ensuite exécuter via un simple appel HTTP.
Ce n’est pas un problème spécifique à WordPress mais il faut être très attentifs aux permissions lorsque l’on héberge une application PHP afin de ne pas se retrouver avec des fichiers PHP corrompus (cf point suivant).
Les permissions
Le second problème réside dans l'utilisation de permissions trop laxistes. Il n'est pas rare de voir des sites WordPress fonctionnant avec un utilisateur ayant les droits d'écriture sur l'ensemble des fichiers du site. Ces permissions permettent à l'administrateur de mettre à jour le site et d'installer des extensions ou des thèmes depuis l'interface web.
De telles permissions permettent à une personne exploitant une faille de sécurité d'écrire de nouveaux fichiers, ou de modifier les fichiers de WordPress pour injecter du code malicieux. Ce code peut être utilisé pour espionner votre site ou pour utiliser les resources de votre serveur à votre insu.
Il n'y a pas de solution miracle contre cette problématique si ce n'est de verrouiller complètement les permissions des dossiers et de ne laisser accessibles en écriture que le dossier censé accueillir les fichiers envoyés par l'administrateur (le dossier wp-content/uploads). On rajoutera aussi une règle particulière afin d'empêcher l'exécution de fichier PHP au sein du dossier uploads (ce dossier n'est censé accueillir que des images). Ceci permettra de limiter l'impact d'une faille sur votre application.
En revanche, ces permissions plus restrictives empêcheront l'administrateur de mettre à jour le site ou les extensions depuis l'interface web. Il faudra alors faire ces opératiosn depuis le serveur avec des outils comme wp-cli.
Tout à la racine
L'autre souci que nous allons rencontrer avec WordPress est la structure des dossiers. En effet, pour faire fonctionner le site, la racine du serveur web doit pointer vers la racine de WordPress. Cette configuration a pour effet de rendre l'ensemble des fichiers de l'application accessible depuis le web.
C'est aujourd'hui une pratique très déconseillée, que l'on ne retrouve dans aucune application PHP modernes. On préconise de placer les fichiers sources un niveau au-dessus de la racine web (par exemple les dépendances PHP sont situés dans un dossier vendor non accessible depuis le web). C'est d'ailleurs la présence de dépendances dans un dossier public qui a permis l'exploitation d'une faille au sein de PHPUnit par exemple.
Malheureusement, il n'existe pas de méthodes permettant de mitiger ce problème pour les fichiers de WordPress. Il est possible, lorsque vous codez un thème ou une extension, de déplacer les fichiers ailleurs sur votre serveur mais il n'est pas possible de le faire pour les fichiers de WordPress sans nuire au bon fonctionnement du CMS.
wp_has_password()
Le hashage des mots de passe est souvent remis en question. Pour une meilleure compatibilité, et pour supporter de vieille version de PHP, WordPress utilise la librairie PHPass externe pour hasher les mots de passe. En soi, cette librairie peut convenir mais WordPress utilise un coût qui est trop faible par rapport aux standards actuels. Ce coût fait que, si une personne arrive à obtenir une base de données, elle sera en mesure (dans un temps plus ou moins raisonnable) d'obtenir les mots de passe par la méthode de la force brut. L'augmentation du coût, permet de ralentir cette stratégie et d'empêcher les attaquants d'obtenir les mots de passe de vos utilisateurs dans un temps raisonable.
Il est toutefois important de noter que WordPress dispose d'un mécanisme permettant de remplacer la méthode de hashage du CMS. Il est donc conseillé de remplacer cette stratégie par une stratégie plus sécurisée (via le plugin password_hash ou la librairie wp-password-bcrypt)
Wordpress c’est lent !
Un autre argument donné à l'encontre de WordPress est sa lenteur. On fait souvent l'expérience de sites long à s'afficher ou qui consomment beaucoup de ressources côté serveur.
Pauvre MySQL :(
Une des racines du problème est la multiplication des requêtes SQL lors de la génération d'une page WordPress. En effet, de nombreux modules et de nombreuses fonctions génèrent des requêtes SQL qui ne sont pas forcément nécessaires. Aussi, il n'est pas rare de voir plusieurs centaines de requêtes effectuées pour afficher une page d'article.
C'est un problème inhérent au fonctionnement même d'un CMS qui cherche à avoir une structure de base de données la plus générique possible (afin de s'adapter à un maximum de cas). Il sera possible de mitiger ce problème grâce à l'utilisation de cache qui permettra de mettre en mémoire les données. Cette mise en cache permet de faire descendre drastiquement le temps d'affichage d'une page et d'alléger les resources serveur nécessaires.
Si vous développez un thème ou un plugin vous pouvez aussi utiliser l'extension query-monitor afin d'observer le nombre de requêtes faites par le CMS et d'évaluer l'impact de vos propres fonctions.
WP_POST_REVISIONS
L'autre souci que l'on rencontre systématiquement est une base de données saturée par l'utilisation des révisions. Ce système permet de garder en mémoire une trace des différentes modifications faites aux contenus (sans limite de temps par défaut !). Ces révisions finissent par saturer la base de données et impactent négativement le fonctionnement du site. Vous pouvez remédier à ce problème en désactivant les révisions ou en limitant le nombre de révisions qui sont conservées par le système.
Trop de CSS et de JS
WordPress dispose d'un système permettant aux développeurs d'extensions et de thèmes de rajouter des assets JavaScript et CSS via un hook. Un site qui utilise beaucoup d'extensions se retrouvera fatalement avec des dizaines de Javascript et CSS. Ce qui a un effet négatif sur l'expérience utilisateur.
<?php
function loadMoreAssets($hook) {
wp_enqueue_script( 'custom_js', plugins_url( 'js/custom.js', __FILE__ ), array(), '1.0.0' );
wp_register_style( 'my_css', plugins_url( 'style.css', __FILE__ ), false, '1.0.0' );
wp_enqueue_style ( 'my_css' );
}
add_action('wp_enqueue_scripts', 'loadMoreAssets');Ce problème est souvent amplifié par l'utilisation de page builder qui permettent à l'administrateur de construire une page avec beaucoup de liberté et de modules. Ces extensions ont tendance à aussi générer du CSS et du JavaScript supplémentaire pour le chaque module qui est utilisé dans la page (carousel, accordéon, player vidéo...).
Il n'existe pas de méthode miracle pour lutter contre ce souci, si ce n'est d'éviter le problème à sa source. Si vous développez un thème personnalisé, essayé de minimiser l'utilisation de plugins et limitez au maximum l'utilisation de gros fichiers CSS / JS tiers (faites bien attention au poids des modules que vous utilisez afin de ne pas rendre le chargement de la page trop lent pour vos utilisateurs).
Il y a bien des plugins qui permettent de fusionner et minimiser le JS et le CSS mais ces plugins ne peuvent pas faire de miracles si vous chargez une dixaines de librairies de plus de 200ko (on retrouve cette situation très fréquemment sur les thèmes WordPress qui inclue tous les modules JavaScript imaginables).
Trop d’images
La multiplication des formats d'images amène souvent à des problèmes de place sur les serveurs modestes. Il est possible depuis un thème ou une extension de définir un format d'image.
<?php
add_image_size('mon-super-format', 220, 180, true );Avec parfois des formats déclarés pour des usages très spécifiques.Il faut savoir que chaque format sera ensuite généré pour chaque image envoyée par l'administrateur. Aussi, si le créateur du thème a déclaré une dizaine de formats, cela veut dire que 10 images seront créés pour chaque image envoyée par l’administrateur. Cette abondance de format peu poser des problèmes si vous avez un espace disque limité ou si le site a beaucoup de contenu.
Cependant, même si cette génération anticipée d'images constitue un problème côté serveur, elle présente un avantage d'un point de vue visiteur. En effet, lorsqu'un administrateur insère une image dans un article, WordPress utilise une balise image responsive qui permet un chargement d'image adapté à la résolution d'écran du visiteur (un visiteur mobile ne se retrouvera pas à charger une image en 3000x2000).
Si vous voulez limiter le nombre de formats d'images vous pouvez utiliser une méthode de génération à la demande via une librairie PHP ou via l'utilisation de services tiers.
WordPress c’est mal codé
Si vous demandez l'avis d'un développeur concernant WordPress, il ne tardera pas à critiquer le code du CMS et de ses extensions. C'est un argument qui revient d'ailleurs assez souvent à l'encontre de WordPress : "son code est mauvais". Pour garder la compatibilité avec d'anciens systèmes, mais aussi avec son propre écosystème, WordPress conserve du code daté, ce qui mène à un code moins facilement maintenable et plus propice aux bugs.
Hooks et Filtres
Le premier souci que vous allez rencontrer lorsque vous allez travailler avec WordPress (surtout si vous reprenez le code d'un autre développeur) est la sur-utilisation des filtres et des hook. Ces fonctions permettent de greffer un comportement à différent niveau du CMS en associant une fonction à un évènement particulier.
function addLolToTitle( $title, $id = null ) {
if ( in_category('lol', $id ) ) {
return $title . ' lol !';
}
return $title;
}
add_filter( 'the_title', 'addLolToTitle', 10, 2 );Le principal problème de cette approche est qui n'est pas possible d'identifier facilement les fonctions qui vont être appelées. Cela mène à de nombreuses confusions lorsque l'on recherche pourquoi le retour d'une fonction n'est pas celui attendu.
echo get_the_title(); // 'Je suis un titre'
the_title(); // 'Je suis un titre lol !'global
La seconde pratique que l'on retrouve très souvent dans WordPress est l'utilisation de variables globales (elles permettent de faire transiter le contenu dans le système). Cela pose plusieurs problèmes :
- Le code n'est pas testable facilement car il va falloir définir des variables globales avant de lancer les différentes fonctions à tester.
- Une même fonction peut donner un retour différent suivant le contexte dans lequelle elle est appelée (ce qui mène à de nombreuses surprises).
- Comme pour les filtres/hooks, il est souvent difficile de comprendre qui est à l'origine d'une modification d'une variable globale.
Pour vous donner un exemple plus précis, WordPress utilise une variable globale pour représenter la requête permettant de générer les contenus : $wp_query. Cet objet est passé dans tout le système et permet à WordPress de savoir quelle page afficher, quel template charger et se retrouve aussi utilisé dans des fonctions comme have_posts(). La modification de cette variable entraine un changement de comportement pour l'ensemble de l'application.
WordPress c’est pour les noobs !
Un dernier problème, plus subjectif celui-ci, est le fait que WordPress est très utilisé par des personnes peu techniques (c'est d'ailleurs une critique que l'on retrouve aussi à l'encontre de PHP). L'accessibilité de l'outil est à la fois un avantage et un inconvénient.
- Le manque de compétences techniques mène a des installations de WordPress qui ne sont pas sécurisées ou lentes. Et il n'y a rien de pire que d'avoir à réparer un site WordPress avec un thème qui a des centaines de fichiers qui ne suit aucune structure définie.
- L'écosystème est un mélange de très bon outils mais aussi d'outils mal conçus et il n'est pas évident de faire le tri entre le bon et le mauvais.
WordPress permet a des personnes qui ne sont pas développeur de concevoir des sites web ce qui ne plait pas forcément à certains développeurs (il y a un certain élitisme).
Pourquoi l'utiliser ?
Avec tout ce que je viens de dire, on peut alors se demander pourquoi utiliser WordPress comme solution pour créer un site. Au final, WordPress est avant tout un outil qui répond à un besoin spécifique, besoin qui n'est pas forcément couvert par d'autres outils. Comme souvent, le problème vient du fait que l'on a tendance à voir un outil comme une solution miracle pour tous les problèmes.
WordPress s'avère très efficace si on souhaite mettre en place un site vitrine où l'administrateur sera autonome dans la gestion des contenus. En revanche, ce n'est pas une solution pérenne pour un site dynamique qui devra évoluer dans le temps (on peut, mais ça ne veux pas dire que l'on doit le faire pour autant).
