Le WordPress d'aujourd'hui, décodé pour les développeurs

Éditeur de site (FSE)

Reprendre un site FSE livré deux ans plus tôt, jamais revu : ce qu’on y trouve

Un site construit fin 2021 avec l'extension Gutenberg en mode expérimental, jamais retouché depuis : voici ce qu'une reprise révèle, entre dette technique et bonnes surprises.

Par WordPress Développement • 5 août 2023 • 4 min de lecture • Aucun commentaire
Reprendre un site FSE livré deux ans plus tôt, jamais revu : ce qu'on y trouve

Zéro mise à jour en quatorze mois : c’est le premier constat en ouvrant le tableau de bord de ce site, confié fin 2021 à une petite structure qui produit des accessoires en tapisserie d’ameublement. À l’époque, l’éditeur de site n’existait pas encore dans le cœur de WordPress — la version stable qui l’a intégré, la 5.9, ne sortirait qu’en janvier 2022 — et le prestataire d’alors avait construit le site avec l’extension Gutenberg activée en mode expérimental, une pratique courante à ce moment pour qui voulait anticiper l’arrivée de l’éditeur de site sans attendre sa stabilisation.

Reprendre ce type de projet pose une question précise avant toute autre : le thème a-t-il été mis à jour pour suivre la stabilisation de la fonctionnalité, ou est-il resté figé sur son état expérimental d’origine ? La réponse détermine tout le reste de l’audit.

Premier réflexe : la version de theme.json

Le fichier theme.json du thème indiquait "version": 1. Cette version correspond au format expérimental d’avant la stabilisation de juillet 2021 ; le format stable utilise la version 2, avec des clés renommées et une structure légèrement différente pour les réglages d’espacement. Le thème fonctionnait toujours, WordPress conservant une rétrocompatibilité pour la version 1, mais aucun des réglages ajoutés depuis à la version 2 — les tailles de police fluides, notamment — n’était disponible sans une mise à niveau du fichier.

Ce que l’inventaire a révélé

L'essentiel à retenir : Un site expérimental de 2021 n'a pas toujours suivi la stabilisation de WordPress 5.9 ; Les patterns codés en dur cachent souvent une dépendance oubliée ; Vérifier la version de theme.json avant tout autre diagnostic

L’audit du thème a fait remonter plusieurs traces caractéristiques d’un projet construit à cette période charnière :

  • des templates .html qui référençaient un template part header.html par un chemin construit à la main, plutôt que par le bloc Template Part devenu standard ensuite ;
  • un fichier functions.php contenant encore des appels à add_theme_support( 'wp-block-styles' ), un support devenu implicite dans les thèmes de blocs stabilisés ;
  • aucune trace de patterns enregistrés via register_block_pattern() : les mises en page répétées avaient été dupliquées manuellement dans chaque page, faute d’existence de cette API généralisée au moment de la construction.

Le piège du thème qui « marche encore »

Le site s’affichait normalement, ce qui a longtemps rassuré la cliente sur l’absence de problème. Mais un thème resté figé sur un format expérimental accumule un risque latent : chaque montée de version majeure de WordPress conserve la rétrocompatibilité un temps, sans garantie qu’elle dure indéfiniment. Attendre la panne pour agir revient à parier sur une date de dépréciation qu’aucune annonce officielle ne fixe à l’avance avec précision.

La mise à niveau retenue

Plutôt qu’une reconstruction complète, nous avons choisi une migration progressive : conversion du theme.json vers la version 2 à l’aide de la documentation officielle des changements de schéma, remplacement des chemins de template parts codés en dur par les blocs correspondants, puis extraction des mises en page répétées en patterns enregistrés côté thème. Cette approche a permis de conserver l’identité visuelle existante, validée par la cliente, sans repartir d’une page blanche.

// Avant : version 1, structure expérimentale
{
  "version": 1,
  "settings": {
    "typography": {
      "fontSizes": [
        { "slug": "normal", "size": "16px" }
      ]
    }
  }
}

// Après : version 2, structure stabilisée
{
  "version": 2,
  "settings": {
    "typography": {
      "fontSizes": [
        { "slug": "normal", "size": "16px", "name": "Normal" }
      ]
    }
  }
}

Face à un thème expérimental jamais mis à jour, nous commençons toujours par dater précisément sa construction plutôt que par juger son état actuel : cela évite de reprocher au prestataire précédent des choix qui étaient, à l’époque, les seuls disponibles.

Notre verdict

Ce projet n’était pas mal construit pour son époque ; il était simplement resté figé alors que la fonctionnalité qu’il exploitait continuait d’évoluer autour de lui. La leçon la plus utile de cette reprise ne porte pas sur le code retrouvé, mais sur la nécessité de dater tout ce qu’on découvre avant de le juger : un choix expérimental de fin 2021 n’est pas une erreur, c’est un instantané d’une fonctionnalité encore en mouvement.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Partager :

À propos de l'auteur

WordPress Développement

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi