Plugin fatal errors sur WooCommerce - Causes & solutions

Symptômes : comment confirmer le diagnostic

Une erreur fatale plugin WooCommerce ne se présente pas toujours de la même façon selon que l'affichage des erreurs PHP est activé ou non. Avant de toucher quoi que ce soit, identifie précisément ce que tu vois — cela oriente déjà vers la cause.

• Page front et/ou admin affichant « Une erreur critique est survenue sur ce site » (Recovery Mode WordPress 5.2+) au lieu du contenu attendu.
• Page blanche (WSOD) sur les pages catégories, fiches produit, panier ou checkout, alors que le reste du site répond encore.
• Un e-mail automatique envoyé à l'adresse `admin_email` intitulé « Votre site rencontre un problème technique », contenant un lien de connexion en mode récupération qui nomme déjà le plugin ou le thème incriminé.
• Avec WP_DEBUG_DISPLAY actif : un message PHP brut du type `Fatal error: Uncaught Error: ...` directement à l'écran, avec un chemin de fichier dans `/wp-content/plugins/`.
• Sections d'admin cassées juste après la mise à jour d'une extension, d'un thème ou du cœur WooCommerce.

1. Note le message exact à l'écran (capture d'écran ou copier-coller). Le verbatim est ce qui permet de mapper l'erreur à sa cause dans le tableau plus bas.
2. Vérifie si tu accèdes encore à `wp-admin`. C'est le critère qui décide du chemin de réparation (admin accessible vs FTP). Teste aussi `/wp-login.php` — l'erreur peut bloquer le front mais pas le back-office, ou l'inverse.
3. Regarde si tu as reçu l'e-mail de Recovery Mode : il contient déjà le nom du plugin fautif et un lien d'accès isolé, ce qui peut t'éviter toute manipulation FTP.

Impact business immédiat

Une erreur fatale sur WooCommerce ne dégrade pas l'expérience : elle la coupe net. Comprendre le coût réel aide à arbitrer entre « je tente un fix rapide en prod » et « je passe par un staging ».

Plus la panne touche le checkout ou la page produit, plus la perte est directe et chiffrable. Une erreur sur le panier équivaut à 100 % de pertes de conversion sur la session concernée.

• Boutique partiellement ou totalement indisponible : tunnel de vente interrompu, donc revenu à zéro sur les pages touchées tant que le bug persiste.
• Budget acquisition gaspillé : les clics Google Ads / Meta continuent d'arriver sur une page cassée, le coût par acquisition explose.
• Perte de confiance interne et client : l'équipe panique, les clients qui tombent sur l'erreur ne reviennent pas forcément.
• Risque SEO si la panne dure : des codes 500 répétés sur les URLs produit peuvent faire désindexer temporairement des pages.
• Aucune perte de données : produits, commandes et clients vivent en base de données (tables `wp_posts`, `wp_wc_orders`, `wp_postmeta`), pas dans les fichiers du plugin. Réinstaller WooCommerce ne supprime rien.

Causes classées par probabilité

Sur WooCommerce, les erreurs fatales plugin se répartissent en un petit nombre de causes récurrentes. Les voici de la plus fréquente à la plus rare, avec leur signature dans les logs.

• 1. Mise à jour d'une extension qui casse (très fréquent) : un fichier de la nouvelle version est manquant ou appelle une fonction d'un autre plugin pas encore chargé. Signature : `Failed opening required ...` ou `Call to a member function ... on null`.
• 2. Incompatibilité PHP (fréquent) : passage de PHP 7.4 à 8.0/8.1/8.2 chez l'hébergeur, et un vieux plugin utilise une syntaxe ou une fonction supprimée. Signature : `Uncaught TypeError` ou `Uncaught Error: Call to undefined function`.
• 3. Conflit entre extensions (fréquent sur le checkout) : deux plugins qui surchargent les mêmes hooks WooCommerce (`woocommerce_checkout_process`, fragments panier). Signature : erreur sur `get_cart()` ou sur un objet WooCommerce non instancié.
• 4. Mémoire PHP insuffisante (sous-estimé) : un import produit ou un plugin lourd dépasse la limite. Signature : `Allowed memory size of X bytes exhausted`.
• 5. Fichiers corrompus ou MAJ interrompue : upload FTP coupé, droits cassés. Signature : `Failed opening required` ou erreur de permissions.
• 6. Bug du cœur WooCommerce lui-même (rare mais réel) : ex. l'incident block patterns du 6 mai 2025 — `strpos(): Argument #1 ($haystack) must be of type string, null given` dans `plugins/woocommerce/src/Blocks/BlockPatterns.php` ligne 251, corrigé en 9.8.4.

Diagnostic : les commandes à lancer

