Le 20 juillet 2021, WordPress 5.8 remplace l’écran classique de gestion des widgets par un éditeur de blocs à part entière. Ce changement, présenté avant tout comme une amélioration d’ergonomie, a des conséquences directes et peu documentées sur les sites multilingues dont les barres latérales affichent un contenu différent selon la langue active.
Avant cette version, un widget classique était un simple réglage stocké en base, largement indépendant de la langue : seule son contenu textuel changeait selon les extensions de traduction de chaînes utilisées. Avec les widgets blocs, chaque bloc devient un contenu structuré à part entière, ce qui change la donne pour toute extension multilingue gérant des barres latérales distinctes par langue.
Ce qui change concrètement dans la structure des widgets
Les widgets ne sont plus stockés comme de simples options sérialisées, mais comme un contenu de blocs assimilable à celui d’un article, rattaché à une zone de widgets donnée. Sur un site utilisant Polylang avec l’option de traduction des widgets activée, chaque zone existe désormais potentiellement en autant de versions que de langues, chacune composée de ses propres blocs :
- un bloc « Derniers articles » configuré dans la barre latérale française n’est plus automatiquement disponible dans la version anglaise
- la disposition des blocs (ordre, réglages individuels) doit être reconstruite manuellement, langue par langue, lors de la première migration
- un bloc de requête personnalisé, filtré par langue, doit désormais être reconfiguré dans chaque zone linguistique séparément
Impact classé par ordre de gravité observé
Impact élevé : disparition apparente de widgets après mise à jour
Sur plusieurs sites testés juste après la sortie de cette version, la première mise à jour vers l’éditeur de blocs a vidé certaines zones de widgets dans les langues secondaires, alors que la langue principale du site conservait son contenu. La cause : l’ancien widget classique n’existait, en base, que pour une seule langue, l’extension multilingue générant les autres versions à la volée, une mécanique que l’éditeur de blocs ne reproduit pas de la même façon.
Impact moyen : doublons de blocs après conversion automatique
Certains sites ont vu leurs anciens widgets convertis automatiquement en blocs, mais dupliqués dans chaque zone linguistique existante, produisant un contenu de barre latérale identique dans toutes les langues, y compris pour des blocs qui auraient dû rester spécifiques à une seule d’entre elles.
Impact faible : réglages visuels à réajuster
Enfin, certains ajustements restent purement cosmétiques : l’espacement ou l’alignement de blocs convertis automatiquement peut légèrement différer de l’ancien rendu du widget classique, sans conséquence fonctionnelle réelle sur le multilinguisme du site.
Recommandations avant de mettre à jour un site multilingue
Face à ce changement, une vérification manuelle, zone par zone et langue par langue, reste la seule approche fiable avant de considérer la mise à jour comme terminée :
- exporter une capture de chaque zone de widgets, dans chaque langue, avant la mise à jour
- comparer cette capture avec le rendu obtenu après conversion en blocs
- reconstruire manuellement les zones affectées plutôt que de compter sur une conversion automatique complète
Cette vérification, réalisée sur un site de test avant toute application en production, prend rarement plus d’une heure pour un site de taille moyenne, un temps largement compensé par les correctifs d’urgence évités ensuite sur le site réel.
Une mise à jour majeure du cœur qui change la structure de stockage d’une fonctionnalité mérite toujours un test préalable sur une copie du site, langue par langue, avant d’être appliquée à un site multilingue en production.
En résumé
WordPress 5.8 a transformé les widgets en contenu de blocs à part entière, un changement bénéfique pour la flexibilité éditoriale mais qui a révélé, sur les sites multilingues aux barres latérales traduites séparément, des hypothèses de stockage que les extensions multilingues n’avaient pas toutes anticipées de la même façon. Un audit préalable, zone par zone, reste le moyen le plus sûr d’éviter une mauvaise surprise après mise à jour.
