WordPress : tout savoir sur Full Site Editing, la prochaine évolution majeure du CMS

En quoi consiste le projet full site editing ? Quels sont ses objectifs, ses avantages ? Une alternative existe-t-elle pour les développeurs qui s’élèvent contre le principe de l’éditeur de blocs Gutenberg ? Jean-Baptiste Audras, représentant de l’équipe Core de WordPress, a répondu à nos questions.

site-editor-fse-wordpress-jean-baptiste-audras
Le menu Site editor, qui contiendra les fonctionnalités du FSE, ne sera disponible que si le thème est compatible. © Jean-Baptiste Audras / WordPress

Amorcé par le développement de l’éditeur Gutenberg, le projet full site editing (FSE) de WordPress, qui pourrait être lancé avec la version 5.8 en juillet prochain, constitue la nouvelle « expérience de gestion de site native » du CMS. Il permet de modifier et de personnaliser l’ensemble de l’interface d’un site à partir de blocs de contenus éditoriaux. Nous avons interrogé Jean-Baptiste Audras, CTO de l’agence Whodunit et représentant de l’équipe Core de WordPress, qui nous présente les avantages du FSE et répond aux nombreux questionnements sur cette évolution majeure du CMS.

Pouvez-vous nous présenter en quoi consiste full site editing (FSE) ? Quel est son objectif ?

Le point de départ du projet Gutenberg est de proposer une expérience d’administration plus homogène. Pour gérer un site WordPress, il était auparavant nécessaire d’apprendre beaucoup de concepts très différents les uns des autres : éditeur « classique », shortcodes, widgets, champs personnalisés, gestionnaire de menus… Le projet Gutenberg a pour but de proposer une expérience unifiée, car basée sur le principe du bloc, une unité éditoriale à partir de laquelle on peut gérer l’ensemble du site.

La première phase du projet fut de moderniser l’éditeur de contenu. Cela a été fait grâce à l’éditeur de blocs, qui est sorti fin 2018 avec WordPress 5.0. De nombreuses itérations ont été faites entre les versions 5.0 et 5.7 de WP. Nous disposons aujourd’hui d’un éditeur stable et d’un écosystème extrêmement riche grâce aux extensions et thèmes qui tirent profit de tout ce qu’apporte cet éditeur, et qui en retour en décuplent les possibilités.

Le full site editing (FSE) est la seconde phase du projet. Cette phase vise à permettre l’édition de l’ensemble de l’interface front-end du site, toujours à l’aide du concept de blocs éditoriaux.

Quels changements va-t-il apporter concrètement dans la manière de concevoir un site sur WordPress ? Pouvez-vous nous donner quelques exemples précis ?

Si l’éditeur de blocs se limite à la gestion du contenu de chaque publication, le full site editing permet de manipuler n’importe quel élément éditorial présent dans l’interface, tels que le header du site, ses menus de navigation, ses widgets, son footer, mais aussi les modèles de pages spécifiques du thème : page de liste des articles, page de résultats de recherche, page d’erreur 404, etc.

L’objectif est que le thème reste responsable de la charte graphique d’ensemble du site via ses feuilles de styles, tandis que la mise en page et l’agencement des éléments de contenus seront entièrement administrables via des blocs Gutenberg.

Ci-dessous, un exemple d’édition du pied de page d’un site via l’éditeur de site (full site editing). N’importe quel bloc Gutenberg peut être utilisé et paramétré, cela permet de concevoir un pied de page de zéro, tout en conservant tout de même la charte graphique générale du site, qui est définie par le thème utilisé.

© Jean-Baptiste Audras / WordPress

Quels sont les avantages du FSE, pour les utilisateurs à la recherche d’un site facilement personnalisable, et pour les développeurs de la communauté WordPress ?

L’objectif de ce projet est de donner aux utilisatrices et utilisateurs du CMS WordPress une maîtrise complète non seulement des contenus de leur site, mais aussi de son architecture éditoriale d’ensemble. Cela est déjà possible depuis longtemps car WordPress permet de gérer les menus, les widgets, et son outil de personnalisation (connu en anglais sous le nom de customizer) donne la possibilité aux thèmes de déclarer des éléments modifiables dans l’interface même du thème. Le full site editing apporte la possibilité de le faire avec une interface unifiée et un concept universel : celui du bloc éditorial. Les blocs Gutenberg peuvent être combinés entre eux pour former tous types d’agencements, tout en respectant la charte graphique définie par le thème utilisé.

