Bilan de l’année pour WordPress

À la fin de 2017, nous avons recensé 11 versions publiques de WordPress et 11 autres versions bêta. Pour les proches de la communauté WordPress comme pour les simples observateurs, il est clair que cette communauté a désormais une ampleur considérable.

Les améliorations semblaient se répartir en deux grandes catégories : les unes pour les développeurs, les autres pour les rédacteurs.
Voyons en détail ce qui s’est passé pour WordPress en 2017, selon ces deux orientations de développement :

Améliorations pour les Développeurs

En 2017, les améliorations semblent avoir suivi deux voies : faciliter la vie des développeurs et celle des rédacteurs. Pour les développeurs, les progrès de l’API REST ont été décisifs. Les utilisateurs attendent toujours plus de rapidité et de fluidité des sites qu’ils consultent. Le « Headless WordPress » commence déjà à s’imposer, donnant une importance considérable à l’API REST. Examinons en détail ses améliorations au cours de l’année écoulée :

• Décembre 2016 – WordPress7 « Vaughan » intègre désormais des points d’accès REST API pour les articles, les termes, les utilisateurs, les métadonnées et les réglages.
• Janvier 2017 – Publication d’une mise à jour de sécurité qui corrige un problème concernant les informations des auteurs
• Avril 2017 – Nouvellesaméliorations de l’API REST pour les recherches de plusieurs termes et d’utilisateurs, ainsi que pour les utilisateurs de différents fuseaux horaires.
• Mai 2017 – Correctifs permettant aux développeurs de se connecter à plusieurs points d’accès simultanément.
• Publication de WordPress8 « Evans », avec notamment un widget multimédia de base utilisant le schéma de l’API REST
• Août 2017 – Publication de la version 4.8.1 avecplusieurs améliorations du traitement des données, des images et des jetons de l’API REST.
• Novembre 2017 – Publication de WordPress9 « Tipton », avec plusieurs améliorations de l’outil de personnalisation, dont la toute nouvelleCustomizer JS API.

Améliorations pour les Rédacteurs

Le plus grand chantier depuis la création de WordPress est lancé : il s’appelle le projet Gutenberg.

Dans sa description du projet Gutenberg, Matias fait aussi référence à la Grèce en le comparant au bateau de Thésée.

Le projet Gutenberg est venu combler une importante lacune de WordPress pour les rédacteurs. Alors que WordPress continuait à évoluer et à innover, son éditeur stagnait. Les extensions et les thèmes se sont donc multipliés en devenant dépendants des codes courts ou, pire encore, en nécessitant l’intervention du créateur du site pour des tâches simples.

Gutenberg a été créé pour rendre l’édition de texte plus agréable aux auteurs. Il cherche à rapprocher l’édition dans l’administration de l’apparence publique, donnant aux créateurs davantage de liberté pour produire de meilleurs contenus.

Sa création a nécessité la collaboration de très nombreux membres de la communauté et d’innombrables contributeurs. Gutenberg est disponible pour tous sous forme d’extension, avec plus de 500 téléchargements par jour. Avant sa publication comme extension en juin 2017, il avait déjà connu 6 mois de développement et a reçu depuis 25 mises à jour majeures. Les voici en détail :

• 16 juin : v1.0 – Première publication comme extension 23 juin : v0.2.0 – Ajout des blocs
• 30 juin : v3.0 – Correctifs supplémentaires de mise en forme et ajout de boutons
• 8 juillet : v4.0 – Correctifs côté serveur et prise en charge accrue des API
• 14 juillet : v5.0 – Prise en charge de plusieurs navigateurs et plateformes mobiles
• 28 juillet : v6.0 – Ajouts liés au contenu et à l’expérience utilisateur
• 4 août : v7.0 – Accessibilité et améliorations de l’interface
• 4 août : v7.1 – Correctif urgent pour le formulaire de contact Jetpack
• 11 août : v8.0 – Nouveaux blocs pour différents médias et types de texte
• 18 août : v9.0 – Amélioration de la personnalisation des blocs et des couleurs
• 29 août : v0.0 – Amélioration du glisser-déposer et des menus déroulants
• 5 septembre : v1.0 – Correctifs et améliorations des interactions entre blocs
• 27 septembre : v2.0 – Ajout d’un compteur de mots et de blocs
• 27 septembre : v2.1 – Correctif urgent pour les blocs non cliquables
• 4 octobre : v3.0 – Simplification de l’affichage et des descriptions des blocs
• 10 octobre : v1.4.0 – Structure REST API initiale pour les blocs globaux réutilisables
• 24 octobre : v1.5.0 – Prise en charge native des métaboxes dans les métaboxes existantes
• 24 octobre : v5.1 – Correctif urgent pour le redimensionnement de l’écran dans Firefox
• 25 octobre : v5.2 – Correctifs urgents des problèmes de redirection de l’éditeur classique
• 31 octobre : v6.0 – Correctifs de performances et conversion des blocs classiques en blocs Gutenberg
• 2 novembre : v6.1 – Possibilité de coller des codes courts et blocs à conversion automatique
• 15 novembre : v7.0 – Amélioration de l’extensibilité des blocs par filtres et hooks
• 28 novembre : v8.0 – Correctifs et améliorations du traitement des codes courts
• 29 novembre : v8.1 – Ajout de la possibilité de remettre un article publié à l’état de brouillon
• 11 décembre : v1.9.0 – Hooks et hooks globaux réutilisables
• 13 décembre : v9.1 – Correctifs pour Firefox et l’extension Yoast SEO

