Fatal error: Cannot redeclare class WC_Product in /wp-content/plugins/extension-maison/includes/class-wc-product.php on line 12. Ce message apparaît en général au pire moment : juste après une mise en production, sur une boutique qui fonctionnait parfaitement une minute plus tôt en local. Le symptôme est classique, la cause l’est tout autant, et le correctif tient en une ligne une fois qu’on l’a identifiée.
Le contexte ici : un développeur déploie une extension maison sur une boutique WooCommerce via un script de synchronisation de fichiers, et casse la production en quelques secondes. Le site affiche une page blanche, les logs remontent l’erreur de redéclaration, et la panique monte vite quand des commandes sont en cours au moment de l’incident.
Symptôme : une page blanche et une classe qui existe déjà
PHP interdit de déclarer deux fois la même classe dans un même processus d’exécution. Quand cette règle est violée, PHP arrête tout net l’exécution du script avec une erreur fatale, avant même que WordPress ait pu afficher quoi que ce soit. Résultat : la boutique entière tombe, pas seulement la page concernée, puisque l’erreur survient dès le chargement des extensions, bien avant le rendu de la page demandée.
Le nom de la classe dans le message, ici WC_Product, ne doit pas tromper : il ne s’agit presque jamais d’un conflit entre deux extensions tierces qui redéfiniraient la même classe WooCommerce. C’est bien plus souvent une extension maison mal packagée qui inclut son propre fichier plusieurs fois, ou un fichier de classe personnalisé qui porte malencontreusement un nom déjà utilisé ailleurs dans le même chargement.
Diagnostic : retracer le chemin des inclusions
La première chose à faire est d’ouvrir le fichier et la ligne indiqués dans le message d’erreur, puis de chercher comment ce fichier est chargé dans l’extension. Deux cas reviennent le plus souvent : un include ou un require placé dans une boucle qui s’exécute plusieurs fois, ou le même fichier référencé à deux endroits distincts du code sans protection contre le double chargement.
Le rôle du script de déploiement
Dans le cas qui nous intéresse, le coupable n’est pas le code de l’extension lui-même mais le script de déploiement : une synchronisation de fichiers mal écrite copie le dossier de l’extension dans wp-content/plugins/extension-maison/, puis, à cause d’une erreur de chemin, le recopie une seconde fois dans un sous-dossier imbriqué du même répertoire de plugins. WordPress, en scannant le répertoire des extensions actives, finit par charger le même fichier de classe deux fois, sous deux chemins différents.
Correctif : sécuriser le fichier et nettoyer le déploiement
Deux actions distinctes s’imposent. D’abord, corriger l’inclusion elle-même en remplaçant tout require ou include par require_once ou include_once, qui vérifient si le fichier a déjà été chargé avant de l’inclure à nouveau. Ensuite, et surtout, corriger le script de déploiement qui a créé la duplication de dossiers en premier lieu.
// Avant : vulnérable à la double inclusion
require dirname( __FILE__ ) . '/includes/class-wc-product-custom.php';
// Après : protégé
require_once dirname( __FILE__ ) . '/includes/class-wc-product-custom.php';Une protection supplémentaire, peu coûteuse, consiste à entourer la déclaration de classe elle-même d’une vérification class_exists(), qui évite l’erreur fatale même si une inclusion en double venait à se reproduire malgré tout :
if ( ! class_exists( 'WC_Product_Custom' ) ) {
class WC_Product_Custom extends WC_Product {
// ...
}
}- Vérifier le chemin exact indiqué dans le message d’erreur avant toute autre action
- Remplacer les inclusions simples par des inclusions protégées contre le double chargement
- Nettoyer le répertoire de production pour supprimer les dossiers dupliqués par le déploiement
Un message qui cite une classe WooCommerce ne signifie pas toujours que WooCommerce est en cause : regardez d’abord ce qui inclut le fichier, pas la classe elle-même.
Prévention : fiabiliser le processus de déploiement
Ce type d’incident se répète tant que le script de déploiement reste artisanal. Une synchronisation qui supprime d’abord le dossier de destination avant de recopier les fichiers, plutôt que d’ajouter par-dessus une copie existante, élimine la cause racine. Un test simple avant chaque mise en production, consistant à activer les extensions sur une copie de la base en environnement de recette, aurait également révélé le problème avant qu’il n’atteigne les clients.
Notre verdict
Cette panne coûte cher en stress mais se résout en quelques minutes une fois le bon réflexe acquis : lire précisément le chemin de fichier dans le message d’erreur, chercher la duplication plutôt que le conflit, et corriger le processus de déploiement en plus du code. Ne traiter que le symptôme dans le code, sans revoir le script de mise en production, laisse la porte ouverte à une récidive au prochain déploiement.