Ne désactive jamais des plugins au hasard : tu perdrais la trace du coupable. La règle est de diagnostiquer d'abord. Le chemin de fichier dans le message d'erreur désigne presque toujours directement le plugin fautif.

Active d'abord le journal de débogage, reproduis l'erreur, puis lis les logs. WooCommerce écrit aussi ses propres logs séparément du cœur WordPress.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );    // écrit dans wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // ne PAS afficher l'erreur aux visiteurs
// Pense à tout remettre à false et à supprimer debug.log après diagnostic

# Log WordPress global (après avoir activé WP_DEBUG_LOG)
tail -n 50 wp-content/debug.log

# Logs WooCommerce dédiés : cherche les fichiers fatal-errors-*
ls -lt wp-content/uploads/wc-logs/
tail -n 50 wp-content/uploads/wc-logs/fatal-errors-*.log

# Isoler les lignes Fatal error et le plugin pointé
grep -i "fatal error" wp-content/debug.log
grep -iE "wp-content/plugins/[^/]+" wp-content/debug.log | head

# Selon l'hébergeur, le log PHP-FPM/Apache se trouve souvent ici :
tail -n 50 ~/logs/error.log
tail -n 50 /var/log/php-fpm/www-error.log
grep -i "PHP Fatal" ~/logs/error.log | tail

php -v
# ou via WP-CLI, qui reflète l'environnement WordPress
wp eval 'echo PHP_VERSION;'

Tableau : message d'erreur → cause → correction

Garde ce tableau ouvert pendant le diagnostic. Repère ta ligne d'erreur exacte, identifie la cause, applique le fix correspondant détaillé dans la section suivante.

• `Failed opening required '.../plugins/xxx/yyy.php'` → fichier de plugin manquant/corrompu (souvent une MAJ ratée, ex. WooCommerce Services et son `StoreNoticesNotifier.php`) → réinstaller proprement le plugin.
• `Call to a member function get_cart() on null` (dans `.../plugins/example-plugin/...your-page.php`) → conflit : un plugin appelle WooCommerce avant qu'il soit instancié → désactiver/mettre à jour le plugin pointé par le chemin.
• `Uncaught Error: Call to undefined function ...` ou `Uncaught TypeError` → incompatibilité PHP (fonction dépréciée supprimée en PHP 8+) → mettre le plugin à jour ou redescendre la version PHP.
• `Allowed memory size of N bytes exhausted` → mémoire PHP saturée → augmenter `WP_MEMORY_LIMIT`.
• `strpos(): Argument #1 ($haystack) must be of type string, null given` dans `woocommerce/src/Blocks/BlockPatterns.php:251` → bug cœur WooCommerce du 6 mai 2025 → mettre à jour vers WooCommerce 9.8.4 + purger le transient `ptk_patterns`.

Solutions pas-à-pas

Le bon chemin dépend d'une seule question : as-tu encore accès à `wp-admin` ? C'est l'arbre de décision que les guides oublient le plus souvent.

