Divi Theme Builder : diagnostiquer « An unknown error has occurred »

Identifier le niveau du Theme Builder qui échoue

Vous ouvrez Divi > Theme Builder et l’écran affiche « An unknown error has occurred ». Le même message peut apparaître lorsque vous essayez d’ouvrir l’en-tête, le corps ou le pied de page d’un modèle. Elegant Themes documente ce symptôme. Le message ne désigne aucun composant précis. Commencez par noter si toute la liste de modèles est inaccessible, si un seul modèle est concerné ou si la zone s’ouvre et échoue seulement à l’enregistrement.

Le Theme Builder gère les modèles et leurs affectations. Un même en-tête peut servir à plusieurs pages, tandis qu’un autre modèle peut être réservé à une catégorie ou à un document. Une panne lors de l’ouverture d’une zone n’indique pas à elle seule que son contenu a disparu. Dans un nouvel onglet, ouvrez une page publique qui devrait utiliser ce modèle et une page qui devrait en utiliser un autre. Gardez leur état comme référence. Si le site public affiche encore l’ancien en-tête, vous disposez d’un témoin utile sans toucher à la console.

Relevez la version de Divi dans Apparence > Thèmes, puis la version de WordPress et de PHP depuis le tableau de bord ou le panneau d’hébergement. Les commandes et leur emplacement peuvent varier entre Divi 4 et Divi 5. Vérifiez d’abord quelle interface est réellement ouverte. Sur un service hébergé, certains journaux ou réglages PHP appartiennent à l’hébergeur. En multisite, notez le sous-site où l’erreur apparaît et faites confirmer par l’administrateur réseau la portée des composants partagés.

Choisissez une action de comparaison qui ne modifie pas le site public. Si l’ouverture du corps d’un modèle déclenche le message, ouvrez ce même corps lors de chaque essai. Si la liste entière échoue, comparez la même entrée de menu. Un essai dans l’éditeur d’une page ordinaire peut aider à délimiter le symptôme, mais ne remplace pas le témoin dans la console des modèles.

Sauvegarder les modèles et leurs affectations

Si la console est encore utilisable, repérez les modèles attribués aux pages importantes. Notez pour chacun les conditions d’inclusion et d’exclusion, ainsi que les zones partagées avec le modèle général. Prenez une capture en masquant les noms de clients ou d’espaces privés. Une sauvegarde de la disposition seule ne suffit pas à retrouver avec certitude les pages qui devaient l’utiliser.

Dans Divi > Theme Builder, ouvrez l’outil de portabilité lorsque l’interface le permet. L’éditeur documente l’export de tous les modèles ou d’une sélection vers un fichier JSON. Sélectionnez le périmètre voulu, exportez et vérifiez que le fichier est présent dans un espace privé. Conservez aussi les affectations relevées. Si le défaut empêche l’export, demandez au responsable de confirmer une sauvegarde récente et exploitable de la base et des fichiers. Gardez l’interface en défaut comme témoin plutôt que d’essayer des imports pour la débloquer.

Avant une désactivation de composant ou une modification de modèle, préparez une copie représentative. Elle doit reprendre la version du thème, les extensions, les modèles et les affectations que vous voulez comparer. Si la copie peut envoyer des courriels ou appeler des intégrations, neutralisez ces actions externes. Une copie simplifiée peut suffire pour constater qu’un modèle isolé s’ouvre. Elle ne prouve pas que le même modèle fonctionne avec toutes les dépendances de la configuration réelle.

1. Notez le modèle, la zone qui échoue et deux pages témoins.
2. Exportez les modèles si l’interface le permet et vérifiez le fichier obtenu. Sinon, confirmez le point de restauration disponible.
3. Sur la copie, relevez le thème actif, le thème enfant éventuel et les extensions nécessaires pour reproduire le défaut.

Approche 1. Comparer avec le mode sans échec de Divi

Cette approche convient si le tableau de bord reste accessible et que votre version propose Safe Mode. Dans Divi > Support Center, ouvrez la section Safe Mode. Activez l’option avec votre compte, puis revenez à Divi > Theme Builder. La documentation décrit l’isolation de composants tiers, du thème enfant et de code personnalisé pour le compte qui a activé ce mode. Les visiteurs continuent de recevoir la configuration habituelle. Le mode sert à lire le résultat d’un essai. Toute modification que vous enregistrez doit être traitée comme une écriture réelle.

Refaites seulement l’ouverture qui échouait. Si le même modèle s’ouvre, le résultat oriente vers l’un des composants que le mode a isolés. Il n’identifie pas encore lequel. Si le message reste identique, quittez le mode et passez à l’observation réseau. Une différence de temps d’ouverture avec le même message d’échec demande encore une preuve. Notez le statut et l’étape réellement atteinte dans chaque état.

