WordPress, je t’aime mais…

Attendez, je ne vais pas tout vous dévoiler tout de suite !

Retour en 2003, Matt Mullenweg et Mike Little corrigent quelques bugs d’un logiciel open-source nommé B2. Ils en profitent pour ajouter quelques fonctionnalités et renommer le projet.

WordPress est né.

18 ans plus tard, désolé je ne suis pas un grand historien… 😅 WordPress a toutes les caractéristiques d’un dinosaure : il est imposant et plus tout jeune.

Vieux par son code, sa dette technique, ses bonnes pratiques en retrait de celles envisagées dans nos métiers. Et mastodonte par sa communauté et sa démocratisation, les dernières stats du moment annonce 43% du Web mine de rien…

Et les standards du Web, alors ?

Quand WordPress s’accorde à être inclusif, respecter un bon nombre de standards au niveau accessibilité et j’en passe. Malheureusement, on ne peut pas en dire autant quant à la base de code du cœur… L’écosystème de PHP a beaucoup évolué depuis les premières versions de notre cher et tendre CMS, et pourtant c’est pas du moteur de WordPress.

À commencer par le plus important selon moi :

La gestion des dépendances avec WordPress

Déjà près de 10 ans que composer existe, il s’agit d’un logiciel de gestion de dépendances écrit en PHP.

Et pour autant, il faut faire des pieds et des mains avant de pouvoir installer WordPress avec composer. Et je ne vous parle pas des plugins qu’il faut aller chercher sur wpackagist.org car pas compatibles avec Packagist (le repertoire officiel lié à composer ou toute libraire digne de ce nom se trouve).

Est-ce que les extensions sont considérées comme des dépendances de WordPress, du coup ? Pas vraiment…

⚠️ Spoiler alerte !

Impossible de gérer les dépendances de manière fiable sans devoir les préfixer dans son application WordPress, thème ou plugin.

Pourquoi ?

Si vous avez le malheur d’utiliser une bibliothèque PHP qu’une autre extension ou thème WordPress embarque, alors qui vous assure qu’elle sera dans la même version que ce que vous avez besoin ? Laquelle sera chargée en 1^ère entre les deux ?

C’est vite un micmac ingérable.

Une solution simple, qui est en réalité pas si simple mais bref : préfixez vos dépendances. Il existe des outils comme php-scoper ou mozart qui vous ferons vite perdre quelques cheveux. Mais, une fois en place, vous êtes cloisonné et safe en ce qui concerne de potentiels conflits entre les différentes versions des bibliothèques utilisées dans votre application WordPress.

C’est bien beaucoup d’effort à fournir là où composer sait gérer tout ça nativement…

Composer s’appuie sur les standards PSR, PHP Standards Recommandations, ils sont au nombre de 13 au moment où j’écris ces lignes et forment un pot commun de bonnes pratiques pour les dév. PHP, mais WordPress ne les suit pas.

Le choix délibéré de ne pas suivre les standards PHP

Bien que discutable WordPress à fait le choix d’avoir ses propres Coding Standards.

Mon point de vue est mitigé mais reste neutre tant que la communauté continue de maintenir les différents outils qui permettent le linting et le fix du code que l’ont produit. Un·e développeur·se ne devrait pas s’attarder sur la forme : convention de nommage ou le vieux débat sur l’indentation est-ce qu’on utilise des tabs ou des espaces… Puérile !

Il me parait plus judicieux tout un chacun s’attarde un peu plus au fond :

• Comment est pensé mon code ?
• Quels sont les effets de bords ?
• Est-ce qu’il est facile à comprendre et réutiliser ?
• Quelle architecture adopter, pour quelle dette technique ?

Il existe tellement d’outils du coté des Design Pattern que je suis navré à chaque fois que je présente dans mes formations, dans quel ordre se charge WordPress.

Excusez-moi du peu, mais le code est à gerber… 🤮

Des global dans tout les sens, des require en veux-tu en voilà, des class avec des longueurs à n’en plus finir, je pourrais en faire une liste longue comme le bras mais là n’est pas le sujet. Je comprend que la volonté de WordPress outre la « rétro-compatibilité » qu’il défend haut et fort est de rester accessible pour les bidouilleurs.

Qu’on soit clair, je suis resté bidouilleur pendant très longtemps et je n’en veux à personne de l’être.

Là où tous les frameworks populaires font le choix de la modularité, et propose des boîtes à outils les plus petites possible, WordPress se contente d’un monolithe.

Là où pour les développeur·se·s PHP aguerris les concepts d’interfaces, d’injection de dépendances, de services, d’autowiring, d’inversion de contrôle, de composition, etc. sont des basiques (une bonne partie empruntée à la Programmation Orientée Objet), chez WordPress, c’est inscrit aux abonnés absents.