1. ARBRE DE DÉCISION — As-tu accès à wp-admin ? OUI → étapes Cas A. NON → vérifie d'abord l'e-mail de Recovery Mode (Cas C), sinon passe par FTP/SSH (Cas B).
2. CAS A (admin accessible) : va dans Extensions, désactive le plugin pointé par le log, recharge le site. Si l'erreur disparaît, supprime puis réinstalle la dernière version stable du plugin (ou son rollback). Une seule extension à la fois pour ne pas casser une fonction critique.
3. CAS B (admin inaccessible, FTP/SSH) : connecte-toi en FTP, va dans `/wp-content/plugins/` et renomme le dossier du plugin fautif, par exemple `mon-plugin` → `mon-plugin_off`. WordPress le désactive automatiquement et le site revient. Remets ensuite le bon nom une fois le plugin corrigé.
4. CAS B en ligne de commande (plus rapide) : `wp plugin deactivate <slug> --skip-plugins --skip-themes` pour désactiver sans charger le code fautif. Si tu ne connais pas le slug : `wp plugin list --status=active`.
5. CAS C (Recovery Mode WordPress 5.2+) : ouvre le lien reçu par e-mail (ou `https://ton-site.fr/wp-login.php?action=enter_recovery_mode`). Tu accèdes à un admin isolé où le plugin fautif est déjà désactivé — corrige-le puis « Quitter le mode de récupération ».
6. TEST DE CONFLIT OFFICIEL (si la cause reste floue) : bascule temporairement sur le thème Storefront, désactive TOUTES les extensions sauf WooCommerce, vérifie que l'erreur disparaît, puis réactive les plugins un par un jusqu'à ce que l'erreur revienne — le dernier réactivé est le coupable.
7. RÉINSTALLER WOOCOMMERCE proprement (sans perdre de données) : `wp plugin install woocommerce --force` réécrit les fichiers du cœur. Tes produits et commandes restent en base, rien n'est supprimé. En manuel : supprime le dossier `/wp-content/plugins/woocommerce/` puis ré-uploade la version officielle.
8. FIX MÉMOIRE si `Allowed memory size ... exhausted` : ajoute `define( 'WP_MEMORY_LIMIT', '256M' );` dans wp-config.php (et `WP_MAX_MEMORY_LIMIT` à `512M` pour l'admin).
9. FIX PERMISSIONS si `Failed opening required` ou erreurs d'accès : `find wp-content/plugins -type d -exec chmod 755 {} \;` puis `find wp-content/plugins -type f -exec chmod 644 {} \;`.
10. NETTOYAGE FINAL : remets `WP_DEBUG` et `WP_DEBUG_LOG` à `false`, supprime `wp-content/debug.log` (il est public par défaut), et purge le cache (objet + page + CDN).

Spécificités par version

Le comportement et les pièges changent selon la version de WooCommerce et de PHP en jeu. Vérifie ta combinaison avant de corriger.

• WooCommerce 7.x → 8.x (HPOS) : la 8.x active la table `wp_wc_orders` (High-Performance Order Storage). Une extension non migrée qui lit encore les commandes via `wp_posts`/`wp_postmeta` peut déclencher une erreur fatale. Vérifie la compatibilité HPOS dans WooCommerce → Statut → Fonctionnalités avant d'activer le stockage haute performance.
• WooCommerce 9.x / incident 9.8.4 (6 mai 2025) : les versions antérieures à 9.8.4 pouvaient planter sur les block patterns avec `strpos(): ... null given` dans `BlockPatterns.php:251`. Correctif : passer en 9.8.4+ (null-check dans `parse_categories()`) puis purger le transient — `wp transient delete ptk_patterns --skip-themes --skip-plugins` ou en SQL `DELETE FROM wp_options WHERE option_name = '_transient_ptk_patterns';`.
• Incident WooCommerce Services : une MAJ a livré un `StoreNoticesNotifier.php` manquant/non chargé, provoquant un `Failed opening required` sur des milliers de sites. Fix : désactiver puis réinstaller WooCommerce Shipping & Tax / WooCommerce Services à sa dernière version.
• PHP 7.4 vs 8.0–8.2 : WooCommerce récent supporte PHP 7.4 à 8.2. Beaucoup de plugins tiers anciens cassent sur PHP 8+ (arguments typés stricts, fonctions supprimées). Si l'hébergeur vient de forcer une montée de version, redescends temporairement en PHP 7.4 le temps de mettre à jour les extensions, puis remonte.
• WordPress < 5.2 : pas de Recovery Mode ni d'e-mail de récupération. Sur ces versions, le seul recours sans admin est le FTP. Une raison de plus de maintenir WordPress à jour.

Prévention : éviter que ça recommence

La plupart de ces incidents naissent d'une mise à jour faite directement en production. Quelques réflexes suppriment 90 % du risque.

• Un environnement de staging : teste toute MAJ (cœur, extension, thème, version PHP) sur une copie avant la prod.
• Sauvegarde avant chaque mise à jour : base de données + `wp-content/plugins`, pour pouvoir comparer les versions et restaurer en minutes.
• Mettre à jour une extension à la fois : si quelque chose casse, tu sais immédiatement quel plugin est en cause.
• Activer WP_DEBUG_LOG en continu sur staging (jamais l'affichage en prod) pour repérer les erreurs PHP latentes avant qu'elles ne deviennent fatales.
• Surveiller la matrice de compatibilité : version PHP de l'hébergeur, version WooCommerce, statut HPOS, et compatibilité déclarée de chaque extension critique du checkout.

Quand appeler un expert

La majorité de ces erreurs se règlent seul avec les étapes ci-dessus. Mais certains signaux justifient de déléguer pour limiter la casse business.

Si la perte de chiffre d'affaires par heure dépasse largement le coût d'une intervention, ne joue pas à l'apprenti sorcier en production.

• L'erreur revient après réinstallation et le test de conflit ne désigne aucun plugin clair (corruption base de données, table HPOS désynchronisée, ou bug serveur).
• Tu n'as ni accès FTP/SSH ni e-mail de Recovery Mode, et l'hébergeur ne donne pas les logs PHP.
• Le checkout est touché et chaque heure d'indisponibilité coûte cher : un diagnostic rapide vaut mieux qu'un site cassé toute la journée.
• Le correctif exige de modifier du code d'extension ou de gérer une migration HPOS sur un catalogue volumineux.
• Chez BugRescue, Soulaimane Aattar et son équipe diagnostiquent l'erreur fatale, identifient le plugin ou la version PHP en cause, remettent la boutique en ligne sans perte de données, puis sécurisent un process de mise à jour pour éviter la récidive.

FAQ