Ces versions sont le fruit d’un immense effort collectif pour faire de Gutenberg ce qu’il est aujourd’hui. Le seul point sombre est que si l’ensemble de la communauté s’accorde sur le besoin d’un meilleur éditeur, ce consensus ne concerne pas la manière de le mettre en œuvre.

Ce que produit cette méthode de développement

Il est remarquable qu’aucun moyen n’ait été trouvé pour concilier ces deux orientations. Au cours de l’année, Chris Lema s’interrogeait : « Ne voulions-nous pas montrer que WordPress était plus qu’une plateforme de blogs ? » Beaucoup affirment que l’accent mis sur la refonte de l’éditeur de contenu s’oppose entièrement à la voie ouverte par l’API REST aux développeurs.

L’API REST permet aux développeurs d’innover davantage dans un monde privilégiant le mobile, théoriquement celui de demain. Pourtant, Gutenberg n’est pas entièrement compatible avec elle, du moins à ce jour.

Les pages créées avec Gutenberg incluent du CSS et du JavaScript. Les développeurs doivent donc intégrer le CSS de Gutenberg dans leur interface JavaScript ou écrire leur propre CSS pour reproduire ses styles. Beaucoup estiment que du CSS intégré serait la solution la plus adaptée et la plus compatible avec l’API REST. Nous savons que l’équipe Gutenberg entend lever ces obstacles au développement, mais ils ne sont toujours pas résolus à ce jour.

Comme une équipe

L’année écoulée se distingue aussi par les efforts importants visant à faciliter les flux de travail des développeurs et des rédacteurs. WordPress faisant fonctionner 29 % du web et 54 des 100 principaux sites, il doit clairement être adapté à ces équipes. Une fois encore, la communauté a travaillé comme une grande équipe unie.

WordPress 4.9 a apporté des changements très utiles aux deux groupes, comme l’enregistrement des modifications de design en brouillon et la détection d’erreurs lors des modifications de code. De son côté, l’API REST leur a permis de transformer une installation WordPress ordinaire en site Headless WordPress ou en application web progressive.

Avec maturité

Si vous suivez les développeurs du cœur de WordPress, vous avez peut-être aussi remarqué que le calendrier des versions a gagné en maturité ces deux dernières années. Sur les 22 versions WordPress de 2017, 11 étaient des versions bêta et/ou destinées aux développeurs. L’équipe publie rapidement des mises à jour de sécurité ou de maintenance sans aucun problème, en collaboration avec HackerOne. Les mises à jour sont publiées lorsque la communauté est prête, toujours après 2 à 3 versions bêta.

L’avenir

L’avenir de WordPress semble résolument placé sous le signe de la maturité. Chaque occasion donne lieu à des évolutions pour prendre en charge les technologies et expériences numériques futures. Des flux de travail simplifiés renforcent son intérêt pour les entreprises, tandis que l’API REST et Gutenberg ont ouvert la voie à un éventail d’usages plus large.

Le State of the Word 2017 a récemment annoncé une autre perspective intéressante : le projet Tide, qui utilisera des tests automatisés pour chaque extension et thème du dépôt WordPress. La collaboration a également été officiellement annoncée avec HackerOne – un réseau de hackers qui tentera de rendre WordPress à toute épreuve.

Nous espérons personnellement davantage de points d’accès REST API et d’innovations dans l’expérience des utilisateurs de mobiles et de tablettes. Bien sûr, nous attendons aussi que l’écart entre Gutenberg et l’API REST soit comblé avant WordPress 5.

Enfin, nous aimerions voir WordPress intégrer à ses fonctions de base de nombreuses fonctionnalités tierces, aujourd’hui proposées par des extensions, pour offrir des possibilités étendues dès le départ sans dépendances.

Une chose est sûre : nous attendons tous une superbe année 2018, pleine de belles surprises pour notre CMS préféré.