Ajouter du CSS dans WordPress proprement

Ce que fait vraiment le panneau « CSS additionnel »

Depuis WordPress 4.7, le chemin Apparence puis Personnaliser ouvre un panneau « CSS additionnel » : un éditeur, un aperçu en direct, aucune manipulation de fichier. C’est la voie la plus courte, et elle convient exactement à ce pour quoi elle a été conçue — un correctif court et ciblé dont on veut voir l’effet immédiatement.

Deux détails d’implémentation décident de la suite. Le contenu est enregistré comme une option du thème actif : il cesse de s’appliquer le jour où le site change de thème, sans être effacé pour autant, ce qui produit des disparitions difficiles à expliquer. Et il est injecté en ligne dans l’en-tête de chaque page plutôt que servi comme fichier de style, donc il n’est jamais mis en cache séparément et il repart sur le réseau à chaque vue.

Il n’existe par ailleurs ni historique, ni relecture, ni recherche : le panneau est un champ de texte. Tant que la feuille tient en quelques dizaines de lignes que l’on saurait réexpliquer dans six mois, c’est sans conséquence. Au-delà, le coût de maintenance dépasse le confort de départ.

• Quelques dizaines de lignes, pas quelques centaines.
• Des correctifs que l’on saurait retrouver et justifier plus tard.
• Rien qui doive survivre à un changement de thème.

Le thème enfant, seul endroit qui survit aux mises à jour

Un thème enfant est un dossier qui déclare le thème existant comme parent. Il hérite de tout son fonctionnement et ne contient que les écarts voulus. Comme les mises à jour du parent ne touchent jamais ce dossier, c’est le seul emplacement où du CSS écrit aujourd’hui sera encore là après la prochaine version du thème.

Deux fichiers suffisent. Le premier déclare le thème enfant, le second charge sa feuille de style après celle du parent, ce qui garantit l’ordre de priorité sans recourir à des artifices.

À partir de là, le CSS vit dans un fichier : il passe dans un gestionnaire de versions, se relit en revue, se cherche, se commente, et se met en cache par le navigateur comme n’importe quelle ressource statique.

/*
Theme Name: Mon thème enfant
Template: nom-du-theme-parent
Version: 1.0.0
*/

/* Les écarts voulus, et seulement eux. */

add_action( 'wp_enqueue_scripts', function () {
    wp_enqueue_style( 'parent-style', get_template_directory_uri() . '/style.css' );

    wp_enqueue_style(
        'child-style',
        get_stylesheet_directory_uri() . '/style.css',
        array( 'parent-style' ),
        wp_get_theme()->get( 'Version' )
    );
} );

Les trois endroits où il ne faut pas écrire

Modifier directement le fichier de style du thème parent fonctionne jusqu’à la première mise à jour, qui écrase le dossier entier. Le travail disparaît alors sans avertissement, et généralement au pire moment : celui où l’on applique un correctif de sécurité.

L’éditeur de fichiers intégré à l’administration présente le même risque, aggravé par l’absence de retour arrière : une accolade oubliée dans un fichier PHP suffit à rendre le site inaccessible, y compris l’administration depuis laquelle on venait d’écrire.

Enfin, empiler des extensions « CSS personnalisé » revient à multiplier les sources de vérité. Au bout de deux ou trois, plus personne ne sait quelle règle vient d’où, chaque page charge des styles concurrents, et le diagnostic d’un simple décalage prend une demi-journée.

• Ne jamais éditer le thème parent : la mise à jour l’écrasera.
• Désactiver l’éditeur de fichiers de l’administration sur un site en production.
• Une seule source pour le CSS du site, pas trois extensions concurrentes.

Écrire du CSS qui n’a pas besoin de !important

Le recours répété à une déclaration prioritaire est presque toujours le symptôme d’un problème d’ordre ou de spécificité, pas d’une limite du langage. Deux règles qui visent le même élément sont départagées d’abord par leur spécificité, et à spécificité égale par leur ordre de chargement.

Le premier réflexe est donc de vérifier quand la feuille est chargée : une dépendance déclarée à l’ajout du style suffit à la placer après celle du thème, et la question de la priorité disparaît. Le second est de viser juste plutôt que fort — un sélecteur ancré sur une classe du composant plutôt qu’une chaîne d’éléments imbriqués.

Une déclaration prioritaire reste légitime pour neutraliser un style en ligne posé par une extension tierce, sur laquelle on n’a pas la main. Elle mérite alors un commentaire expliquant ce qu’elle contourne : c’est ce commentaire qui permettra de la retirer le jour où l’extension change.

/* Fragile : dépend de la structure du thème. */
.site-main .content article .entry-header h2 a { color: #8e66f1; }

/* Stable : dépend du composant. */
.entry-title__link { color: #8e66f1; }

Quand le CSS additionnel devient un symptôme

Une feuille de correctifs qui grossit raconte quelque chose du site. Quelques dizaines de lignes ajustent un thème ; plusieurs centaines signalent que le thème choisi ne correspond pas à ce que le site doit faire, et que chaque page se paie désormais son rattrapage.

Le signal le plus net est la répétition : la même correction réécrite pour chaque nouveau gabarit, les mêmes valeurs recopiées avec de légers écarts, des sélecteurs de plus en plus longs. À ce stade, poser des décisions de design réutilisables — échelle typographique, espacements, couleurs — coûte moins cher que la prochaine série de correctifs. C’est le travail d’une charte graphique appliquée au code plutôt qu’à un document.

Le poids compte aussi : injecté dans chaque page, ce CSS est transféré à chaque vue et bloque l’affichage tant qu’il n’est pas interprété, ce qui pèse directement sur les signaux de performance mesurés par les moteurs — un point traité dans le référencement SEO au même titre que le contenu. Quand la dette dépasse le correctif, la question n’est plus où écrire le CSS mais quel socle reprendre, ce que cadre une création de site internet. Une estimation donne un premier ordre de grandeur avant d’en discuter.