Avant que add_theme_support() ne devienne la méthode standard pour déclarer une fonctionnalité prise en charge par un thème, un développeur qui voulait signaler que son thème gérait un logo personnalisé, ou une taille d’image spécifique, devait souvent inventer sa propre convention : une constante MON_THEME_LOGO_SUPPORT définie dans functions.php, ou une variable globale vérifiée directement par le code du thème lui-même.
Cette diversité de conventions posait un problème que peu de personnes anticipaient au moment de leur écriture : une extension tierce, qui voulait s’adapter au thème actif pour éviter d’afficher une fonctionnalité redondante, n’avait aucun moyen fiable d’interroger cette information, faute de standard partagé entre les thèmes.
Le problème des constantes propres à chaque thème
Une constante définie par un thème n’est visible et interrogeable que si l’on connaît à l’avance son nom exact, ce qui suppose d’écrire un code spécifique pour chaque thème pris en charge individuellement. Une extension qui voulait détecter si le thème actif gérait nativement un carrousel d’images, par exemple, ne pouvait pas écrire un test générique : elle devait maintenir une liste de constantes propres à chaque thème populaire, une liste vouée à devenir rapidement incomplète face au nombre de thèmes disponibles.
add_theme_support(), une déclaration standardisée dans un vocabulaire commun
add_theme_support(), appelée dans le hook after_setup_theme, déclare la prise en charge d’une fonctionnalité avec un identifiant commun à tous les thèmes, défini par le cœur de WordPress lui-même :
add_action( 'after_setup_theme', function () {
add_theme_support( 'custom-logo' );
add_theme_support( 'post-thumbnails' );
add_theme_support( 'title-tag' );
} );
N’importe quelle extension, ou le cœur de WordPress lui-même, peut alors interroger cette déclaration avec current_theme_supports( 'custom-logo' ), sans jamais avoir besoin de connaître le nom du thème actif ni une constante spécifique à celui-ci.
Ce que cette standardisation a permis au cœur de WordPress
Cette API a permis au cœur de WordPress d’adapter son propre comportement selon les fonctionnalités déclarées par le thème actif, sans jamais connaître à l’avance quel thème serait utilisé. L’écran de personnalisation du logo, par exemple, ne s’affiche dans le Customizer que si le thème actif a préalablement déclaré add_theme_support( 'custom-logo' ) : sans cette déclaration, l’option reste absente de l’interface, plutôt que de risquer un affichage incohérent avec un thème qui ne saurait pas l’exploiter.
Un vocabulaire qui s’est enrichi au fil des versions
La liste des fonctionnalités reconnues par add_theme_support() s’est étoffée version après version : html5 pour un balisage moderne des formulaires de recherche et de commentaires, responsive-embeds pour les intégrations vidéo fluides, editor-styles pour appliquer l’apparence du thème dans l’éditeur de contenu, ou encore align-wide pour les alignements larges introduits avec l’éditeur de blocs. Chaque ajout a suivi le même principe fondateur : un identifiant partagé, interrogeable par n’importe quel code tiers sans connaissance préalable du thème concerné.
Une convention propre à un seul thème ne devient un standard que le jour où quelqu’un d’autre a besoin de l’interroger sans connaître ce thème à l’avance ; c’est précisément ce que résolvait cette nouvelle API.
Ce qu’il reste à vérifier dans un thème hérité
Un thème ancien, écrit avant la généralisation de cette convention ou maintenu par une équipe qui n’en a jamais adopté l’usage systématique, peut encore contenir des constantes personnalisées à la place d’appels à add_theme_support(). Une reprise de maintenance sur un tel thème gagne à identifier ces conventions maison et à les remplacer progressivement par l’API standard, ce qui améliore la compatibilité du thème avec les extensions qui, elles, s’attendent presque toujours à trouver ce vocabulaire commun.
- Rechercher les constantes définies dans functions.php qui ne correspondent à aucune convention du cœur.
- Vérifier si une fonctionnalité équivalente existe déjà sous forme de add_theme_support standard.
- Remplacer progressivement, fonctionnalité par fonctionnalité, plutôt que par une réécriture complète risquée.
En résumé
add_theme_support() n’a pas seulement simplifié l’écriture des thèmes : elle a rendu possible une communication fiable entre le thème, le cœur de WordPress et les extensions tierces, en remplaçant une multitude de conventions propres à chaque projet par un vocabulaire commun et interrogeable. Ce changement, largement invisible pour l’utilisateur final, reste l’une des évolutions les plus structurantes de l’API des thèmes.
