# Contact Form 7 dans un thème bloc : diagnostiquer une mise en page cassée

> Symptôme, diagnostic et correctif ciblé pour un formulaire Contact Form 7 dont la mise en page se retrouve cassée une fois inséré dans un thème bloc récent.

- Auteur : Clément Hadrot
- Publié le : 2025-03-01
- Mis à jour le : 2025-03-01
- Catégorie : Thèmes
- URL : https://wpmoderne.dev.wordpress-developpement.fr/themes/contact-form-7-theme-bloc-css-casse/

## L’essentiel

- Les styles globaux du thème bloc écrasent les classes natives du plugin
- Le conflit vient souvent d'une réinitialisation trop large des éléments de formulaire
- Un correctif ciblé sur les sélecteurs suffit, sans toucher aux styles globaux

Le formulaire s'affiche, les champs sont bien là, mais tout est empilé sans espacement, le bouton d'envoi prend toute la largeur de la colonne et les libellés se retrouvent collés aux champs de saisie. Voilà le symptôme exact rencontré en insérant un shortcode Contact Form 7 dans un template de thème bloc récent, alors que ce même formulaire s'affichait sans problème sur l'ancien thème classique du même site.

Ce billet suit la démarche symptôme → diagnostic → correctif → prévention, sur ce cas précis. Il ne traite ni la migration vers le bloc Formulaire natif de WordPress, ni la validation des données côté serveur : uniquement le conflit de mise en page observé.

## Symptôme : un formulaire visuellement écrasé

Le shortcode `[contact-form-7 id="..." title="Contact"]` est inséré dans un bloc Shortcode, lui-même placé dans un template de page géré par l'éditeur de site. À l'affichage :

- Les champs de formulaire n'ont plus aucune marge entre eux
- Le champ de texte et son libellé se chevauchent visuellement
- Le bouton de soumission occupe 100 % de la largeur du conteneur parent
- Les bordures des champs ont disparu, remplacées par un simple soulignement

Sur l'ancien thème classique, avec exactement le même formulaire Contact Form 7, aucun de ces problèmes n'apparaissait. Le plugin n'a pourtant pas changé de version entre les deux tests.

## Diagnostic : des styles globaux trop larges

L'inspection des styles calculés dans les outils de développement du navigateur révèle la cause : le thème bloc applique des règles CSS globales très larges, générées à partir de `theme.json`, qui ciblent des sélecteurs génériques comme `input`, `label` et `button` sans les restreindre à un contexte précis. Contact Form 7, de son côté, génère son propre balisage avec des classes comme `.wpcf7-form-control`, mais ces classes n'ont pas une spécificité CSS suffisante pour l'emporter sur les règles globales du thème.

```
/* Générée automatiquement depuis theme.json */
input, textarea, select {
    border: none;
    border-bottom: 1px solid var(--wp--preset--color--contrast);
    padding: 0;
    margin: 0;
}

button {
    width: 100%;
    background: var(--wp--preset--color--primary);
}
```

Ce type de règle est courant dans les thèmes blocs conçus pour uniformiser l'apparence des blocs natifs de formulaire (bloc Champ de formulaire de l'éditeur de site). Le problème, c'est que ces sélecteurs génériques capturent aussi les éléments générés par un shortcode de plugin tiers, qui n'a jamais été pensé pour composer avec ce niveau de styles globaux.

### Vérifier l'hypothèse avant de corriger

Avant d'écrire le moindre correctif, il est utile de confirmer précisément quelle règle gagne le conflit de spécificité. Dans les outils de développement, sélectionner un champ du formulaire et observer, dans le panneau des styles calculés, quelle déclaration CSS est barrée (donc perdante) et laquelle s'applique réellement. Cela évite d'ajouter un correctif qui ne cible pas la bonne règle.

> L'essentiel à retenir : Les styles globaux du thème bloc écrasent les classes natives du plugin ; Le conflit vient souvent d'une réinitialisation trop large des éléments de formulaire ; Un correctif ciblé sur les sélecteurs suffit, sans toucher aux styles globaux

## Correctif : cibler précisément le conteneur du formulaire

La tentation est grande d'ajouter `!important` partout. C'est la mauvaise solution : elle rend le CSS suivant impossible à maintenir dès que le thème évolue. Le correctif propre consiste à augmenter la spécificité en s'appuyant sur une classe de conteneur ajoutée autour du shortcode, sans toucher aux règles globales du thème.

```
<!-- Dans le bloc Shortcode de l'éditeur de site -->
<div class="conteneur-cf7">
    [contact-form-7 id="128" title="Contact"]
</div>
```

```
.conteneur-cf7 .wpcf7-form-control {
    display: block;
    margin-bottom: 1rem;
    padding: 0.6rem 0.8rem;
    border: 1px solid var(--wp--preset--color--contrast);
    border-radius: 4px;
}

.conteneur-cf7 label {
    display: block;
    margin-bottom: 0.3rem;
}

.conteneur-cf7 input[type="submit"] {
    width: auto;
    display: inline-block;
}
```

Ces quatre sélecteurs, ajoutés dans une feuille de style additionnelle du thème via `wp_enqueue_style()`, suffisent à rétablir un affichage cohérent sans avoir à modifier une seule ligne des règles globales générées par `theme.json`. Le formulaire retrouve ses espacements, ses bordures, et un bouton de taille raisonnable.

### Charger ce correctif uniquement où nécessaire

```
function agence_style_correctif_cf7() {
    if ( has_shortcode( get_post()->post_content ?? '', 'contact-form-7' ) ) {
        wp_enqueue_style(
            'correctif-cf7',
            get_stylesheet_directory_uri() . '/assets/css/correctif-cf7.css',
            array(),
            '1.0'
        );
    }
}
add_action( 'wp_enqueue_scripts', 'agence_style_correctif_cf7' );
```

Ce chargement conditionnel évite d'envoyer ce CSS correctif sur des pages qui ne contiennent pas de formulaire Contact Form 7, gardant le poids global des feuilles de style du site sous contrôle.

## Prévention pour les prochains formulaires tiers

Ce cas illustre un problème plus général : tout plugin qui génère son propre balisage de formulaire, sans passer par les blocs natifs de l'éditeur, entrera potentiellement en conflit avec les styles globaux d'un thème bloc. Quelques réflexes réduisent le risque en amont :

1. Toujours envelopper un shortcode de formulaire tiers dans une classe de conteneur dédiée, dès l'intégration initiale
2. Tester l'affichage du formulaire sur le thème bloc final avant la livraison, pas seulement sur un environnement de développement neutre
3. Préférer, quand c'est possible, une extension proposant nativement des blocs plutôt qu'un shortcode hérité

## En résumé

Le conflit entre Contact Form 7 et un thème bloc n'est ni un bug du plugin ni un défaut du thème : c'est une conséquence directe de deux logiques de style qui n'ont pas été conçues pour cohabiter. Un conteneur dédié et quatre sélecteurs ciblés suffisent à réconcilier les deux, sans jamais avoir à toucher aux styles globaux issus de `theme.json`.