# add_theme_support(‘html5’) moderniser recherche et commentaires sans plugin

> Six mots-clés suffisent à déclarer un balisage HTML5 natif pour les formulaires de recherche, de commentaire et les galeries, sans extension supplémentaire.

- Auteur : WordPress Développement
- Publié le : 2021-04-20
- Mis à jour le : 2021-04-20
- Catégorie : Thèmes
- URL : https://www.wpmoderne.fr/themes/add-theme-support-html5-recherche-commentaires-sans-plugin/

## L’essentiel

- Six zones peuvent recevoir un balisage HTML5 natif
- Un seul appel remplace des années de balisage hérité
- Le rendu reste compatible avec les extensions de commentaires

Six mots-clés : `search-form`, `comment-form`, `comment-list`, `gallery`, `caption`, `script`, `style`. C'est la liste complète des zones qu'un thème peut moderniser d'un seul coup grâce à `add_theme_support('html5')`, sans installer la moindre extension et sans réécrire de balisage à la main.

Avant cette fonctionnalité, les formulaires générés par les fonctions du cœur de WordPress produisaient un balisage hérité, avec des attributs de présentation directement dans le HTML et des tableaux utilisés pour la mise en forme des galeries. Voici comment activer un rendu propre pour un intégrateur qui construit un thème sur mesure.

## La déclaration de base

Comme toutes les fonctionnalités de thème, l'appel se fait dans `after_setup_theme`, avec un tableau listant les zones concernées.

```
function monthème_setup() {
    add_theme_support( 'html5', array(
        'search-form',
        'comment-form',
        'comment-list',
        'gallery',
        'caption',
        'script',
        'style',
    ) );
}
add_action( 'after_setup_theme', 'monthème_setup' );
```

Chaque mot-clé active un rendu distinct pour la fonction correspondante du cœur : `get_search_form()`, `comment_form()`, `wp_list_comments()`, la fonction de rendu des galeries d'images, et la génération des légendes.

> L'essentiel à retenir : Six zones peuvent recevoir un balisage HTML5 natif ; Un seul appel remplace des années de balisage hérité ; Le rendu reste compatible avec les extensions de commentaires

## Ce que change search-form concrètement

Sans cette déclaration, `get_search_form()` produit un formulaire avec un attribut `role="search"` ajouté en surcouche mais un balisage globalement hérité. Avec la déclaration active, le formulaire généré utilise un `<label>` natif associé à l'entrée, un type d'entrée `search` plutôt qu'un simple `text`, ce qui bénéficie directement à l'accessibilité et à l'ergonomie mobile.

```
<form role="search" method="get" class="search-form" action="https://exemple.test/">
    <label>
        <span class="screen-reader-text">Rechercher :</span>
        <input type="search" class="search-field" placeholder="Rechercher …" value="" name="s" />
    </label>
    <input type="submit" class="search-submit" value="Rechercher" />
</form>
```

## Variante : ne moderniser qu'une partie

Il n'est pas obligatoire d'activer toutes les zones d'un coup. Un thème qui personnalise entièrement son propre formulaire de recherche par un filtre sur `get_search_form` peut se limiter aux zones qu'il ne réécrit pas lui-même.

- Ne déclarer que `comment-form` et `comment-list` si le formulaire de recherche est entièrement personnalisé ailleurs.
- Ajouter `style` et `script` pour que les balises générées par certains widgets utilisent un attribut moderne plutôt qu'un attribut de type obsolète.
- Combiner avec un CSS ciblant les classes générées, comme `.comment-list`, pour un rendu homogène avec le reste du thème.

## Le cas particulier de comment-list

Cette zone modifie la structure produite par `wp_list_comments()`, qui passe d'une liste imbriquée avec des balises de définition à une structure `<ol>` et `<li>` plus conforme aux usages actuels. Attention toutefois : un thème qui personnalise déjà l'affichage des commentaires via un rappel (« callback ») personnalisé garde la main sur son propre balisage, la déclaration `html5` ne s'applique qu'au rendu par défaut fourni par WordPress.

> Sur un projet livré à un client peu technique qui personnalise parfois lui-même des blocs via l'éditeur, activer cette fonctionnalité en amont évite bien des balises dépréciées qui finissent par gêner un futur audit d'accessibilité.

## Compatibilité avec les extensions de commentaires

Les extensions qui remplacent le système de commentaires natif, par exemple pour ajouter un système de notation, s'appuient en général sur les mêmes fonctions du cœur et respectent donc cette déclaration sans configuration supplémentaire. Il reste utile de vérifier le rendu après activation d'une telle extension, certaines surchargeant directement le balisage sans tenir compte des réglages du thème.

## En résumé

Six mots-clés, un seul appel, et l'ensemble des formulaires générés par le cœur de WordPress adopte un balisage HTML5 natif plutôt qu'un rendu hérité. Cette fonctionnalité de thème, peu coûteuse à mettre en place, reste l'une des plus rentables pour un intégrateur soucieux de livrer un code propre sans réinventer les fonctions déjà fournies par WordPress.