Du côté des développeuses et des développeurs WordPress, cela entraîne quelques changements d’ampleur, car pour être compatibles avec le full site editing, les thèmes devront présenter une architecture spécifique, avec un fichier theme.json (ci-dessous, il est provisoirement nommé experimental-theme.json car nous sommes encore en phase de développement de la fonctionnalité), et des nouveaux fichiers modèles contenant la base HTML de chaque élément de l’interface, répartis dans les dossiers block-templates et block-template-parts).

© Jean-Baptiste Audras / WordPress

Il est clair qu’à la sortie du full site editing, seule une minorité de thèmes seront compatibles. Cela dit, une minorité de thèmes seulement étaient compatibles avec l’éditeur de blocs lors de sa sortie fin 2018, retard qui fut assez vite comblé par l’enthousiasme des auteurs de thèmes pour les possibilités offertes par Gutenberg. Avec l’éditeur de blocs, le projet Gutenberg a prouvé qu’il pouvait améliorer les capacités de WordPress en termes d’administration de contenu, de performances, d’accessibilité, de maintenabilité et d’universalité (en base de données, Gutenberg enregistre du code HTML standard, ce qui facilite énormément les opérations de migration).

Il est cependant important de noter que WordPress n’a pas forcément les mêmes objectifs que d’autres constructeurs de pages. Elementor propose par exemple d’aller beaucoup plus loin que Gutenberg sur le design des pages en proposant beaucoup d’options de mise en forme graphique. Ce n’est pas l’objectif de Gutenberg, qui se repose sur le thème pour ce qui concerne la charte graphique du site. C’est aussi, selon moi, ce qui fait la force de ce projet, en conservant une séparation entre la mise en forme (gérée par le thème) avec les contenus et leur mise en page (gérée via Gutenberg).

Avec Gutenberg et le principe du bloc éditorial, WordPress a ainsi pu basculer de plain-pied vers une vraie approche modulaire, facilitant l’utilisation de design systems dans la conception de sites par les agences et par les personnes qui développent des thèmes gratuits ou payants.

Comprenez-vous les critiques d’une partie de la communauté au sujet de cette nouvelle approche du CMS, amorcée avec l’intégration de Gutenberg ?

Toute critique constructive doit être écoutée. Et les craintes sont effectivement compréhensibles. D’une part, tout changement dans WordPress fait forcément naître de l’appréhension de la part des personnes qui ont investi du temps pour maîtriser l’utilisation de ce CMS. Tout changement d’ampleur nécessite donc un nouvel investissement de formation ou d’auto-formation. À nous de rendre cet apprentissage continu le moins complexe possible, en commençant par documenter l’utilisation du CMS. Je tiens d’ailleurs à faire une parenthèse pour indiquer que la communauté française est l’équipe de documentation la plus prolifique au niveau international dans l’écosystème. N’hésitez pas à la contacter si vous avez des questions et si vous souhaitez contribuer.

D’autre part, les agences web et éditeurs d’extensions sont aussi impactés par ces changements, et doivent monter en compétence. Cela représente également des investissements conséquents. Mon message pour les professionnels est simple : contribuez au projet avec des idées, du code… Ne vous cantonnez pas à un rôle de suiveur mais soyez acteur de la technologie dont dépend votre business. La communauté recevra toujours vos suggestions et retours avec bienveillance si vous en faites vous-même preuve. Il faut par ailleurs noter que la culture de la rétrocompatibilité entretenue par le projet WordPress n’est plus à démontrer. Cela permet de proposer un certain nombre de garanties aux uns et aux autres.

Enfin, la capacité d’innovation du projet WordPress démontre aussi sa vitalité, ce que semblent valider les parts de marché du CMS. Les évolutions majeures sont donc inévitables tout autant qu’indispensables.

FSE sera-t-il en concurrence directe avec des plugins et des thèmes premium, comme Elementor ou Divi ? Si oui, pourquoi ?

Le full site editing va devenir l’expérience de gestion de site native de WordPress. Mais la présence de cette expérience éditoriale sera conditionnée à sa prise en charge par le thème du site et par ses extensions.

Dans un premier temps, les constructeurs de pages vont probablement tout simplement désactiver le full site editing pour ne conserver que leurs outils à eux. C’est compréhensible et cela ne pose pas de problème à court terme, puisqu’il faudra de toute façon attendre quelque temps avant qu’une grande partie des thèmes et extensions soit complètement compatible avec le full site editing.

