Le 15 juillet, en même temps que la sortie de la version de maintenance 6.8.2 que j’ai eu le plaisir de diriger, plusieurs anciennes versions de WordPress ont été abandonnées à leur triste sort.
Âgées de 9 à 11 ans, les branches 4.1 à 4.6 ont en effet connues leur ultime mise à jour, qui consiste simplement en l’affichage d’un message indiquant sur le tableau de bord que la version ne recevra plus aucune mise à jour de sécurité [1].
Au sein de la Security Team de WordPress, nous avons préparé cet abandon avec soin, car nous savons aussi que propulsant plus de 40% du web, ce projet open source ne doit pas prendre ce type de décision à la légère.
Des versions anciennes de WordPress qui ne devraient plus être utilisées
Ces versions 4.1 à 4.6 datent de 2014 à 2016.
10 ans sont passés et il est évident qu’elles ne devraient plus être utilisées. Mais si l’on suit les statistiques d’utilisation [2] de ces versions, elles représentent tout de même un nombre conséquent d’installations.
Si l’on fait un rapide calcul en partant du fait que WordPress propulse 40% (fourchette basse) du top 10 millions de sites web et que les versions 4.1 à 4.6 représentent 0,86% de l’ensemble, cela donne au minimum 50 000 sites qui n’auront plus aucune mise à jour de sécurité.
Bien entendu, nombre de ces sites ne sont plus utilisés depuis belle lurette, mais ce sont toujours des questions que nous nous posons lorsque nous abandonnons le « support » d’autant de sites d’un coup.
Une bonne partie d’entre eux sont déjà sans doute des sites « zombies » ayant été abandonnés puis piratés suite à l’absence de mise à jour d’une extension ou d’un thème, mais quand bien même, il doit aussi rester quelques milliers de sites proposant un contenu pertinent et légitime…
Il y a quelques années nous avions avec la Security Team proposé publiquement de forcer la mise à niveau de ces vieilles version vers la version supérieure la plus proche qui soit encore maintenue [3]. C’est une possibilité technique, mais qui a été jugée inacceptable par la communauté, car cela implique pour WordPress de décider unilatéralement d’effectuer une modification non demandée à l’époque où le site a été créé. Cela pose par ailleurs une question de responsabilité au cas où le site casse suite à la mise à niveau. Cette possibilité technique a donc été abandonnée au profit d’une simple dépréciation, avec affichage d’un encart indiquant clairement que le site est en danger.
La tradition de la rétrocompatibilité chez WordPress, pour le meilleur et pour le pire !
Depuis la version 3.7 et l’arrivée des mises à jour automatiques du CMS, le projet WordPress a toujours tenu à être exemplaire en terme de rétrocompatibilité.
Le système de versioning de WordPres en est d’ailleurs la preuve la plus immédiate : les versions majeures sont indiquées par les deux premiers chiffres du numéro de version. Par exemple, si la version de WordPress ayant amené l’éditeur de blocs Gutenberg est un chiffre rond (5.0), la version qui a apporté l’édition complète du site (FSE) est la version 5.9, et pas 6.0. Les versions 4.9, 5.0, 5.1 ou 6.8 sont toutes des versions majeures, ce n’est que le troisième chiffre qui indique une version mineure.
Dans tous les cas chez WP, un changement de version majeure n’indiquera jamais une rupture de compatibilité. Toutes les versions sont compatibles les unes avec les autres. La compatibilité lors de la mise à niveau est un des principes de base de la philosophie de notre CMS.
Par contre, il n’est pas viable en terme de politique de maintenance de rester sur une ancienne version de WordPress au motif que celle-ci serait toujours « supportée ».
Chez WordPress, la rétrocompabilité est dite « de courtoisie », c’est à dire que les versions précédentes font l’objet de correctifs de sécurité, mais jamais d’évolutions et très rarement de corrections fonctionnelles. Il n’existe pas de LTS (long time support) comme sur d’autres projets open source.
La seule branche activement maintenue restera toujours la version majeure courante.
Plus il y a d’anciennes versions à maintenir, plus il y a d’inertie sur le déploiement des correctifs de sécurité
Il faut savoir que déployer un correctif de sécurité sur WordPress nécessite plusieurs dizaines (voire centaines) d’heures. Je ne parle ici bien sûr que du temps de déploiement, pas de la création du correctif de sécurité lui même.
Actuellement, lorsqu’un correctif de sécurité est validé, nous devons le déployer sur toutes les branches de 4.1 à 6.8. Cela représente donc 28 versions de WordPress à sortir par correctif ! En effet, chaque branche maintenue doit être dûement testée et approuvée. Autant dire qu’il s’agit d’une tâche très consommatrice de ressources humaines, au détriment de l’avancée d’autres projets.
Il serait donc utile de réduire le nombre de versions supportées, idéalement en ne supportant que les 10 dernières versions majeures, ou les versions sorties les 3 années précédentes (ce qui revient à peu près au même).
Prochaine étape : le bottleneck de WordPress 4.9
C’est un sujet que j’ai évoqué lors du dernier Core Committer Check-in, la réunion mensuelle en visio-conférence de l’équipe principale de développement du projet WordPress. WordPress 4.9 est la version ayant précédé l’arrivée du projet Gutenberg dans la version 5.0, qui a été pour beaucoup de personnes une version plus que majeure puisqu’elle introduisait un changement de paradigme dans la rédaction de contenus sur le CMS.
Cela n’avait cependant rien d’une rupture de rétrocompatibilité : une extension nommée Classic Editor permet de conserver l’ancien éditeur de contenus malgré le passage aux version 5.0 et suivantes. Malheureusement, un grand nombre de sites sont restés sur la branche 4.9, alors qu’il suffit d’installer l’extension proposée pour continuer à utiliser l’ancien éditeur (et c’est d’ailleurs toujours le cas 7 ans plus tard).
Le résultat est qu’il reste environ 1,5% de sites bloqués sur la version 4.9. Le défi de l’équipe Core et de l’équipe Security de WordPress est donc d’arriver à trouver comment faire basculer ces sites vers de versions plus récentes. Plusieurs pistes sont évoquées, notamment l’apparition d’un message plus prédominant sur l’administration pour inviter à effectuer une mise à jour. Affaire à suivre.
Notes :
Laisser un commentaire