# Elementor et bloc Gutenberg sur la même page : ce qui casse vraiment

> Diagnostic des conflits CSS et JavaScript réellement observés quand un bloc Gutenberg personnalisé est inséré dans une page construite avec Elementor.

- Auteur : WordPress Développement
- Publié le : 2022-10-10
- Mis à jour le : 2022-10-10
- Catégorie : Blocs Gutenberg
- URL : https://www.wpmoderne.fr/blocs/elementor-bloc-gutenberg-meme-page-conflits/

## L’essentiel

- Le conflit vient presque toujours des styles globaux, pas du bloc lui-même
- Elementor court-circuite parfois le rendu natif d'un article
- Un test de rendu isolé règle le diagnostic en quelques minutes

Un client utilisait Elementor pour la quasi-totalité de ses pages, sauf pour un article de blog où un bloc Gutenberg personnalisé — un tableau de comparaison interactif — devait s'insérer via le widget « Shortcode » d'Elementor, faute de pouvoir utiliser l'éditeur natif sur ce gabarit précis. Le résultat affichait un tableau à moitié stylé, avec des marges incohérentes et un comportement au clic qui ne réagissait plus.

Ce cas illustre un problème récurrent sur les projets qui mêlent les deux systèmes : Elementor et Gutenberg peuvent techniquement cohabiter, mais chacun impose son propre système de styles globaux, ce qui génère des conflits qu'un simple bloc bien codé ne suffit pas toujours à éviter.

## Premier réflexe : isoler le rendu du bloc seul

Avant de chercher le conflit, la vérification de base consiste à insérer le même bloc sur une page 100 % Gutenberg, sans Elementor, pour confirmer qu'il fonctionne correctement en dehors de tout contexte tiers. Sur ce projet, le bloc s'affichait parfaitement en dehors d'Elementor, ce qui a orienté le diagnostic vers un conflit d'environnement plutôt que vers un bug du bloc lui-même.

## Premier conflit : les styles globaux Elementor qui débordent

Elementor applique des styles globaux très larges (`* { box-sizing: border-box; }`, des réinitialisations de marges sur les balises `p`, `ul`, `table`) qui s'appliquent à toute la page, y compris au contenu inséré via un shortcode. Le tableau du bloc perdait ainsi ses marges internes, écrasées par une règle Elementor plus spécifique en cascade CSS.

```
/* Règle Elementor, très générique */
.elementor table td { padding: 0; }

/* Règle du bloc, moins spécifique en pratique */
.wpm-tableau-comparatif td { padding: 12px; }
```

> L'essentiel à retenir : Le conflit vient presque toujours des styles globaux, pas du bloc lui-même ; Elementor court-circuite parfois le rendu natif d'un article ; Un test de rendu isolé règle le diagnostic en quelques minutes

## Deuxième conflit : le widget Shortcode qui n'enqueue pas les scripts

Le widget « Shortcode » d'Elementor affiche le HTML retourné par le shortcode, mais n'exécute cette insertion qu'au moment du rendu Elementor, potentiellement après l'exécution normale du hook `wp_enqueue_scripts` côté thème. Le script d'interactivité du tableau, enregistré via `has_block()`, ne se déclenchait donc jamais : Elementor ne rend pas la page via le système de blocs natif, et `has_block()` retournait `false` alors que le tableau était bien présent visuellement via le shortcode.

```
// Ne fonctionne pas dans ce contexte : le contenu n'est jamais lu comme un bloc par Elementor
if ( has_block( 'wpmoderne/tableau-comparatif' ) ) {
    wp_enqueue_script( 'wpmoderne-tableau-comparatif' );
}
```

Le correctif a consisté à enqueue le script de façon inconditionnelle sur les pages utilisant Elementor concernées, un compromis moins élégant qu'un ciblage précis, mais fiable dans ce contexte mixte.

## Troisième conflit : la spécificité CSS à rattraper

Plutôt que d'entrer dans une guerre de spécificité CSS avec les styles globaux d'Elementor, la solution retenue a consisté à charger la feuille de style du bloc en dernier dans l'ordre d'enqueue, avec une dépendance explicite sur le style Elementor pour garantir cet ordre :

```
wp_enqueue_style(
    'wpmoderne-tableau-comparatif',
    plugins_url( 'style.css', __FILE__ ),
    array( 'elementor-frontend' ),
    '1.2.0'
);
```

## Ce que cet article ne couvre pas

La migration complète d'un site Elementor vers Gutenberg, ou l'inverse, implique des choix bien plus larges que ce cas ponctuel de cohabitation sur une seule page, et mérite une réflexion de fond sur l'ensemble du projet. Un comparatif de performance entre les deux systèmes de construction de page dépend fortement du site concerné et ne se résume pas à ce type de conflit d'intégration.

## En résumé

Sur ce projet, aucun des trois conflits observés ne venait du code du bloc lui-même : tous provenaient de l'environnement Elementor qui l'entourait, entre styles globaux trop larges et détection de contexte qui ne fonctionne pas de la même façon hors de l'éditeur natif. Isoler le bloc seul reste le réflexe le plus rapide pour écarter cette hypothèse avant de chercher plus loin.