Corriger l’erreur fatale Post SMTP dans Settings

Si vous avez déjà cliqué sur Post SMTP → Settings et que WordPress vous répond par un écran blanc ou une erreur fatale, vous êtes dans le cas typique d’un bug déclenché uniquement dans l’admin, au chargement de la page de réglages.

Le problème

Le symptôme central : ouvrir la page de réglages de Post SMTP provoque une erreur PHP fatale. Souvent, le site reste accessible côté visiteurs, mais l’admin plante sur cette page précise.

Voici des messages d’erreur réalistes que j’ai vus dans les logs sur des sites WordPress 6.9.x (la formulation exacte varie selon l’hébergeur et le mode debug) :

Fatal error: Uncaught TypeError: array_merge(): Argument #2 must be of type array, string given
in /wp-content/plugins/post-smtp/Postman/PostmanViewController.php:1234
Stack trace:
#0 ...

Fatal error: Uncaught Error: Call to undefined function wp_get_environment_type()
in /wp-content/plugins/post-smtp/Postman/Postman.php:210

Fatal error: Uncaught Error: Class "VendorPackageSomeClass" not found
in /wp-content/plugins/post-smtp/vendor/.../autoload.php:...

Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes)
in /wp-content/plugins/post-smtp/.../Settings.php on line ...

Où ça apparaît :

Admin : surtout sur /wp-admin/admin.php?page=postman (ou une variante).
AJAX : parfois pendant le chargement des onglets, si la page Settings appelle admin-ajax.php.
REST API : plus rare, mais certains plugins modernes chargent des données via /wp-json/.

Circonstances typiques :

Juste après une mise à jour de Post SMTP ou de WordPress (ici WordPress 6.9.4).
Après un changement de version PHP (passage en 8.1/8.2/8.3) qui rend des erreurs “silencieuses” plus strictes (TypeError).
Après l’activation d’un plugin de sécurité/cache qui modifie l’admin (minification, blocage REST/AJAX, règles WAF).

À qui ça sert : si vous êtes blogueur débutant, vous allez apprendre à récupérer la vraie trace, isoler le conflit, puis appliquer une correction sûre (sans toucher au cœur de WordPress). À la fin, vous saurez aussi quoi fournir au support (logs propres, étapes, versions).

Résumé rapide

Activez un mode diagnostic propre : WP_DEBUG + log, et récupérez la trace exacte de l’erreur.
Testez la page Settings avec Health Check (mode “dépannage”) pour confirmer un conflit plugin/thème.
Beaucoup de crashs viennent d’options Post SMTP corrompues après mise à jour : réinitialisation ciblée via WP-CLI ou base.
Les erreurs “Class not found” pointent souvent vers un vendor/autoload incomplet : réinstallation du plugin (propre) plutôt qu’un patch à l’aveugle.
Les erreurs “memory exhausted” se règlent côté serveur (limite PHP) + réduction de surcharge admin (cache/minify mal configurés).

Les symptômes

Selon le serveur, vous pouvez voir :

Erreur 500 en ouvrant Post SMTP → Settings.
Écran blanc (WSOD) uniquement sur cette page d’admin.
Message “There has been a critical error on this website” + e-mail WordPress avec un extrait de trace.
Onglets/sections de Post SMTP qui ne chargent pas, avec des erreurs dans la console (AJAX/REST bloqués).
Impossible de sauvegarder les réglages (nonce invalide, permissions, ou fatal error au moment du submit).

Signes qui orientent vers une cause précise :

Le front fonctionne, mais l’admin plante : souvent un hook admin mal utilisé ou un conflit avec un plugin “admin optimizer”.
Ça marche en local mais pas en production : souvent version PHP, mémoire, ou WAF (pare-feu applicatif).
Ça a cassé “juste après update” : options incompatibles, autoloader vendor, cache d’OPcache.

Tableau de diagnostic rapide

