WPBakery en panne : diagnostic et corrections

WPBakery plante : ce qui se passe et pourquoi c’est récupérable

L’éditeur backend qui affiche une page blanche, des [vc_row][vc_column] qui s’impriment en clair sur le site, une erreur de licence qui bloque tout accès — WPBakery (anciennement Visual Composer) a une fâcheuse habitude : il casse sans prévenir, souvent après une mise à jour WordPress ou l’installation d’un nouveau plugin.

Bonne nouvelle : la plupart des pannes sont connues, documentées, et résolvables sans toucher une seule ligne de code complexe. Ce guide passe les cas les plus fréquents en revue, du plus simple au plus chirurgical.

Pourquoi WPBakery tombe en panne

• Conflit de scripts JS : WPBakery charge une pile de fichiers JavaScript. Un autre plugin (Elementor, Divi, ACF, un plugin de cache agressif) peut bloquer ou écraser ces scripts.
• Droits insuffisants : le rôle utilisateur connecté n’a pas accès à l’éditeur backend — souvent après une migration ou un changement d’hébergeur.
• Mémoire PHP épuisée : WPBakery est gourmand. Sous 128 Mo, l’éditeur se charge à moitié ou pas du tout.
• Licence invalide ou expirée : depuis WPBakery 6.x, certaines fonctionnalités (et mises à jour) nécessitent une clé active.
• Version obsolète : une version de WPBakery trop ancienne pour la version de WordPress installée, ou vice-versa.
• Cache serveur ou navigateur : l’éditeur chargé dans un état cassé, mis en cache, réapparaît à chaque rechargement.
• Shortcodes orphelins : le plugin est désactivé ou supprimé sans nettoyage préalable — tous les shortcodes restent dans la base de données et s’affichent en clair.

1. Vider le cache en premier (toujours)

Avant tout diagnostic : videz le cache. Cela résout 20 % des pannes sans autre intervention.

1. Dans l’admin WordPress → plugin de cache installé (WP Rocket, LiteSpeed Cache, W3 Total Cache…) → Vider tout le cache.
2. Videz aussi le cache de votre navigateur (Ctrl+Shift+R / Cmd+Shift+R) ou ouvrez en navigation privée.
3. Si votre hébergeur propose un cache serveur (Kinsta, WP Engine, O2switch…), videz-le également depuis le panel.

Si l’éditeur réapparaît : c’était un problème de cache. Si non, continuez.

2. Backend editor invisible ou écran blanc

C’est la panne la plus signalée. L’éditeur tourne, tourne, et n’affiche rien.

Vérifier la mémoire PHP

WPBakery recommande au minimum 256 Mo. Ajoutez cette ligne dans votre wp-config.php, juste avant /* That's all, stop editing! */ :

define('WP_MEMORY_LIMIT', '256M');

Si vous avez accès au php.ini (via SSH ou panel hébergeur) :

memory_limit = 256M
max_execution_time = 120

Pour aller plus loin sur ces directives, l’article sur l’erreur 413 WordPress explique le rôle de chaque paramètre PHP et où les modifier selon votre hébergeur.

Désactiver les autres plugins un par un

En mode incognito, désactivez tous les plugins sauf WPBakery. Si l’éditeur revient, réactivez les plugins un à un pour identifier le coupable. Les suspects habituels : plugins de sécurité (Wordfence), optimisation JS (Autoptimize), ou un second page builder.

Vérifier les droits utilisateur

Dans Réglages → Visual Composer → Rôle des utilisateurs, vérifiez que votre rôle (Administrateur) a bien accès à l’éditeur backend. Cochez les cases si nécessaire.

3. Shortcodes [vc_row] affichés en clair sur le site

Si vos pages publiées affichent [vc_row][vc_column text_tc="..."][/vc_column][/vc_row] en clair, c’est que WPBakery n’est plus actif pour interpréter ses propres shortcodes.

Causes possibles :

• Plugin désactivé ou supprimé accidentellement.
• Conflit de chargement qui empêche l’init de WPBakery.
• Migration depuis un autre hébergeur sans emporter le plugin.

Résolution :

1. Allez dans Extensions → Extensions installées : WPBakery est-il bien actif ? S’il est désactivé, réactivez-le.
2. S’il n’est pas installé, réinstallez-le depuis votre compte codecanyon.net (achat original) ou depuis le panel thème si WPBakery était bundlé avec votre thème.
3. Si WPBakery est actif mais les shortcodes persistent : désactivez tous les autres plugins, puis testez. Un plugin de cache ou un optimiseur peut court-circuiter le filtre do_shortcode.

Attention : si vous décidez d’abandonner WPBakery définitivement, utilisez le plugin WPBakery Shortcode Cleaner (ou équivalent) pour convertir ou supprimer les shortcodes avant désinstallation. Sinon, votre base de données garde ces shortcodes pour toujours.

4. Conflit après mise à jour WordPress ou WPBakery

Une mise à jour WordPress ou WPBakery 7.x qui casse l’éditeur, c’est classique. Si vous avez besoin de faire un rollback propre d’un plugin, la procédure détaillée est ici.

Pour WPBakery spécifiquement :

1. Téléchargez la version précédente depuis votre compte codecanyon.
2. Désactivez la version actuelle, supprimez-la.
3. Installez la version antérieure manuellement (upload du ZIP via Extensions → Ajouter → Téléverser).
4. Testez l’éditeur avant de remettre à jour.

Si la MAJ vient de WordPress (pas de WPBakery) : vérifiez la compatibilité de votre version de WPBakery sur la page changelog du plugin avant toute mise à jour.

5. Problème de licence

Depuis la version 6.x, WPBakery affiche des alertes de licence et peut limiter les mises à jour automatiques si la clé n’est pas activée.

1. Allez dans WPBakery → Licence dans votre admin.
2. Entrez la clé d’achat disponible sur votre compte codecanyon.net.
3. Si la clé est déjà saisie mais marquée invalide : déconnectez-la, sauvegardez, puis entrez-la à nouveau.
4. Si WPBakery est bundlé avec votre thème (Avada, BeTheme, The7…), la licence est gérée par le thème — cherchez dans Thème → Options → Enregistrement du thème.

Un WPBakery “nulled” (version piratée) n’a pas de licence valide et ne recevra jamais de mise à jour. Si c’est votre situation : achetez une licence légale ou migrez vers un autre builder.

6. Conflit avec un autre page builder

Faire tourner WPBakery et Elementor en même temps sur le même site, c’est une recette pour des conflits JS garantis. Si vous avez les deux actifs :

1. Décidez lequel vous gardez.
2. Désactivez l’autre complètement (et son constructeur de templates).
3. Rechargez l’éditeur WPBakery.

Si vous migrez de WPBakery vers Elementor, l’article sur l’optimisation WPBakery couvre la suppression propre des shortcodes résiduels et les précautions avant désinstallation.

Tableau récapitulatif

Quand passer la main à un pro

Si après ces étapes l’éditeur reste cassé, que les shortcodes persistent malgré WPBakery actif, ou que vous avez un conflit que vous n’arrivez pas à isoler — la piste la plus probable est un conflit profond dans les fichiers du thème ou une base de données corrompue. C’est le moment de brancher un accès SSH (comment l’activer sur Plesk) pour inspecter les logs d’erreur PHP en temps réel, ou de confier le diagnostic à quelqu’un qui peut lire ces logs sans risquer d’aggraver la situation. Une maintenance active évite précisément ce type de blocage : les conflits de version se détectent avant qu’ils cassent l’éditeur en production.