Le WordPress d'aujourd'hui, décodé pour les développeurs

Elementor

Comment l’éditeur Elementor charge un brouillon sans recharger la page

L'aperçu en direct d'Elementor s'appuie sur des échanges internes en arrière-plan plutôt que sur un simple rechargement complet du navigateur.

Par WordPress Développement • 15 février 2021 • 4 min de lecture • Aucun commentaire
Comment l'éditeur Elementor charge un brouillon sans recharger la page

admin-ajax.php apparaît des dizaines de fois dans l’onglet réseau du navigateur dès qu’on ouvre l’éditeur Elementor sur un brouillon. Ce détail, visible par n’importe qui ouvre les outils de développement pendant une session d’édition, révèle le mécanisme central qui permet à l’aperçu de se mettre à jour instantanément sans jamais recharger la page dans son ensemble.

Comprendre ce mécanisme aide à mieux diagnostiquer les situations où l’aperçu semble « en retard » par rapport aux modifications faites dans le panneau, un symptôme qui remonte régulièrement dans les tickets de support d’agences travaillant avec Elementor au quotidien.

Le principe général : une interface, deux zones

L’éditeur Elementor sépare visuellement deux zones qui communiquent en permanence : le panneau de gauche, une application JavaScript autonome construite avec Backbone.js et Marionette.js, et la zone d’aperçu à droite, chargée dans une iframe distincte. Modifier un réglage dans le panneau ne provoque jamais un rechargement de cette iframe : à la place, le panneau envoie les nouvelles valeurs directement au script chargé à l’intérieur de l’aperçu, via des messages échangés en JavaScript entre les deux contextes.

Ce qui se passe réellement à l’enregistrement

L'essentiel à retenir : L'éditeur ne recharge jamais la page complète pendant l'édition ; Des requêtes internes transmettent la structure mise à jour ; L'aperçu se régénère uniquement pour la partie modifiée

Deux mécanismes distincts entrent en jeu selon le moment. Pendant la frappe, la mise à jour visuelle dans l’aperçu se fait localement, sans aller-retour serveur : le JavaScript de l’éditeur reconstruit directement le fragment de HTML concerné. En revanche, dès qu’un enregistrement (automatique ou manuel) se déclenche, une requête part réellement vers le serveur, généralement vers admin-ajax.php avec une action dédiée, pour persister la structure mise à jour dans la métadonnée _elementor_data.

// Exemple simplifié de ce que reçoit le serveur
POST /wp-admin/admin-ajax.php
action=elementor_save_builder
post_id=482
data={"elements":[...]}

Ce découpage explique pourquoi une coupure réseau ponctuelle pendant l’édition ne casse pas immédiatement l’expérience visuelle : les modifications restent visibles localement, mais elles ne sont pas persistées tant que la requête d’enregistrement n’a pas abouti. C’est aussi la raison pour laquelle Elementor affiche un indicateur d’enregistrement en cours dans la barre supérieure de l’éditeur.

Le rôle du brouillon automatique

WordPress dispose nativement d’un système de brouillon automatique, matérialisé par le statut de post auto-draft puis draft. Elementor s’appuie sur cette mécanique existante plutôt que d’en réinventer une : chaque enregistrement automatique déclenché depuis l’éditeur crée ou met à jour une révision, consultable ensuite depuis l’historique des révisions de WordPress, indépendamment de la version publiée du contenu.

  • Le contenu publié reste inchangé tant que le bouton « Publier » n’a pas été activé.
  • Le brouillon se met à jour régulièrement, sans intervention manuelle.
  • L’historique des révisions permet de revenir à un état antérieur en cas d’erreur.

Ce que cela signifie pour le diagnostic d’un problème d’aperçu

Quand un client signale que « ses modifications ne s’affichent pas », deux causes bien distinctes doivent être écartées séparément : un problème d’affichage local dans le navigateur (souvent réglé par un rafraîchissement simple de l’éditeur) ou un échec réel de l’enregistrement côté serveur, généralement lié à un plugin de sécurité qui bloque certaines requêtes vers admin-ajax.php. Confondre les deux mène à des heures de diagnostic inutile.

Avant de suspecter un bogue d’Elementor, vérifier l’onglet réseau du navigateur pour confirmer que la requête d’enregistrement part bien et reçoit une réponse positive.

En résumé

L’éditeur Elementor ne recharge jamais la page complète pendant une session d’édition : il combine une mise à jour visuelle locale et des requêtes internes ponctuelles vers le serveur pour persister les changements. Ce mécanisme concerne strictement l’expérience d’édition ; il ne doit pas être confondu avec l’API REST publique de WordPress, que le site expose éventuellement pour d’autres usages, un sujet qui dépasse le cadre de cet article.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Partager :

À propos de l'auteur

WordPress Développement

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi