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

Éditeur de site (FSE)

Pourquoi une valeur de style personnalisé ressort filtrée dans le panneau Styles

Une valeur CSS saisie dans le panneau Styles disparaît après enregistrement, sans message d'erreur. La cause se trouve du côté de l'échappement en écriture.

Par WordPress Développement • 28 avril 2025 • 4 min de lecture • Aucun commentaire
Pourquoi une valeur de style personnalisé ressort filtrée dans le panneau Styles

Une couleur personnalisée saisie sous forme de fonction CSS complexe, ou une valeur d’ombre portée avec plusieurs paramètres, disparaît purement et simplement après l’enregistrement des réglages de styles globaux. Rouvrir le panneau montre un champ vide, ou revenu à sa valeur précédente, sans le moindre message expliquant ce qui s’est passé.

Ce comportement n’est pas un bug isolé : il vient d’un mécanisme de nettoyage volontairement strict, qui s’applique à toute valeur enregistrée via les styles globaux, y compris quand elle est saisie par un administrateur du site plutôt que par un utilisateur aux droits limités.

Symptôme

Le cas se présente typiquement ainsi : une valeur de style personnalisé (par exemple une valeur d’ombre portée avec une syntaxe multi-paramètres, ou une couleur exprimée avec une fonction CSS moins courante) est saisie dans le panneau Styles de l’éditeur de site. Le champ accepte la saisie sans avertissement visuel. Après clic sur enregistrer, puis rechargement du panneau, la valeur a disparu ou a été remplacée par une valeur par défaut.

Diagnostic

Les données de styles globaux transitent, avant écriture en base, par une fonction de nettoyage du cœur dédiée à ce type de contenu, dans la même famille que wp_kses mais appliquée spécifiquement à la structure JSON des styles globaux plutôt qu’à un champ de contenu ouvert. Cette fonction vérifie chaque valeur par rapport à un schéma attendu : certaines propriétés n’acceptent que des valeurs numériques suivies d’une unité connue, d’autres n’acceptent que des références à des préréglages déclarés dans theme.json.

Une valeur qui sort de ce schéma — une syntaxe CSS techniquement valide pour un navigateur, mais non anticipée par la structure attendue des styles globaux — est purement supprimée plutôt que rejetée avec un message. C’est ce silence qui rend le diagnostic difficile : rien ne distingue, du point de vue de l’utilisateur, une valeur refusée d’une valeur simplement oubliée.

L'essentiel à retenir : Le panneau Styles passe par une validation stricte avant sauvegarde ; Certaines syntaxes CSS valides sont tout de même rejetées ; Le contournement passe par un theme.json plutôt que par la saisie libre

Correctif

Deux approches permettent de contourner cette limite, selon le besoin réel :

  • Si la valeur correspond à un réglage réellement pris en charge par le schéma (couleur, dimension, typographie), la reformuler dans une syntaxe strictement conforme à ce qu’attend theme.json — souvent une valeur simple plutôt qu’une fonction CSS composée.
  • Si la valeur nécessite une syntaxe CSS que le panneau Styles ne prend pas en charge nativement, la déclarer directement dans theme.json via la propriété css d’un bloc, qui accepte du CSS brut sans passer par le même filtre de structure.

Cette seconde option déplace la déclaration du panneau d’administration vers le code du thème, ce qui la rend moins accessible à un client non technique, mais garantit qu’elle survivra à l’enregistrement :

{
  "styles": {
    "blocks": {
      "core/group": {
        "css": "box-shadow: 0 12px 24px -8px rgba(15, 23, 42, 0.35);"
      }
    }
  }
}

Un point important : ce n’est pas une faille à contourner

Ce nettoyage strict existe pour une raison précise : le panneau Styles est accessible à des rôles qui ne sont pas nécessairement autorisés à écrire du code arbitraire sur le site (un rôle personnalisé avec la capacité edit_theme_options sans les capacités habituellement réservées aux administrateurs, par exemple). Sans ce filtre, une valeur de style pourrait théoriquement servir de vecteur pour injecter du contenu non désiré dans le CSS généré du site. Le comportement n’est donc pas un défaut à corriger côté cœur, mais une limite à connaître côté conception de thème.

Prévention

Pour un thème destiné à être configuré par des clients depuis le panneau Styles, mieux vaut tester en amont les types de valeurs qu’on prévoit de leur laisser saisir librement, plutôt que de découvrir la limite après livraison. Les valeurs basées sur les préréglages déclarés dans theme.json (couleurs, espacements, typographies enregistrés comme préréglages) passent toujours sans problème, puisqu’elles correspondent exactement au schéma attendu.

La règle qu’on retient pour la conception de thème : tout ce qu’un client doit pouvoir régler librement passe par un préréglage déclaré dans theme.json, jamais par une saisie CSS libre dans le panneau Styles.

En résumé

Une valeur qui disparaît sans message d’erreur dans le panneau Styles n’indique pas un bug, mais l’application d’un nettoyage de sécurité qui protège la structure des styles globaux contre des valeurs hors schéma. Comprendre cette limite en amont évite de perdre du temps à chercher un dysfonctionnement là où le comportement est en réalité voulu.

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