grep -rn "style=" mon-extension/ : cette simple commande, lancée avant toute autre étape, révèle souvent l’ampleur réelle du chantier. Elementor V4 introduit des classes globales et des variables de style partagées entre les éléments, en remplacement progressif des styles inline générés widget par widget sous les versions précédentes. Migrer une extension vers ce système sans audit préalable revient à découvrir les incompatibilités une par une, en production, chez un client.
Cette checklist ne traite pas le renommage des widgets ni leur passage au format atomique, sujet distinct déjà abordé ailleurs : elle se concentre uniquement sur ce qu’il faut vérifier côté styles avant d’entamer l’adaptation aux classes globales.
1. Recenser les styles injectés en ligne
Les widgets Elementor classiques génèrent fréquemment leurs styles directement en attribut style ou via un bloc <style> inséré dynamiquement dans la page, à partir des réglages du panneau de configuration. Ce mode de génération entre en conflit direct avec le principe des classes globales, qui attend des styles définis une fois et référencés par nom de classe. Chaque occurrence de style inline dans le code de l’extension doit être identifiée avant de décider si elle sera convertie en classe globale ou conservée telle quelle pour les widgets qui ne migrent pas.
2. Vérifier la spécificité CSS entre widgets
Un widget qui s’appuyait sur l’ordre d’apparition de ses règles CSS dans la feuille de style — une pratique courante pour forcer la priorité d’un style sur un autre sans recourir à !important — perd cette garantie une fois les styles répartis en classes globales potentiellement chargées dans un ordre différent. Il faut vérifier, widget par widget, si une règle de style dépend implicitement de sa position dans le fichier plutôt que d’une spécificité explicite.
.mon-widget .titre { color: #1a1a1a; }
.mon-widget.variante-sombre .titre { color: #ffffff; } /* dépend de l'ordre */
3. Lister les dépendances de polices et d’unités
Les classes globales d’Elementor V4 s’appuient sur un système de variables de style (couleurs, typographies, espacements) défini au niveau du site plutôt que par widget. Une extension qui codait en dur une taille de police en pixels, sans passer par les contrôles de style natifs d’Elementor, ne bénéficiera d’aucune adaptation automatique lors de la migration : ces valeurs resteront figées et devront être converties manuellement en variables si l’on veut qu’elles suivent la charte définie globalement sur le site.
4. Tester la coexistence avec la feuille de style héritée
Elementor V4 ne retire pas les styles générés par la V3 sur les pages non migrées : les deux systèmes coexistent, ce qui signifie qu’une extension déployée sur un parc de sites hétérogène doit continuer à générer correctement les styles classiques pour les pages non encore migrées, tout en supportant les classes globales sur les pages qui le sont. Ignorer ce point conduit à des styles doublés ou en conflit sur les pages en transition.
- Vérifier qu’aucune règle CSS de l’extension ne cible une classe générée automatiquement par la V3 de façon à casser si cette classe change de forme sous la V4.
- Confirmer que les styles par défaut de l’extension continuent de s’appliquer correctement sur une page non migrée.
- Tester une page mixte, avec certains widgets migrés et d’autres non, pour vérifier l’absence de conflit visuel.
5. Vérifier les feuilles de style chargées conditionnellement
Une extension qui charge sa feuille de style uniquement quand un widget spécifique est présent sur la page, via elementor/frontend/before_render, doit vérifier que cette condition reste valable dans le nouveau système : les éléments atomiques et les classes globales peuvent être détectés différemment lors du rendu de la page, ce qui change le moment où l’extension sait qu’elle doit charger son style.
6. Documenter les styles qui ne migreront pas tout de suite
Certains widgets complexes ne justifient pas une migration immédiate vers les classes globales, en particulier ceux peu utilisés ou proches de la fin de vie. Il vaut mieux documenter explicitement, dans le changelog de l’extension, quels widgets restent sur l’ancien système de style et pour combien de temps, plutôt que de laisser un client découvrir l’incohérence sans explication.
Une migration de style partielle n’est pas un problème en soi. Une migration de style partielle non documentée, en revanche, devient un ticket de support récurrent.
En résumé
Avant d’écrire la moindre ligne d’adaptation aux classes globales d’Elementor V4, l’audit des styles en dur, des dépendances de spécificité et de la coexistence avec la V3 permet d’estimer correctement l’effort réel de migration. Les six points de cette checklist, cochés dans l’ordre, évitent de découvrir les incompatibilités une à une après coup.