1. Ouvrez Divi > Support Center et relevez l’état initial de Safe Mode.
2. Activez ce mode et tentez d’ouvrir exactement la même zone du même modèle.
3. Notez si la liste se charge, si la zone s’ouvre et si l’erreur revient. Laissez le contenu sans enregistrement pendant cette comparaison.
4. Remettez Safe Mode dans son état initial. Si le test change le résultat, poursuivez l’isolement sur une copie.

Repérer le composant par réintroduction progressive

Si Safe Mode permet d’ouvrir le modèle, utilisez une copie pour rechercher ce qui change. Gardez la liste des extensions actives et le nom du thème d’origine. Désactivez sur la copie les extensions tierces nécessaires à la comparaison, en préservant celles sans lesquelles le témoin perdrait tout son sens. Si un modèle affiche des données WooCommerce, un essai sans WooCommerce peut montrer que la console s’ouvre, mais il ne permet pas de confirmer le bon affichage des données. Distinguez le test d’ouverture et le test de rendu.

Comparez ensuite un seul groupe de changements à la fois. Le thème enfant peut ajouter du code PHP ou un script dans l’administration. Les intégrations personnalisées peuvent aussi agir hors des extensions affichées dans la liste courante. Sur la copie, comparez l’état du thème enfant à celui du thème parent lorsque cette variation est possible. Si une extension est la piste la plus forte, réactivez-la avec ses dépendances immédiates, puis rouvrez le même modèle. Pour un ensemble important, réintroduisez des groupes cohérents avant de réduire le groupe qui déclenche l’échec.

1. Reproduisez d’abord l’erreur sur la copie dans son état habituel. Relevez l’état des extensions et du thème.
2. Réduisez les composants tiers sur la copie et rouvrez le témoin. Si l’ouverture réussit, réintroduisez un groupe ou une dépendance à la fois.
3. Quand l’échec réapparaît, confirmez la différence par un second essai avec et sans le composant suspect.
4. Rétablissez la configuration initiale sur la copie. Préparez une correction ciblée pour la version ou le composant confirmé.

Approche 2. Suivre la requête de la console des modèles

Si le mode sans échec ne change pas le résultat ou si le défaut survient pendant une opération précise, ouvrez les outils de développement. Dans Réseau, effacez les lignes précédentes et activez Preserve log si l’interface change de page. Dans Divi > Theme Builder, ouvrez une seule fois la liste ou la zone qui échoue. Repérez la demande qui correspond à l’instant du message. Pour une zone intégrée, la demande peut être celle d’un document, tandis que la console elle-même peut charger des données en arrière-plan. Inspectez les deux types lorsque le filtre Fetch/XHR ne révèle rien.

Relevez le statut, le chemin et la nature du corps renvoyé. Une page de connexion dans la réponse invite à vérifier la session. Une page de protection avec un identifiant demande une recherche dans le journal du service qui filtre la demande. Une réponse 500 suivie d’un message d’erreur dans le journal PHP oriente vers le composant ou la limite qui a interrompu le traitement. Un statut 200 peut contenir une réponse inattendue, par exemple une page HTML à la place des données attendues par l’interface. Comparez la réponse à celle d’un modèle sain ou de la copie.

1. Notez l’heure avec le fuseau, le chemin, le statut et la zone du modèle.
2. Cherchez la première réponse anormale dans la suite liée à cette action. Gardez un court extrait anonymisé.
3. Corrélez l’heure au journal de l’hébergement ou de PHP. Si la demande n’atteint pas WordPress, cherchez d’abord dans la couche qui a répondu.
4. Refaites une seule ouverture après la correction ciblée. Vérifiez que le message disparaît et que la bonne zone devient modifiable.

Traiter la cause révélée par le journal

Dans Divi > Support Center > System Status, comparez les informations sur WordPress, PHP et les limites disponibles. Un voyant jaune ou rouge indique un écart à examiner. Il ne prouve pas que cet écart a déclenché la panne. Si la ligne correspondante du journal signale un épuisement de mémoire, demandez quelle limite s’applique à la requête web et quel traitement a consommé la mémoire. Si le journal nomme une extension ou un fichier du thème enfant, comparez sa version à celle de la copie où le modèle s’ouvre.

Le support d’Elegant Themes propose aussi de contrôler les permaliens et le protocole. Réservez ces contrôles au résultat qui les justifie. Une réponse 404 sur la route réelle ou une redirection vers une adresse inattendue mérite un relevé du chemin et du serveur concerné. Vérifiez d’abord sur la copie la configuration des liens et les adresses de WordPress dans Réglages > Général. Une installation en sous-dossier peut avoir deux adresses différentes de manière intentionnelle. Évitez de les égaliser à l’aveugle. Si la réparation concerne le serveur web ou le proxy HTTPS, faites préparer le retour de configuration avant de la reproduire en service.

