# « Historique : pourquoi add_theme_support a remplacé des constantes codées en dur »

> Avant que les thèmes ne déclarent leurs fonctionnalités avec une API dédiée, chacun définissait ses propres constantes ou variables globales. Retour sur l'intérêt réel de ce changement.

- Auteur : WordPress Développement
- Publié le : 2024-04-17
- Mis à jour le : 2024-04-17
- Catégorie : Thèmes
- URL : https://www.wpmoderne.fr/themes/historique-add-theme-support-remplace-constantes/

## L’essentiel

- Avant add_theme_support, chaque thème inventait sa propre convention de déclaration
- Les extensions ne pouvaient pas interroger une constante propre à un thème donné
- add_theme_support standardise la déclaration et son interrogation via current_theme_supports

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.

> L'essentiel à retenir : Avant add_theme_support, chaque thème inventait sa propre convention de déclaration ; Les extensions ne pouvaient pas interroger une constante propre à un thème donné ; add_theme_support standardise la déclaration et son interrogation via current_theme_supports

## 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.