« La page reste blanche, ou le bouton Elementor charge indéfiniment sans jamais afficher l’éditeur. » C’est la description reçue par une agence qui gérait un site vitrine traduit avec TranslatePress et construit avec Elementor Pro, quelques jours après une mise à jour automatique de l’un des deux plugins. Le problème touchait uniquement les pages traduites : la version française d’origine s’éditait normalement dans Elementor, tandis que les versions anglaise et espagnole, gérées par TranslatePress, refusaient purement et simplement de charger l’éditeur visuel.
Ce cas est distinct de la panne de sélecteur de langue Elementor déjà couverte par ailleurs, qui concernait l’affichage du sélecteur en front, pas l’accès à l’éditeur visuel lui-même en back-office.
Le mécanisme du conflit
TranslatePress fonctionne par surcouche visuelle : il charge la page dans un iframe, superpose une interface d’édition de chaînes traduites, et intercepte certains scripts pour afficher le contenu à traduire directement au survol. Elementor Pro, de son côté, charge sa propre interface d’édition visuelle également via un mode preview spécifique, avec ses propres scripts de gestion du DOM et ses propres styles injectés dynamiquement. Quand un visiteur (ou un traducteur) tente d’ouvrir l’éditeur de traduction visuelle de TranslatePress sur une page construite avec Elementor, les deux couches d’édition tentent de prendre le contrôle du même DOM en parallèle, chacune s’attendant à trouver la page dans un état qu’elle contrôle entièrement.
Le blocage observé provient généralement d’un script d’Elementor Pro qui, après une mise à jour, détecte qu’il n’est pas dans son contexte d’édition habituel (l’éditeur natif WordPress) et interrompt son initialisation, empêchant au passage TranslatePress de terminer le chargement de sa propre couche de traduction visuelle, restée en attente d’un événement JavaScript qu’Elementor ne déclenche jamais dans ce contexte.
Diagnostic pas à pas
- Ouvrir la console JavaScript du navigateur (F12) en tentant de charger l’éditeur de traduction sur la page concernée
- Repérer une erreur de script mentionnant un sélecteur DOM introuvable ou un timeout d’initialisation, généralement émise par un fichier
frontend.min.jsd’Elementor - Vérifier les numéros de version installés des deux extensions et les comparer au changelog officiel de chacune pour la période de la mise à jour
- Désactiver temporairement TranslatePress seul pour confirmer qu’Elementor s’ouvre normalement en édition sur la page traduite (ce qui isole bien le conflit entre les deux extensions plutôt qu’une panne d’Elementor seul)
Le correctif : forcer l’ordre de chargement des scripts
La solution qui a résolu ce cas précis consistait à retarder l’initialisation du script de prévisualisation de TranslatePress jusqu’à ce qu’Elementor ait fini de charger sa propre interface, plutôt que de laisser les deux scripts s’exécuter en parallèle. Concrètement, cela passe par un petit script ajouté en mu-plugin qui attend un événement personnalisé émis par Elementor avant de déclencher l’initialisation de TranslatePress dans ce contexte précis :
add_action( 'wp_footer', function() {
if ( ! did_action( 'elementor/frontend/after_register_scripts' ) ) {
return;
}
?>
<script>
document.addEventListener('DOMContentLoaded', function() {
window.addEventListener('elementor/frontend/init', function() {
if (window.TRP_TRANSLATION_PREVIEW) {
window.TRP_TRANSLATION_PREVIEW.init();
}
});
});
</script>
<?php
}, 999 );
Ce correctif reste une solution de contournement, pas une résolution officielle du conflit : il dépend de l’existence de points d’entrée exposés par les deux extensions à un instant donné, susceptibles de changer à une future mise à jour de l’une ou l’autre.
Pourquoi désactiver l’un des deux n’est pas une option viable
Face à ce blocage, la tentation immédiate est de désactiver temporairement Elementor sur la page traduite pour permettre la traduction, puis de le réactiver ensuite. Cette approche fonctionne ponctuellement mais devient vite intenable dès qu’une équipe éditoriale doit traduire régulièrement du nouveau contenu construit avec Elementor : elle réintroduit une manipulation manuelle fragile à chaque traduction, avec un risque d’oubli qui laisse la page réellement cassée pour les visiteurs pendant la fenêtre de désactivation.
Signaler le conflit aux deux éditeurs
Au-delà du correctif technique local, ce type de conflit entre deux extensions largement utilisées mérite d’être signalé aux deux équipes de support, via leurs canaux officiels respectifs. Les éditeurs d’extensions grand public corrigent régulièrement ces incompatibilités dans une version suivante une fois le conflit clairement documenté et reproductible, ce qui permet à terme de retirer le correctif de contournement.
- Isoler le conflit en désactivant une extension à la fois avant de conclure à un bug natif
- Chercher l’erreur précise dans la console plutôt que de deviner la cause
- Documenter et signaler le conflit aux deux équipes de support concernées
- Considérer tout correctif de contournement comme temporaire, à retirer dès qu’un correctif officiel existe
En résumé
Un éditeur visuel qui refuse de s’ouvrir sur une page traduite n’est presque jamais un bug isolé d’une seule extension : c’est le symptôme de deux couches d’édition qui se disputent le même DOM sans coordination. Le diagnostic par la console JavaScript et un correctif ciblé sur l’ordre de chargement des scripts suffisent en général à débloquer la situation, en attendant qu’un correctif officiel règle le conflit à la source.