Symptôme	Cause probable	Vérification	Solution
Erreur fatale “array_merge()… string given”	Option Post SMTP attendue en tableau mais stockée en chaîne	Regarder la trace + vérifier option en DB	Solution 3 (réinitialiser/convertir l’option)
“Class not found … vendor/autoload.php”	Plugin mal installé / vendor incomplet	Comparer le dossier plugin, re-télécharger depuis wordpress.org	Réinstaller proprement le plugin (et vider OPcache)
Erreur 500 sans détail	Logs désactivés / WAF / cache	Activer WP_DEBUG_LOG + logs serveur	Solution 1 + désactiver cache/admin minify
Page Settings vide, console JS en erreur	Conflit JS (minification) ou REST/AJAX bloqué	Console navigateur + onglet Network	Désactiver minify admin, autoriser /wp-json/
“Allowed memory size exhausted”	Mémoire PHP insuffisante pour l’admin	error_log + Site Health	Augmenter memory_limit (serveur) + limiter plugins lourds

Pourquoi ça arrive

Version débutant : quand vous ouvrez une page de réglages, WordPress charge le plugin, ses fichiers PHP, ses scripts, puis exécute son code pour afficher le formulaire. Si un seul morceau de code tombe sur une donnée inattendue (ex. une option stockée au mauvais format), PHP stoppe tout avec une erreur fatale.

Voici ce qui se passe en coulisses (version plus technique) :

WordPress charge les plugins, puis déclenche des hooks. Un hook est un “point d’accroche” où un plugin peut exécuter du code. Il y a des actions (exécuter) et des filtres (modifier une valeur).
La page Settings passe par admin_menu (ajout du menu) puis par le chargement de l’écran (souvent load-$hook_suffix), puis l’affichage.
Post SMTP lit des options (stockées en base via get_option()). Si le type n’est pas celui attendu (string au lieu d’array), PHP 8.1+ déclenche des TypeError plus strictes.

Causes classées du plus fréquent au plus rare (sur WordPress 6.9.4 / PHP 8.1+) :

Option Post SMTP corrompue ou héritée d’une ancienne version (migration incomplète).
Conflit plugin (cache/minify/admin optimizer/sécurité) qui casse AJAX/REST ou modifie l’ordre de chargement.
Installation incomplète du plugin (dossier vendor manquant, fichiers tronqués après update).
Version PHP non supportée (trop ancienne) ou au contraire comportement plus strict (TypeError) qui révèle un bug latent.
Limite mémoire trop basse sur l’admin, surtout sur gros sites (WooCommerce, builders, etc.).

Compatibilité page builders : Divi 5, Elementor et Avada n’ont généralement rien à voir avec une page Settings de plugin. Mais dans mon expérience, ils contribuent indirectement via des addons “optimisation admin” ou des scripts globaux injectés partout. On testera donc aussi avec un thème standard via Health Check.

Prérequis avant de commencer

Sauvegarde complète (fichiers + base). Ne faites pas ces manipulations directement en production sans filet.
Un accès à :
- FTP/SFTP ou gestionnaire de fichiers
- le fichier wp-config.php
- idéalement WP-CLI (optionnel mais très pratique)
Versions recommandées : WordPress 6.9.4 et PHP 8.1+. (Si vous êtes en PHP 7.4/8.0, commencez par migrer : beaucoup d’outils modernes ne testent plus ces versions.)
Outils utiles :
- Query Monitor (logs PHP, hooks, requêtes)
- Health Check & Troubleshooting (mode dépannage sans impacter les visiteurs)
- La page Santé du site : Site Health (API)

Risque principal : toucher au mauvais fichier (ex. modifier un plugin directement) et perdre vos modifications à la prochaine mise à jour. Pour les snippets, utilisez un mu-plugin (plugin “must-use”) ou un plugin custom.

Solution 1 : isoler le fatal error et obtenir la trace (WP_DEBUG, logs, Query Monitor)

Quand quelqu’un me dit “Post SMTP Settings cause fatal error”, je commence toujours par la même chose : obtenir la trace exacte. Sans ça, vous allez désactiver des plugins au hasard.

Étape 1 — Activez un log PHP propre (sans afficher les erreurs aux visiteurs)

Ouvrez wp-config.php (à la racine WordPress) et ajoutez/ajustez ces constantes. Placez-les avant la ligne “That’s all, stop editing!”

Code AVANT (fréquent chez les débutants : debug absent ou affiché à l’écran) :