C’est juste questionnant sur la capacité de gérer du code legacy et la résistance au changement que certains contributeur·rice·s ont essayé d’initier dans ce sens.

Les lacunes de WordPress

On sort un instant de la technique, on prend du recul, et en fait on se rend compte que certaines fonctionnalités indispensables pour un site Internet en 2022 n’y sont pas…

Pas de gestion du multilingue native

Bien que déjà identifié par la communauté depuis un certain temps. Bien des efforts sont fait pour palier ce soucis par des plugins comme Polylang ou encore Weglot qui ont des approches fondamentalement différentes. Mais nativement que dalle !

On me dit dans l’oreillette que Gutenberg va s’attaquer au problème dans la phase 4 du projet. Hâte de suivre les avancées sur le sujet en tout cas !

Je reviendrais sur les bienfaits qu’apporte cet éditeur dans l’écosystème WordPress.

Où sont les formulaires ?

Certains puristes WordPress me diront qu’avec les fichiers admin-post.php ou admin-ajax.php c’est possible. C’est vrai !

Mais… parce qu’il y a un mais…

Pourquoi chargé tout WordPress, La Boucle et j’en passe pour pouvoir traiter un formulaire ? Pourquoi ne pas avoir d’API digne de ce nom pour gérer la validation et les potentiels retours d’erreurs pour l’utilisateur final de votre site ?

Beaucoup d’interrogations où chaque agence a son mot à dire, ses préférences et sa manière à elle de gérer les choses.

Le grand absent est… le SEO !

Bien que des efforts ont été fait depuis août 2020 et la version 5.5.0 pour exposer des sitemaps XML. C’est triste de constater qu’en 2022 on en soit encore à installer Yoast pour avoir une interface pour gérer les <title> et la meta description de chaque page ou en exclure certaines de l’indexation et autres joyeuseté pour optimiser son site pour les moteurs de recherche.

À quoi bon continuer d’utiliser WordPress alors ?

Bon après avoir planté quelques javelots, j’en viens au pourquoi du comment il reste pertinent :

• La facilité de mise en place ;
• La gratuité ;
• L’interface ;
• L’abondance de ressources, de plugins, de thèmes mis à disposition par la communauté ;

Ça en fait un outil full personnalisable, et quoi qu’on en pense ça reste le CMS le plus utilisé au monde sans doute grâce ça.

Même Mme. Michu connaît WordPress !

Et si vous deviez redévelopper toutes les fonctionnalités de WordPress from scratch, ça demande un certain investissement (temps, compétences, etc.).

Gutenberg : la lumière au bout du tunnel

Bien que controversé dès son arrivée en décembre 2018, il a bousculé les habitudes de chacun c’est sûr, alors qu’il a fédérer autour de lui toutes les personnes déjà adepte du modulaire.

Une seule chose à comprendre pour toutes les comprendre

Qu’on les appelle atomes, symboles, objets ou composants en fonction des métiers on parle en réalité de la même chose !

L’éditeur à décider de nommer ça : des blocs. Why not !

Nous voilà bien garni… enfin un outil pour réconcilier le dialogue entre les métiers et un nouveau support pour se concentrer sur le contenu.

---

D’autres concepts aussi importants viennent enrichir les possibilités qu’elles soient créatives ou techniques :

• Blocs réutilisables (contenus synchronisés)
• Styles de bloc (variantes graphiques)
• Variations de bloc (pré-réglages de bloc)
• Composition de blocs (modèles de mise page)

C’est comme des super-pouvoirs, mais pour les blocs.

C’est pas le sujet de les détailler ici, mais quelle finesse on obtient lorsqu’on les maîtrise, vraiment !

L’arrivée du Full Site Editing

Bon même si pour certains le concept de Full Site Editing est encore nouveau, je dois avouer que de mon coté, j’ai deja adopté l’approche.

Modifier l’entièreté de son site avec de simple blocs, c’est presque trop facile.

Et bien qu’il embarque son lot de fonctionnalités et par conséquent vient alourdir visuellement l’interface. Ce que je trouve bien pensé dès le départ, c’est que tout soit options.

Mes clients n’ont pas besoin d’aller inventer une couleur ou un style de texte sorti du chapeau, s’ils ont une charte bien définie. Alors, nous désactivons les éléments d’interface au fur et à mesure ou nous leur définissons des règles d’usage.

L’objectif est simple, une fois dans l’éditeur mes clients n’ont qu’une chose à penser : raconter leur métier de la plus belle des manières.

Ce sont rarement des pro de la mise en page donc on leur enlève le doute.
Et trop de choix, tue le choix !

On leur propose des blocs, des combinaisons de blocs et des modèles de pages que nous avons étudiez spécifiquement pour eux.

Cette manière de construire les sites rebat les carte sur nos différents métiers. Et j’ai l’impression que les agences vont se recentrer sur le conseil et l’accompagnement et bien moins sur la prod grâce à cette manière de penser les sites.