Sur une copie, le journal WordPress peut compléter le journal du serveur si vous ne voyez pas l’erreur PHP. Demandez au mainteneur de relever les valeurs initiales de WP_DEBUG, WP_DEBUG_LOG et WP_DEBUG_DISPLAY sur la copie. Si la collecte WordPress est nécessaire, demandez un chemin de journal privé et non servi par le site, puis vérifiez que l’affichage des erreurs reste désactivé. Les données du journal peuvent contenir des chemins ou des informations privées. Après l’essai, restaurez les trois réglages et traitez le fichier de diagnostic selon les règles de conservation du site. Pour un défaut apparu après une mise à jour, changez un seul composant à la fois sur la copie et gardez une sauvegarde adaptée à cette version.

Approche 3. Isoler un modèle particulier sur une copie

Cette approche convient si la liste des modèles s’ouvre et si plusieurs zones fonctionnent, alors qu’un modèle ou une partie précise déclenche l’erreur. Confirmez d’abord cette différence avec un modèle témoin comparable. Un en-tête global et un pied de page propre à une seule page ne sollicitent pas forcément les mêmes modules. Choisissez une zone qui partage autant que possible les mêmes dépendances et notez ce qui change.

Sur la copie, créez un modèle de contrôle à partir d’une disposition simple ou dupliquez le modèle suspect lorsque votre version le permet. Vérifiez ses affectations avant d’enregistrer. Assignez le témoin à une page de test dédiée et conservez un second document qui ne doit pas l’utiliser. Dans Divi 5, le constructeur de la zone et la console des modèles peuvent présenter deux commandes distinctes. Enregistrez la zone si vous l’avez modifiée, revenez à Divi > Theme Builder, puis utilisez Save Changes pour confirmer les modifications de la console. Relisez la liste et l’affectation après rechargement.

Si la zone simple fonctionne, rapprochez-la de l’original par ajouts ciblés. Un module ou une référence de contenu dynamique peut échouer uniquement lorsqu’il est chargé dans une zone précise. Réintroduisez un groupe à la fois, en gardant la page test et son affectation. Lorsque l’erreur revient, vérifiez le réglage du module, son contexte et sa dépendance. Vous pouvez conserver le modèle original pour le retour pendant que vous préparez une correction sur le témoin.

Un import depuis un export connu peut servir de comparaison sur la copie. Dans la fenêtre de portabilité, lisez les options avant de confirmer. Override Existing Default Website Template peut remplacer le modèle général lorsque le fichier en contient un. Override Existing Assignments peut remplacer des affectations déjà utilisées. Laissez ces deux options désactivées si vous cherchez seulement à observer une disposition importée. Laissez aussi Import Preset désactivé pour éviter d’ajouter les préréglages du fichier. Gardez un export du périmètre avant l’import et vérifiez ensuite quels modèles et quelles affectations ont réellement été ajoutés. Lorsque les identifiants de pages diffèrent entre deux sites, confirmez l’affectation par son nom et par l’adresse de test.

1. Vérifiez qu’un modèle simple s’ouvre avec une affectation réservée au témoin.
2. Ajoutez progressivement les éléments de la zone en défaut ou importez le seul modèle nécessaire sur la copie.
3. Contrôlez la zone, son affectation, la page cible et la page témoin. Si l’erreur revient, retirez le dernier changement et confirmez la différence.
4. Pour revenir à l’état précédent, rétablissez l’affectation d’origine sur la copie et retirez seulement le modèle de test dont vous avez vérifié l’identité. Enregistrez le retour dans la console, rechargez-la puis contrôlez les deux pages témoins.

Vérifier le rendu et fermer l’investigation

Une console qui s’ouvre de nouveau constitue un premier résultat. Ouvrez la zone qui échouait, contrôlez que ses éléments sont présents puis quittez le mode sans échec si vous l’aviez utilisé. Sur la copie, appliquez une modification anodine et vérifiez qu’elle se retrouve après rechargement. Si la modification concerne une affectation, contrôlez aussi la console des modèles après Save Changes. Un modèle peut être éditable alors que la page publique continue d’utiliser un autre modèle.

Vérifiez la page visée, une page qui doit garder un modèle différent et, pour un en-tête ou un pied de page partagé, une autre page qui l’utilise. Sur téléphone, contrôlez le menu et les éléments qui dépendent du contexte. Si l’administration et l’affectation sont correctes mais que le rendu public reste ancien, examinez le cache à ce stade. Ne modifiez pas une seconde fois le modèle uniquement parce que le public reçoit une ancienne réponse.

Pour transmettre le problème, indiquez la version de Divi, la zone concernée, le résultat avec et sans Safe Mode, le statut réseau et la première erreur horodatée. Ajoutez l’identifiant du modèle si vous pouvez l’obtenir sans exporter son contenu privé. Gardez séparés le fichier d’export et le relevé que vous partagez. Le retour attendu consiste à retrouver l’ouverture du Theme Builder dans sa configuration habituelle et à vérifier que chaque page témoin utilise encore la disposition prévue.