<?php
// ... contenu existant ...

define('WP_DEBUG', false);

// ...

Code APRÈS (recommandé pour diagnostiquer en production sans fuite d’infos) :

<?php
// ... contenu existant ...

/**
 * Diagnostic : active les logs sans afficher d’erreurs aux visiteurs.
 * Pensez à désactiver après dépannage.
 */
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

// Évite que PHP affiche des erreurs malgré WP_DEBUG_DISPLAY à false.
@ini_set('display_errors', '0');

// ...

Pourquoi ça aide : WordPress écrira les erreurs dans wp-content/debug.log. C’est le fichier que vous allez lire après avoir reproduit le crash.

Référence officielle : Debug WordPress (developer.wordpress.org)

Étape 2 — Reproduisez l’erreur et récupérez la trace

Ouvrez l’admin, cliquez Post SMTP → Settings (ou l’entrée équivalente).
Si écran blanc : rechargez une fois (parfois le log s’écrit au second hit).
Ouvrez wp-content/debug.log et copiez :
- la ligne “Fatal error …”
- les 10–30 lignes de stack trace

Si debug.log ne se remplit pas :

Votre hébergeur peut désactiver l’écriture. Vérifiez les permissions de wp-content.
Regardez les logs serveur (Apache/Nginx) via le panel.
Si vous utilisez un cache serveur agressif, videz-le.

Étape 3 — Confirmez un conflit sans casser le site public (Health Check)

Installez/activez Health Check, puis :

Outils → Santé du site → onglet Dépannage
Activez le mode dépannage (vos visiteurs ne sont pas impactés).
Testez Post SMTP → Settings.
Si ça marche en mode dépannage : réactivez les plugins un par un dans ce mode jusqu’à reproduire l’erreur.

Dans mon expérience, les conflits les plus fréquents sont :

plugins de minification qui touchent à l’admin
plugins de sécurité qui bloquent admin-ajax.php ou /wp-json/
plugins de snippets qui chargent un code cassé sur admin_init

Étape 4 — Vérifiez la console navigateur (si la page charge “à moitié”)

Si vous voyez l’interface Post SMTP mais avec des onglets vides :

Ouvrez DevTools → Console : cherchez des erreurs JS
Ouvrez DevTools → Network : filtrez admin-ajax.php et /wp-json/

Si vous voyez des 403/401 sur REST, c’est souvent un plugin de sécurité ou des règles serveur. La doc REST API : REST API Handbook

Solution 2 : réparer une page Settings qui casse à cause d’un hook admin mal chargé

Ce cas arrive quand l’erreur fatale ne vient pas “directement” de Post SMTP, mais d’un snippet ou d’un plugin qui s’exécute sur toutes les pages admin… et qui tombe en panne uniquement sur la page Post SMTP (parce qu’une variable attendue n’existe pas sur cet écran).

Typique : un code “personnalisation admin” qui suppose que $_GET['page'] est toujours défini, ou qui appelle une fonction trop tôt.

Diagnostic rapide

Dans le debug.log, la trace pointe vers functions.php (thème), un plugin de snippets, ou un plugin “admin customization”.
En mode Health Check (dépannage), si vous repassez sur Twenty Twenty-Five (ou un thème standard) et que ça marche, votre thème ou un addon admin est en cause.

Exemple réel : un hook admin_init trop agressif (AVANT → APRÈS)

Terme : action = un hook qui exécute une fonction. Ici admin_init s’exécute à chaque chargement admin.

Où se trouve ce code : souvent dans functions.php du thème (parfois thème enfant), ou dans un plugin de snippets. Ne modifiez pas le thème parent. Travaillez dans un thème enfant ou mieux : un mu-plugin.

Code AVANT (cassé : suppose que $_GET['page'] existe et manipule des options sans vérifier) :

<?php
add_action('admin_init', function () {
	// Mauvaise pratique : $_GET peut être absent, et la page peut ne pas correspondre.
	if ($_GET['page'] === 'postman') {
		// Exemple : on modifie une option sans vérifier son type.
		$settings = get_option('postman_options');
		$settings['force_smtp'] = true; // Fatal si $settings est une chaîne (string).
		update_option('postman_options', $settings);
	}
});

