# Le fichier style.css d’un thème : l’en-tête que la revue vérifie > Avant de soumettre son premier thème, chaque champ de l'en-tête de style.css mérite d'être décrypté : Theme Name, Requires PHP, Tags, et les erreurs qui bloquent la revue. - Auteur : Clément Hadrot - Publié le : 2022-01-11 - Mis à jour le : 2022-01-11 - Catégorie : Thèmes - URL : https://wpmoderne.dev.wordpress-developpement.fr/themes/style-css-en-tete-revue/ ## L’essentiel - Theme Name doit être unique et sans caractère spécial superflu - Requires PHP protège les utilisateurs d'une version incompatible - Un champ Tags mal renseigné complète l'échec déjà vu côté readme.txt Un développeur débutant que j'accompagne en mentorat préparait son tout premier thème destiné au répertoire officiel WordPress.org, une déclinaison sobre pour cabinets d'expertise comptable. Il avait soigné le rendu visuel et la structure des templates, mais son en-tête de `style.css` recopiait presque mot pour mot celui d'un tutoriel trouvé en ligne, avec un nom de thème déjà pris et une version de PHP minimale fantaisiste. Décortiquer chaque champ de cet en-tête lui a évité plusieurs allers-retours avec l'équipe de revue. Cet article détaille ce que signifie chaque champ de l'en-tête de `style.css`, sans revenir sur le fichier `readme.txt`, déjà couvert séparément avec ses propres règles de tags et de changelog. ## La structure de base de l'en-tête L'en-tête d'un thème classique se place en commentaire CSS tout en haut du fichier `style.css`, sous une forme stricte que WordPress analyse par expression régulière pour en extraire les métadonnées. ``` /* Theme Name: Comptalis Theme URI: https://example.com/themes/comptalis Author: Nom du développeur Author URI: https://example.com Description: Un thème sobre pensé pour les cabinets d'expertise comptable. Version: 1.0 Requires at least: 5.8 Requires PHP: 7.4 License: GNU General Public License v2 or later License URI: https://www.gnu.org/licenses/gpl-2.0.html Text Domain: comptalis Tags: one-column, custom-menu, custom-logo, translation-ready */ ``` ## Theme Name : unique et sans fioriture Le champ `Theme Name` doit correspondre au nom affiché dans le répertoire officiel. Il doit être unique sur l'ensemble du répertoire : un nom déjà pris par un thème existant provoque un rejet, même si le code n'a strictement rien à voir. Les caractères spéciaux, emojis ou balises HTML n'y ont pas leur place ; un nom simple et descriptif reste la meilleure option, WordPress.org générant lui-même le slug technique à partir de ce nom. > L'essentiel à retenir : Theme Name doit être unique et sans caractère spécial superflu ; Requires PHP protège les utilisateurs d'une version incompatible ; Un champ Tags mal renseigné complète l'échec déjà vu côté readme.txt ## Requires at least et Requires PHP : protéger l'utilisateur, pas le développeur Ces deux champs ne sont pas de simples indications informatives : WordPress les utilise activement pour empêcher l'installation ou l'activation du thème sur un environnement incompatible. `Requires at least` fixe la version minimale de WordPress ; `Requires PHP` fixe la version minimale de PHP. Un thème déclarant `Requires PHP: 8.0` alors qu'il utilise en réalité une syntaxe compatible PHP 7.2 prive inutilement des utilisateurs d'hébergements encore anciens, tandis qu'une valeur trop basse expose à des erreurs fatales si le code utilise des fonctionnalités plus récentes du langage sans le déclarer. Le repère de bon sens que je recommande à mes mentorés : tester réellement le thème sur la version PHP la plus basse encore couramment proposée par les hébergeurs mutualisés du marché avant de fixer ce champ, plutôt que de recopier une valeur trouvée ailleurs. ## Version : la cohérence avec le changelog Le champ `Version` doit suivre un format de versionnage cohérent, en général `MAJEUR.MINEUR` ou `MAJEUR.MINEUR.CORRECTIF`. Comme évoqué pour le readme.txt, cette valeur doit correspondre exactement à la dernière entrée du changelog du thème : un décalage entre les deux fichiers est l'une des incohérences les plus fréquemment relevées lors de la revue. ## License et License URI : la case qui ne se négocie pas Un thème soumis au répertoire officiel doit être distribué sous une licence compatible GPL dans son intégralité, y compris son CSS et son JavaScript, à l'exception explicite des ressources tierces (polices, images) qui peuvent conserver une licence séparée compatible. Le champ `License` doit désigner cette licence de façon univoque, généralement `GNU General Public License v2 or later`, avec l'URL officielle correspondante dans `License URI`. ## Text Domain : la base de toute traduction Le champ `Text Domain` définit l'identifiant utilisé par toutes les fonctions de traduction du thème, comme `__()` ou `_e()`. Il doit correspondre exactement au nom du dossier du thème une fois publié, en minuscules et sans espace. Une divergence entre ce champ et le domaine réellement utilisé dans le code PHP empêche les traductions de charger correctement, un défaut qui passe souvent inaperçu en développement local mais saute aux yeux dès la première traduction fournie par la communauté. ## Tags : la même liste fermée que pour readme.txt Le champ `Tags` de `style.css` suit la même contrainte que celle déjà rencontrée dans le readme.txt : une liste fermée de mots-clés reconnus par WordPress.org, répartis par catégorie fonctionnelle. Les deux fichiers doivent en principe rester cohérents entre eux ; certains développeurs debutants ne renseignent le champ que dans l'un des deux fichiers, ce qui n'empêche pas la soumission mais nuit à la visibilité du thème dans les filtres de recherche du répertoire. - Vérifier chaque tag contre la liste officielle avant soumission, plutôt que de deviner un nom probable. - Garder `style.css` et `readme.txt` alignés sur les mêmes tags, sans duplication d'effort inutile. - Ne jamais inclure de tag évoquant un prix ou une exclusivité, réservé aux thèmes premium hors répertoire. ## En résumé L'en-tête de `style.css` n'est pas une formalité décorative : chaque champ, du nom unique du thème aux versions minimales requises en passant par la licence et le domaine de traduction, est vérifié et parfois activement exploité par WordPress pour protéger l'utilisateur final. Soigner cet en-tête avant la première soumission évite la majorité des rejets liés à un détail qui n'a, en apparence, rien à voir avec la qualité du code.