Une stack technique moderne

Ah, reparlons un peu de tech !

Un de mes constat sans doute assez simple, c’est que Gutenberg a apporté une stack technique dans l’ère du temps et a forcer WordPress a se mettre (un petit peu) à la page.

Beaucoup d’évolutions sur l’API ont fleurit grâce aux contraintes de l’éditeur. Et le rythme de publication des releases me fait toujours autant halluciner. À titre de comparaison pour une mise à jour de WordPress on en entre 4 et 6 dans le même lapse de temps pour Gutenberg.

Ce projet d’éditeur open-source a ouvert ses portes aux développeur·se·s JavaScript. C’est React.js qui propulse Gutenberg.

Et entre nous, qu’on préfère Angular ou Vue.js à React.js c’est une chose mais admettez que ça reste une techno qui vit dans son temps au moins.

Cette approche par composant apporte un éditeur agnostique de son CMS. Oui oui, j’ai pas peur de le dire Gutenberg peut être utiliser de manière détachée de WordPress et peut se brancher sur n’importe quel back-end.

Ça fera sans doute l’objet d’un tutoriel à part entière. Si y’en a qui veulent s’y tenter voici pas où commencer :

Coupez lui la tête à ce CMS !

Tiens la mode du headless on en parle ?

Le 1^er avantage est selon moi de découpler votre CMS (WordPress ou autre hein je suis pas sectaire) et donc la saisie de contenu, la connexion au back-office etc. de votre front-end.

Libre à chaque métier de s’exprimer dans son état de l’art.

Utilisez l’API de WordPress

Un peu de REST par-ci

Par défaut, WordPress expose une API REST que l’on peut déjà consommer avec n’importe que client JavaScript.

Et comme les développeur de la team Gutenberg sont cools, ils en ont fait un composant, comme de par hasard. Ils utilisent le composant API Fetch pour interagir avec l’API de WordPress : https://github.com/WordPress/gutenberg/tree/trunk/packages/api-fetch

Pratique !

Un peu de GraphQL par-là

Il existe un certain Jason Bahl qui a usé d’huile de coude pour nous pondre une extension WPGraphQL.

Comme son nom l’indique il ne s’agit pas d’un gâteau au chocolat mais bien d’une extension fournit une manière différente d’appeler l’API de WordPress au format GraphQL donc !

On y gagne quoi ?

• + de performance (cf. source wpgraphql.com)
• récupérer des ressources imbriquées en un coup
  (au lieu de faire plusieurs appels API différents via REST)
• récupérer uniquement les données dont on a besoin

J’avoue que j’utilise très peu GraphQL donc je n’ai listé que les points qui me paraissent pertinent à mon échelle.

Le plugin est disponible sur le repertoire officiel de WordPress:

Qui dit Headless, dit génération statique des pages

Alors déjà non… tous les sites ne sont pas adapté à ce type de rendu. Et même avec un peu plus de granularité toutes les pages ne sont pas faite pour être pré-générées.

À l’inverse c’est indéniable que le SSG (Static Generation) apporte des performances inégalables.

Comment ça marche ?

En version simplifié, vous générer vos pages en avance, quand vous buildez votre application JavaScript. Les différentes requêtes en bases de données sont faites à ce moment là. Le résultat de cette génération sont des fichiers HTML.

Et comme vous vous en doutez ce sont fichiers qui sont affichés à vos visiteurs, quoi de plus rapide ?

Au revoir les plugins de cache, vous faites déjà leur job ! Enfin, en partie calmez-vous.

---

Vous avez peut-être aussi vu d’autres noms d’oiseau comme SSR, ou ISR. Ce sont des stratégies différentes pour afficher les pages de votre site quand vous utilisez des framework comme Next.js ou Gatbsy :

• SSR : Server Side Rendering, vous faites appel à votre serveur qu’au moment d’une visite
  (comme par défaut dans votre thème WordPress, c’est PHP qui est exécuté par votre serveur et affiche le modèle de page correspondant)
• ISR : Incremental Static Regeneration, vous générez vos pages de manière statique qu’une fois qu’elle sont visité. Votre 1er visiteur aura donc une page chargé via SSR puis le suivant les bénéfices du SSG (Static Generation).

C’est tout un monde de jargon avec lequel il faut se familiariser mais le champ des possibles est énorme. Vous pouvez ainsi bénéficier de toute la puissance des applications JavaScript aussi appelé SPA (Single Page Application), mais pour votre site.

---

Pour en terminer avec mon monologue, je jette facilement la pierre sur un outil que j’utilise pourtant tous les jours. Je suis juste déçu de voir des écosystèmes aussi riche et mature techniquement que celui de Symfony, pour ne prendre que celui-là en exemple, ne pas profiter à celui de WordPress avec comme excuse la plupart du temps : la rétro-compatibilité.