Ce qui casse : si get_option('postman_options') renvoie une string (option corrompue) ou false, l’accès $settings['force_smtp'] provoque une erreur fatale en PHP 8.1+.

Code APRÈS (corrigé : on vérifie le contexte + le type, et on ne touche pas aux options en lecture/écriture à chaque chargement) :

<?php
/**
 * MU-plugin recommandé : /wp-content/mu-plugins/postman-admin-guard.php
 * Sauvegardez avant de modifier.
 */
add_action('admin_init', function () {
	// Ne jamais supposer que $_GET existe.
	$page = isset($_GET['page']) ? sanitize_key(wp_unslash($_GET['page'])) : '';

	// On limite strictement au slug de page visé.
	if ($page !== 'postman') {
		return;
	}

	// On lit l’option et on valide le type.
	$settings = get_option('postman_options');

	if (!is_array($settings)) {
		// On évite le fatal error. À ce stade, on journalise pour diagnostic.
		error_log('[Post SMTP] Option postman_options inattendue (non-array) sur la page Settings.');
		return;
	}

	// Exemple : si vous devez vraiment ajuster un flag, faites-le sur une action explicite
	// (submit de formulaire) plutôt qu’à chaque admin_init.
});

Pourquoi ça corrige : vous empêchez un code tiers de “casser” l’écran Post SMTP en accédant à des données non validées. Et surtout, vous évitez d’écrire en base à chaque chargement admin, ce qui est une autre source de bugs.

Créer le mu-plugin (recommandé)

Créez un dossier wp-content/mu-plugins s’il n’existe pas, puis un fichier postman-admin-guard.php dedans. Les mu-plugins sont chargés automatiquement par WordPress.

Doc officielle : Must-Use Plugins

Solution 3 : nettoyer une option corrompue/incompatible après mise à jour (WP-CLI / base de données)

C’est, de loin, la cause la plus rentable à traiter quand la trace mentionne des erreurs de type :

array_merge(): Argument #2 must be of type array, string given
Cannot access offset of type string on string
foreach() argument must be of type array|object, string given

Le scénario : Post SMTP attend une option sérialisée en tableau (array), mais en base vous avez une chaîne (string), parfois suite à :

une migration interrompue
un plugin de cache d’objets (Redis/Memcached) qui a servi une valeur obsolète
un snippet qui a fait un update_option() avec une mauvaise structure

Étape 1 — Identifiez l’option en cause

Dans la trace, repérez le nom exact de l’option. Les noms varient selon les versions, mais on voit souvent des choses proches de :

postman_options
post_smtp_settings
postman_plugin_options

Si vous ne le voyez pas, cherchez dans debug.log une ligne avec get_option ou un fichier “Settings/Options”.

Option A — Réinitialiser proprement via WP-CLI (le plus sûr)

Si vous avez WP-CLI :

1) Listez les options candidates :

wp option list --search=postman --fields=option_name,autoload --format=table
wp option list --search=post_smtp --fields=option_name,autoload --format=table

2) Inspectez une option (pour vérifier si c’est une string au lieu d’un array sérialisé) :

wp option get postman_options

3) Sauvegardez l’option avant suppression (très utile si vous devez la restaurer) :

wp option get postman_options --format=json > /tmp/postman_options_backup.json

4) Supprimez l’option corrompue (Post SMTP la recréera avec des valeurs par défaut) :

wp option delete postman_options

Doc WP-CLI (référence) : WP-CLI option command

Pourquoi c’est efficace : vous supprimez la donnée toxique qui déclenche l’erreur. Le plugin repart sur une config propre, et la page Settings s’affiche à nouveau.

Option B — Réinitialiser via phpMyAdmin (si vous n’avez pas WP-CLI)

Sauvegardez la base avant. Ensuite :

Ouvrez la table wp_options (le préfixe peut être différent).
Recherchez l’option (ex. postman_options).
Copiez sa valeur dans un fichier texte (backup).
Supprimez la ligne (ou changez option_value en a:0:{} si vous savez ce que vous faites).

Note : remplacer par a:0:{} (array vide sérialisé) peut éviter certains flux d’installation, mais ce n’est pas universel. La suppression est souvent plus propre.