Dans un second temps, il est probable qu’une partie des sociétés éditant les gros thèmes et constructeurs de pages du marché finisse par se baser sur le full site editing pour proposer une expérience enrichie. Le full site editing a l’avantage d’être intégré au Core WP. Mais il ne pourra pas répondre à tous les besoins spécifiques. C’est là que l’écosystème entre en jeu : les extensions et thèmes bâtiront sur cette base pour proposer une expérience répondant à toujours davantage de besoins.

Comment WordPress peut-il rassurer et convaincre les développeurs, qui ne souhaitent pas intégrer l’éditeur de blocs Gutenberg ? Une alternative sera-t-elle disponible ?

WordPress a une grande tradition de respect de la rétrocompatibilité. C’est ce qui fait sa spécificité dans l’offre de CMS disponible sur le marché. Il faut savoir que les écrans de l’éditeur de site qui contiennent les fonctionnalités du full site editing ne seront disponibles que si le thème est compatible FSE. Si votre thème ne déclare pas de templates compatibles avec le full site editing, la fonctionnalité ne sera tout simplement pas affichée.

Bien entendu, les développeuses et développeurs sont encouragés à rendre leurs produits et travaux compatibles dès que possible, puisqu’il s’agit de l’avenir à moyen terme du CMS. Comme en 2018-2019 avec l’arrivée de la phase 1 de Gutenberg : ceux qui ont rendu conformes leurs développements dès le départ ont pu monter en compétence sur les technologies et concepts utilisés par Gutenberg au fur et à mesure de son développement, alors que ceux qui s’y sont mis sur le tard ont accumulé un retard technique plus difficile à combler par la suite.

Même s’ils utilisent au quotidien d’autres constructeurs de pages comme Elementor, nous recommandons fortement aux professionnels de suivre les développements de Gutenberg et de WordPress en général, car c’est une question de maîtrise de la technologie dont on dépend.

Mais à court terme, pas d’inquiétude ! La fonctionnalité de full site editing ne sera tout simplement pas disponible sur votre site si votre thème ne propose pas de fichiers modèles (templates) modifiables. Il n’y aura a priori nul besoin d’extension particulière pour désactiver cette fonctionnalité.

Pourquoi WordPress souhaite-t-il accélérer maintenant l’intégration de FSE dans le core du CMS, avec une possible intégration dès la prochaine version 5.8 prévue pour le 20 juillet prochain ?

L’implémentation dans WordPress 5.8 est conditionnée à l’avancée du projet dans les prochains jours. Elle n’est pas encore certaine à 100 %, mais elle est de plus en plus probable. Dans tous les cas, il faut savoir que le full site editing est davantage un ensemble de projets qu’un projet unique qui sortirait d’un seul coup. L’implémentation de l’ensemble du projet prendra sans doute plusieurs versions de WP. Une première validation du projet d’implémentation pour WP 5.8 s’est déroulée le 14 avril et a conclu à l’absence de problème bloquant. La seconde validation aura lieu le 27 avril prochain.

Voici par exemple les projets full site editing actuellement discutés pour intégration (ou non) dans WP 5.8 :

  • rendre possible la construction de thèmes compatibles avec le full site editing à l’aide du fichier de configuration theme.json,
  • mise en place des blocs indispensables à la création des fichiers modèles de base de n’importe quel thème WP : bloc de gestion du logo du site, bloc d’affichage de listes de publications (Query block), etc.,
  • gestionnaire de widgets à l’aide de blocs Gutenberg,
  • bloc d’affichage des menus de navigation.
Sujets liés :
2 commentaires
Commentaires (2)
  • Bernardo

    Gutenberg est une catastrophe pour les créateurs de site qui veulent pousser juste un peu le design et les fonctionnalités de wordpress.
    Que va donner cette nouvelle mouture, je suis très sceptique. Ne vaudrait il mieux pas se focaliser sur des évolutions spécifiques comme woo commerce qui est très belle reussite. Le moteur n’est toujours pas multilingue nativement, c’est très dommage, et il y a plein de fonctionnalités intéressantes à pousser.
    En terme de référencement et de customisation ux il y aurait aussi beaucoup à faire. Je vois tous les jours les limites de wordpress vis à vis du seo. Le cœur stratégique d’un site performant…

  • Julien H

    Enfin ! Enfin nous allons avoir la main sur la modification bdes blocs de façon plus simple que de passer par l’ensemble des poupées russes du templates… Bravo !

Ajouter un commentaire

Votre adresse email ne sera pas publiée.

Les meilleurs outils CMS