Option C — Patch temporaire pour “survivre” et accéder à l’admin

Si vous êtes bloqué et que vous devez juste rouvrir l’admin pour désactiver un plugin ou exporter des données, vous pouvez ajouter un guard temporaire via un mu-plugin. Ce n’est pas une “réparation” du plugin, mais un filet de sécurité.

Où coller : /wp-content/mu-plugins/postman-option-safety.php

<?php
/**
 * Filet de sécurité temporaire : corrige une option Post SMTP si elle est manifestement corrompue.
 * À retirer après dépannage.
 */

add_action('plugins_loaded', function () {
	// Changez ce nom d’option selon ce que vous voyez dans vos logs.
	$option_name = 'postman_options';

	$value = get_option($option_name, null);

	// Si l’option est une string non sérialisée, on la remet à zéro.
	// Attention : cela réinitialise potentiellement la configuration SMTP.
	if (is_string($value) && $value !== '' && !is_serialized($value)) {
		error_log('[Post SMTP] Option corrompue détectée (' . $option_name . '), réinitialisation.');
		delete_option($option_name);
	}
});

Pourquoi ça marche : Post SMTP ne tombera plus sur une valeur “impossible” et pourra reconstruire ses defaults. Risque : vous perdez la config SMTP (d’où l’intérêt d’un backup via WP-CLI/DB avant).

Référence sur get_option() : get_option()

Vérifications après correction

Une fois la cause traitée, validez avec une checklist simple :

Ouvrez Post SMTP → Settings : la page doit s’afficher sans erreur.
Ouvrez wp-content/debug.log : plus de “Fatal error”.
Envoyez un mail de test depuis Post SMTP (ou depuis un formulaire de contact).
Vérifiez que l’envoi fonctionne aussi via WP-Cron si vous avez des envois planifiés (newsletters, WooCommerce).
Désactivez ensuite le mode debug (ou laissez WP_DEBUG_LOG actif en environnement de staging uniquement).

Si vous avez un cache (plugin, serveur, CDN), videz :

cache plugin (page cache)
cache serveur (Varnish / Nginx microcache)
OPcache (si votre hébergeur le permet) — très utile après réinstallation plugin

Si ça ne marche toujours pas

Quand la page Settings continue de planter, je déroule une procédure fixe. Elle évite les allers-retours inutiles.

1) Réinstallez Post SMTP proprement (sans perdre la config si possible)

Une installation incomplète (vendor manquant) provoque des “Class not found”. Procédure :

Sauvegardez les options (WP-CLI export JSON si possible).
Désactivez Post SMTP.
Supprimez le dossier /wp-content/plugins/post-smtp/ (uniquement ce plugin).
Réinstallez depuis WordPress.org (Post SMTP) (pas depuis un ZIP douteux).
Réactivez et testez la page Settings.

2) Confirmez la version PHP et les extensions

Dans Outils → Santé du site, vérifiez PHP. Visez 8.1+.
Vérifiez les extensions : openssl, mbstring, curl. Post SMTP en dépend souvent indirectement.

Doc PHP (ex. OpenSSL) : PHP OpenSSL

3) Désactivez temporairement les plugins “admin” et “sécurité”

Dans Health Check (mode dépannage), désactivez :

minify/concat JS/CSS (surtout s’il touche l’admin)
plugins de sécurité qui filtrent REST/AJAX
plugins de snippets (un snippet cassé suffit)

Testez à chaque fois Post SMTP → Settings. Quand ça revient, vous avez votre coupable.

4) Vérifiez les limites mémoire

Si la trace mentionne la mémoire :

Augmentez memory_limit côté PHP (panel hébergeur) plutôt que via WordPress.
Évitez de compter sur define('WP_MEMORY_LIMIT', ...) si votre hébergeur force une limite plus basse.

Référence WordPress (mémoire) : WP_MEMORY_LIMIT

5) Vérifiez les permaliens / rewrite rules (rare ici, mais déjà vu)

Si Post SMTP charge des endpoints internes et que ça 404 :

Réglages → Permaliens → Enregistrer (sans changer)

Ça force WordPress à régénérer les règles de réécriture. Référence : flush_rewrite_rules() (à ne pas appeler sur chaque page).

6) Si vous voyez un crash sur un hook spécifique

Problème fréquent : confusion entre actions et filtres. Un filtre doit retourner une valeur. Une action ne retourne rien.

Exemple AVANT (cassé : utilise add_filter mais ne retourne rien) :

<?php
add_filter('admin_menu', function () {
	// Mauvais : admin_menu est une action, pas un filtre.
	// Et on ne retourne rien : comportement imprévisible.
});

Exemple APRÈS (corrigé) :

<?php
add_action('admin_menu', function () {
	// Correct : admin_menu est une action.
});

Doc hooks : Plugin API: Hooks

Pièges et erreurs courantes

Symptôme / erreur	Cause probable	Solution recommandée
Vous collez le snippet dans le mauvais fichier	Code mis dans le thème parent ou dans un plugin qui se met à jour	Utilisez un mu-plugin ou un plugin custom, jamais le core, jamais le thème parent
Erreur fatale après ajout de code : “unexpected token”	Point-virgule oublié, accolade en trop, balise PHP mal fermée	Revenez en arrière via FTP, corrigez la syntaxe, validez avec un éditeur
Le log reste vide	Permissions, WP_DEBUG mal placé, hébergeur qui bloque l’écriture	Vérifiez l’emplacement dans `wp-config.php` + logs serveur
Ça marche en mode dépannage Health Check, mais pas “normalement”	Conflit plugin ou thème	Réactivez un par un dans le mode dépannage jusqu’au coupable
La page Settings charge, mais les onglets restent vides	REST/AJAX bloqué, minification admin	Console + Network, désactivez minify admin, autorisez `/wp-json/`
Erreur “Allowed memory size exhausted”	Limite mémoire PHP trop basse	Augmentez `memory_limit` côté serveur, puis retestez
Vous testez en production sans sauvegarde	Précipitation	Clone staging, ou au minimum backup DB avant suppression d’options
Vous utilisez un vieux tutoriel (PHP 7) sur WordPress 6.9.4	Code non compatible PHP 8.1+ (TypeError, fonctions obsolètes)	Adaptez avec validation de type, `sanitize_*`, et hooks corrects

Variante / alternative

Méthode sans code : remplacer Post SMTP temporairement

Si vous devez absolument rétablir l’envoi d’e-mails pendant que vous diagnostiquez :

Installez un autre plugin SMTP réputé, configurez-le, testez l’envoi.
Laissez Post SMTP désactivé le temps de corriger.

Attention : deux plugins SMTP activés simultanément peuvent se battre pour le hook wp_mail et produire des comportements incohérents (double envoi, headers cassés).

Méthode plus avancée : tracer wp_mail et les hooks sans toucher au plugin

Pour les développeurs (ou si vous travaillez avec un prestataire), vous pouvez instrumenter l’envoi de mail côté WordPress via un mu-plugin. L’objectif : vérifier si Post SMTP modifie bien wp_mail et si l’erreur vient d’un écran admin ou du pipeline mail.

Où coller : /wp-content/mu-plugins/mail-trace.php

<?php
/**
 * Trace légère de wp_mail (ne loggez jamais des contenus sensibles en production).
 * À utiliser temporairement.
 */

add_filter('wp_mail', function ($args) {
	// $args contient to/subject/message/headers/attachments.
	// Risque sécurité : ne loggez pas le message complet si vous envoyez des données privées.
	$to = is_array($args['to']) ? implode(',', $args['to']) : (string) $args['to'];

	error_log('[MailTrace] wp_mail appelé vers: ' . $to . ' | sujet: ' . (string) $args['subject']);

	return $args; // Filtre = on doit retourner la valeur
}, 10, 1);

Référence officielle : Filtre wp_mail

Éviter ce problème à l’avenir

Faites les mises à jour sur une copie staging quand vous le pouvez. Les pages Settings sont souvent le premier endroit où un bug de migration se voit.
Gardez PHP à jour (8.1+ minimum recommandé). Beaucoup d’erreurs “bizarres” viennent d’un PHP trop ancien, ou d’un mix extensions manquantes.
Évitez les snippets “globaux” sur admin_init sans garde-fous. Validez toujours :
- le contexte (page/écran)
- les permissions (current_user_can())
- le type des options (is_array(), is_string())
N’appliquez pas de minification à l’admin sauf si vous savez exactement ce que vous faites. J’ai souvent vu des pages de réglages casser à cause d’un JS concaténé.
Surveillez les logs : gardez une rotation et un accès simple. Une erreur fatale est presque toujours précédée d’avertissements utiles.

Snippet “garde-fou” pour les pages admin (modèle réutilisable)

Ce modèle vous évite d’exécuter du code sur toutes les pages admin. Il réduit fortement les risques de conflits.

Où coller : mu-plugin ou plugin custom.

<?php
/**
 * Modèle : exécuter du code uniquement sur un écran admin précis.
 */

add_action('current_screen', function ($screen) {
	if (!($screen instanceof WP_Screen)) {
		return;
	}

	// Exemple : adaptez selon l’ID réel de l’écran (à lire via Query Monitor).
	if ($screen->id !== 'toplevel_page_postman') {
		return;
	}

	// Ici, votre code spécifique à la page Post SMTP.
	// Toujours valider les types et permissions.
	if (!current_user_can('manage_options')) {
		return;
	}
});

Référence : Hook current_screen

Ressources

Questions fréquentes

Est-ce que je dois désactiver Post SMTP tout de suite ?

Si le site public fonctionne et que seule la page Settings plante, vous pouvez d’abord activer les logs et utiliser Health Check pour isoler. Si l’admin devient instable (erreur globale), désactivez le plugin via FTP en renommant le dossier post-smtp.

J’ai “There has been a critical error…”, mais aucun détail

Activez WP_DEBUG_LOG (Solution 1) et consultez aussi les logs serveur. Sur certains hébergements, WordPress n’a pas le droit d’écrire dans wp-content tant que les permissions ne sont pas correctes.

Supprimer une option va-t-il casser mes e-mails ?

Oui, potentiellement : vous réinitialisez la configuration. Sauvegardez l’option avant (WP-CLI export JSON ou copie DB), puis reconfigurez SMTP dans l’interface une fois l’erreur corrigée.

Divi 5 / Elementor / Avada peuvent-ils provoquer ce fatal error ?

Pas directement. Mais leurs écosystèmes ajoutent souvent des plugins d’optimisation, de sécurité ou des addons admin. Le test Health Check avec un thème standard permet de trancher rapidement.

Je suis en PHP 8.0 et j’ai peur de passer en 8.1+

Sur WordPress 6.9.4 en 2026, PHP 8.1+ est la base recommandée. Beaucoup de plugins corrigent des bugs uniquement sur ces versions. Faites la bascule sur staging et vérifiez vos plugins critiques.

Pourquoi l’erreur n’apparaît que sur la page Settings ?

Parce que le code qui lit/écrit certaines options, charge certains fichiers, ou initialise une UI spécifique ne s’exécute que sur cet écran. Le reste du site peut continuer à tourner.

J’ai une erreur “Class not found” dans vendor/autoload.php

C’est souvent une mise à jour incomplète (ZIP tronqué, permissions, antivirus serveur). La solution la plus rapide est une réinstallation propre du plugin depuis wordpress.org, puis purge cache/OPcache si possible.

Dois-je modifier les fichiers du plugin pour corriger ?

Évitez. Toute modification sera écrasée à la prochaine mise à jour. Préférez : réinstallation, nettoyage des options, ou mu-plugin de garde-fou temporaire le temps d’identifier la cause.

Je ne peux plus accéder à l’admin du tout, comment faire ?

Renommez temporairement le dossier du plugin via FTP (post-smtp → post-smtp.off) pour forcer sa désactivation. Ensuite, réactivez WP_DEBUG_LOG et reprenez le diagnostic.

Quel est le “minimum” à envoyer au support Post SMTP ?

La trace complète (sans données sensibles), vos versions (WordPress 6.9.4, PHP, Post SMTP), la liste des plugins actifs, et le résultat du test Health Check (est-ce que ça casse avec tous les autres plugins désactivés).