Corriger l’erreur fatale Frontend Admin 3.28.31

by | WordPress

Si vous avez déjà vu une page blanche ou une erreur 500 juste après avoir mis à jour Frontend Admin vers 3.28.31, vous n’êtes pas seul. Sur des sites WordPress 6.9.4 en PHP 8.1+, ce genre de “fatal error” arrive souvent pour trois raisons : une incompatibilité PHP (signature de fonction), un conflit REST/AJAX (cache, WAF, nonces), ou un chargement trop tôt/trop tard d’un hook.

Le problème

Le scénario typique : vous mettez à jour le plugin Frontend Admin en version 3.28.31, puis votre site casse immédiatement (front-end, admin, ou une page spécifique contenant un formulaire Frontend Admin).

Exemples d’erreurs réellement observées dans les logs PHP / l’écran :

Fatal error: Uncaught TypeError: array_merge(): Argument #2 must be of type array, null given 
in /wp-content/plugins/frontend-admin/includes/.../something.php:123
Stack trace:
#0 /wp-content/plugins/frontend-admin/includes/.../something.php(123): array_merge(Array, NULL)
#1 /wp-includes/class-wp-hook.php(324): fea_something()
#2 /wp-includes/class-wp-hook.php(348): WP_Hook->apply_filters(NULL, Array)
#3 /wp-includes/plugin.php(517): WP_Hook->do_action(Array)
#4 /wp-settings.php(###): do_action('init')
... (truncated)
Fatal error: Uncaught ArgumentCountError: Too few arguments to function FEASomething::register(), 
0 passed in /wp-includes/class-wp-hook.php on line 324 and exactly 1 expected 
in /wp-content/plugins/frontend-admin/includes/.../Something.php:45
Fatal error: Uncaught Error: Call to undefined function wp_get_current_user() 
in /wp-content/plugins/frontend-admin/includes/.../auth.php:18

Où ça apparaît :

  • Front-end : page contenant un shortcode / bloc Frontend Admin (formulaire, édition de post, profil).
  • Admin : parfois dès le chargement de wp-admin (si le plugin ajoute des hooks globaux).
  • AJAX / REST API : formulaires qui ne soumettent plus, erreurs 401/403/500 dans la console.

À qui s’adresse ce guide : blogueurs débutants, mais aussi personnes qui gèrent un site avec Divi 5, Elementor ou Avada et qui veulent retrouver un site fonctionnel sans “bidouiller au hasard”. À la fin, vous saurez lire l’erreur, isoler la cause (PHP vs REST vs conflit), et appliquer une correction propre (ou un contournement safe).

Résumé rapide

  • Commencez par récupérer le message exact (logs, WP_DEBUG) : sans lui, vous perdez du temps.
  • Si c’est un TypeError/ArgumentCountError en PHP 8.1+, c’est souvent un null passé à une fonction qui attend un tableau, ou une signature de callback devenue stricte.
  • Si le front-end casse mais pas l’admin, vérifiez REST/AJAX (console navigateur, blocage WAF, cache).
  • Désactivez Frontend Admin via FTP si vous n’avez plus accès à wp-admin, puis réactivez en staging.
  • Évitez de modifier le plugin : utilisez un mu-plugin (correctif temporaire), ou revenez à une version stable le temps d’un patch officiel.

Les symptômes

Voici ce que vous pouvez voir, du plus courant au plus trompeur :

  • Erreur 500 sur une page de formulaire front-end (souvent un fatal PHP).
  • Écran blanc (WSOD) sans message (fatal PHP masqué).
  • wp-admin inaccessible après activation/mise à jour (hook global cassé).
  • Formulaire qui “tourne” puis rien : requête AJAX bloquée (403/401/500).
  • Erreurs console : “REST API request failed”, 403 Forbidden, CORS, nonce invalid.
  • Shortcode non rendu : contenu brut affiché, ou bloc qui ne charge pas.
  • Ça marche en local mais pas en production : différences PHP, cache serveur, WAF (Cloudflare/Wordfence), permissions.
  • Conflit avec un builder : Divi 5 / Elementor / Avada ajoutent parfois des optimisations JS/CSS ou des caches qui cassent les endpoints AJAX.

Tableau de diagnostic rapide

Symptôme Cause probable Vérification Solution
Erreur 500/WSOD après update Fatal PHP (TypeError, ArgumentCountError) Logs PHP, WP_DEBUG, Mode récupération Solution 1 / Solution 3
Formulaire ne soumet plus REST/AJAX bloqué (cache, WAF, nonce) Console navigateur + onglet Network Solution 2
Admin inaccessible Hook exécuté trop tôt / fonction WP non chargée Erreur “undefined function wp_get_current_user()” Solution 1 (hook) ou Solution 3 (rollback)
Ça marche en navigation privée Cache navigateur / plugin cache Test incognito + purge cache Solution 2 (purge + exclusions)
Erreur uniquement sur une page builder Minification/concat JS, defer, optimisation Désactiver optimisation JS/CSS Solution 2 (exclusions)

Pourquoi ça arrive

Version débutant : une mise à jour peut changer une partie du code. Si votre site (ou un autre plugin) envoie une donnée “vide” (null) là où le plugin attend un tableau, PHP 8.1+ refuse et stoppe tout. Même chose si une fonction est appelée avec le mauvais nombre d’arguments.

Voici ce qui se passe en coulisses : WordPress déclenche des hooks. Un hook est un point d’accroche où du code peut s’exécuter. Il existe deux types :

  • Actions : “faites quelque chose maintenant” (ex : init, wp_enqueue_scripts).
  • Filtres : “modifiez cette valeur et renvoyez-la” (ex : the_content).

Frontend Admin s’accroche à plusieurs hooks (front-end et admin), et s’appuie beaucoup sur REST/AJAX. Trois causes reviennent le plus souvent après une mise à jour :

  • (Très fréquent) Incompatibilité PHP 8.1+ : types plus stricts, null qui casse un array_merge(), callback appelé avec des arguments inattendus.
  • (Fréquent) Conflit avec cache/minification/WAF : endpoints REST bloqués, nonces invalidés, requêtes mises en cache par erreur.
  • (Plus rare) Code custom/snippet qui “patchait” une ancienne version du plugin, devenu incompatible après update (hook inadapté, priorité, fonction appelée trop tôt).

Note de contexte : nous sommes en avril 2026, WordPress 6.9.4 et PHP 8.1+ sont la base recommandée. Beaucoup de tutos 2021–2023 proposent des snippets qui “fonctionnaient” en PHP 7.4 mais deviennent fatals en PHP 8.1 à cause des changements de typage et d’erreurs plus strictes. Référence : PHP 8.1 migration.

Prérequis avant de commencer

Sauvegardez avant de modifier quoi que ce soit. Idéalement, faites vos tests sur un site de staging (copie de votre site). Ne modifiez jamais le cœur de WordPress.

Ce qu’il vous faut

  • Accès FTP/SFTP ou gestionnaire de fichiers (cPanel, Plesk) pour renommer un plugin si wp-admin est cassé.
  • Accès aux logs PHP (souvent via l’hébergeur) ou à défaut WP_DEBUG.
  • WordPress 6.9.4, PHP 8.1+ (recommandé), mémoire PHP suffisante (au moins 256M sur un site avec builders).

Outils utiles (gratuits)

Activer WP_DEBUG (temporairement)

Dans wp-config.php (à la racine), ajoutez/ajustez :

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false ); // Évite d'afficher les erreurs aux visiteurs

Vous retrouverez les erreurs dans /wp-content/debug.log. Désactivez ensuite WP_DEBUG.

Solution 1 : Corriger une incompatibilité PHP 8.1+ (erreurs fatales TypeError/ArgumentCountError)

Cette solution cible les fatals du type array_merge(): Argument #2 must be of type array, null given, ou Too few arguments, ou encore “undefined function” parce qu’un code s’exécute trop tôt.

Objectif : remettre le site debout, puis appliquer un contournement propre sans modifier le plugin (sinon la mise à jour suivante écrasera votre patch).

Étape 1 — récupérer le fichier et la ligne exacte

Dans le message d’erreur, notez :

  • Le fichier dans /wp-content/plugins/frontend-admin/...
  • La ligne
  • La fonction en cause (ex : array_merge, count, foreach, une méthode de classe)

Cas A — array_merge() reçoit null (fatal PHP 8.1+)

J’ai souvent vu ce cas quand un plugin lit des options WordPress (via get_option()) et suppose que c’est toujours un tableau. Or get_option() peut renvoyer false si l’option n’existe pas, et votre code custom peut renvoyer null via un filtre.

Code AVANT (cassé) — exemple typique

Vous ne verrez pas forcément exactement ce code, mais le pattern est celui-ci :

<?php
// Exemple typique : fusionner des réglages par défaut avec des réglages stockés.
// Problème : $saved peut être null/false et array_merge() plante en PHP 8.1+.

$defaults = array(
	'enable' => true,
	'roles'  => array( 'administrator' ),
);

$saved = get_option( 'fea_settings' ); // Peut être false si absent, ou null via un filtre
$settings = array_merge( $defaults, $saved ); // Fatal si $saved n'est pas un tableau

Code APRÈS (corrigé) — normaliser en tableau

Où coller le correctif : dans un mu-plugin (recommandé), pas dans le plugin Frontend Admin. Un mu-plugin est un plugin “must-use” chargé automatiquement. Créez le fichier :

/wp-content/mu-plugins/fea-compat-php81.php

<?php
/**
 * Plugin Name: FEA - Compat PHP 8.1+ (patch temporaire)
 * Description: Contournements pour éviter des fatals après update Frontend Admin (ex: options null).
 * Author: Votre nom
 * Version: 0.1.0
 *
 * ⚠️ Patch temporaire : à retirer quand le plugin est corrigé officiellement.
 */

defined( 'ABSPATH' ) || exit;

/**
 * Normalise certaines options en tableau pour éviter des TypeError (array_merge, foreach, count).
 *
 * Ici on intercepte get_option via le filtre "option_{$option}".
 * Doc : https://developer.wordpress.org/reference/hooks/option_option/
 */
add_filter( 'option_fea_settings', function( $value ) {
	// Si l'option est absente ou corrompue, force un tableau vide.
	if ( ! is_array( $value ) ) {
		return array();
	}
	return $value;
}, 10, 1 );

Pourquoi ça marche : le filtre option_fea_settings s’exécute quand WordPress récupère l’option fea_settings. On garantit que Frontend Admin reçoit un tableau, donc array_merge() et foreach ne crashent plus.

Explication rapide, ligne par ligne :

  • mu-plugins : chargé avant les plugins classiques, donc utile quand wp-admin est cassé.
  • add_filter() : un filtre doit retourner une valeur.
  • is_array() : on corrige seulement si la valeur n’est pas un tableau.

Attention sécurité : ce patch “masque” une donnée corrompue. Il remet le site en route, mais vous devez ensuite comprendre pourquoi l’option est devenue null (conflit, import, snippet). Gardez ce point pour la section “Si ça ne marche toujours pas”.

Cas B — “Too few arguments” sur un callback hook

Ce fatal arrive quand WordPress appelle votre fonction (ou celle d’un plugin) avec un nombre d’arguments différent de celui attendu. La cause la plus fréquente côté site : un snippet qui remplace un callback via remove_action() / add_action(), mais avec une signature non compatible.

Code AVANT (cassé) — snippet typique

Où on le trouve souvent : functions.php du thème (ou thème enfant), ou un plugin de snippets.

<?php
// Exemple : vous essayez de remplacer un hook du plugin par votre fonction.
// Problème : votre fonction n'accepte pas les arguments que WordPress lui passe.

add_action( 'init', 'mon_fea_override' );

function mon_fea_override() {
	// ...
}

// Plus tard, un hook attendait 1 argument, mais votre callback n'en prend aucun.
// Résultat : ArgumentCountError sur certaines versions / contextes.

Code APRÈS (corrigé) — accepter des arguments optionnels

Où coller : dans le thème enfant (functions.php) ou, mieux, dans un plugin custom. Si vous débutez, restez sur le thème enfant mais sauvegardez avant.

<?php
add_action( 'init', 'mon_fea_override', 10, 1 );

/**
 * Callback compatible : accepte 1 argument (optionnel).
 * Même si WordPress ne passe rien, PHP ne plantera pas.
 */
function mon_fea_override( $arg = null ) {
	// Votre code ici, en tenant compte que $arg peut être null.
}

Pourquoi ça marche : le 4e paramètre de add_action() indique combien d’arguments WordPress est autorisé à passer. Et votre fonction accepte un argument optionnel, donc pas de fatal si le hook change légèrement.

Référence hook API : developer.wordpress.org (Hooks).

Cas C — “Call to undefined function wp_get_current_user()” (exécution trop tôt)

Quand un code appelle une fonction WordPress avant que WordPress ait fini de charger, PHP dit “fonction inconnue”. Ça arrive si un fichier est inclus trop tôt (ex : au chargement du plugin, hors hook), ou si un snippet est placé au mauvais endroit.

Code AVANT (cassé)

<?php
// Mauvaise pratique : exécuter du code WordPress directement au chargement du fichier.
$user = wp_get_current_user(); // Peut planter si appelé trop tôt

Code APRÈS (corrigé) — exécuter au bon hook

Où coller : plugin custom ou thème enfant.

<?php
add_action( 'wp_loaded', function() {
	// wp_loaded : WordPress est chargé, l'utilisateur est initialisé.
	$user = wp_get_current_user();

	// Exemple : log minimal (évitez en production si vous n'en avez pas besoin)
	if ( defined( 'WP_DEBUG' ) && WP_DEBUG ) {
		error_log( 'Utilisateur courant: ' . ( $user->exists() ? $user->user_login : 'anonyme' ) );
	}
} );

Doc utile : developer.wordpress.org (wp_loaded).

Solution 2 : Résoudre un conflit REST/AJAX (cache, sécurité, nonces, WAF)

Quand le site ne plante pas “en fatal”, mais que Frontend Admin ne fonctionne plus (soumission, upload, édition), le problème est souvent côté requêtes REST/AJAX.

Sur des sites avec Divi 5, Elementor ou Avada, j’ai vu deux accélérateurs de problèmes :

  • Optimisation JS agressive (minification, defer, delay JS).
  • Cache page qui met en cache des réponses qui ne devraient jamais l’être.

Étape 1 — vérifier la console et l’onglet Network

Dans Chrome/Firefox :

  1. Ouvrez la page du formulaire.
  2. F12 → onglet Console et Network.
  3. Soumettez le formulaire.
  4. Repérez les requêtes vers /wp-json/ (REST) ou admin-ajax.php.

Erreurs typiques :

  • 401/403 : nonce invalide, WAF, droits insuffisants.
  • 404 sur /wp-json/ : rewrite rules cassées, permaliens à régénérer.
  • 500 : fatal PHP dans un endpoint (retournez à Solution 1).

Étape 2 — exclure REST/AJAX du cache

Règle générale : ne mettez jamais en cache :

  • /wp-json/
  • /wp-admin/admin-ajax.php
  • les pages contenant des formulaires d’édition front-end (si le plugin le recommande)

Chaque plugin de cache a sa UI. Si vous utilisez un cache serveur (LiteSpeed, Nginx FastCGI, Varnish), configurez l’exclusion côté serveur aussi.

Étape 3 — corriger un nonce “cassé” par optimisation JS

Un nonce est un jeton de sécurité WordPress (anti-CSRF) utilisé dans les formulaires et requêtes AJAX/REST. Si un cache sert une version “ancienne” d’une page, le nonce peut expirer et provoquer un 403.

Vous pouvez diagnostiquer en désactivant temporairement :

  • Minification/concat JS
  • “Delay JS” / “Defer all JS”
  • Optimisation CSS qui modifie l’ordre des scripts

Divi 5 : testez en désactivant les options de performance liées aux scripts dans Divi → Performance (selon votre configuration).
Elementor : testez en désactivant l’optimisation de chargement (et tout plugin tiers type “Speed Booster”).
Avada : idem via Avada → Performance, et Fusion Builder si vous avez des optimisations.

Étape 4 — forcer la désactivation du cache sur les pages FEA (solution code)

Si votre plugin de cache est difficile à configurer, vous pouvez envoyer des en-têtes “no-cache” sur des pages spécifiques. C’est un contournement utile quand Frontend Admin est sur une URL fixe (ex : /edit-post/).

Où coller : dans un plugin custom ou un mu-plugin. Sauvegardez avant.

<?php
/**
 * Désactive le cache HTTP sur certaines pages contenant Frontend Admin.
 * ⚠️ Ne remplace pas une config correcte de votre cache serveur, mais aide à stabiliser.
 */
add_action( 'send_headers', function() {
	if ( is_admin() ) {
		return;
	}

	// Ajustez ces conditions à votre site.
	// Exemple simple : une page par son slug.
	if ( is_page( array( 'edit-post', 'frontend-admin' ) ) ) {
		nocache_headers();
	}
} );

Pourquoi ça marche : nocache_headers() envoie des en-têtes HTTP qui demandent aux caches intermédiaires de ne pas stocker la réponse. Doc : developer.wordpress.org (nocache_headers).

Étape 5 — régénérer les permaliens (REST 404)

Si /wp-json/ renvoie 404, allez dans Réglages → Permaliens → cliquez Enregistrer (sans rien changer). Ça régénère les règles de réécriture.

Si vous avez WP-CLI, c’est plus propre :

wp rewrite flush --hard

Doc WP-CLI : developer.wordpress.org (wp rewrite flush).

Solution 3 : Revenir en arrière proprement et isoler la cause (WP-CLI, mode récupération, staging)

Si vous êtes bloqué (site down) et que vous n’avez pas encore identifié l’erreur, le rollback contrôlé est souvent la voie la plus rapide. Le but n’est pas de rester en ancienne version, mais de rétablir le site puis de tester la mise à jour en staging.

Option A — désactiver Frontend Admin sans wp-admin (FTP/SFTP)

Renommez le dossier :

/wp-content/plugins/frontend-admin/ → /wp-content/plugins/frontend-admin.disabled/

WordPress désactivera automatiquement le plugin. Vous récupérez l’accès au site/admin.

Option B — revenir à la version précédente via WP-CLI

Prérequis : WP-CLI installé sur votre serveur.

# Voir la version installée
wp plugin get frontend-admin --field=version

# Installer une version précise (exemple : 3.28.30) puis activer
wp plugin install frontend-admin --version=3.28.30 --force
wp plugin activate frontend-admin

Attention sécurité : rester sur une version plus ancienne peut vous exposer si une faille est corrigée dans 3.28.31. Utilisez ce rollback comme étape temporaire, le temps d’un correctif officiel ou d’un patch validé.

Option C — Mode récupération WordPress

WordPress a un mécanisme de “recovery mode” qui vous envoie un lien par e-mail quand un fatal est détecté, pour vous permettre de désactiver le plugin fautif. Si vous avez reçu cet e-mail, utilisez-le.

Référence : developer.wordpress.org (Fatal Error Recovery Mode).

Isoler la cause (méthode que j’utilise en intervention)

  1. Rétablir le site (désactivation ou rollback).
  2. Cloner en staging.
  3. Activer WP_DEBUG_LOG en staging.
  4. Mettre à jour Frontend Admin en staging.
  5. Reproduire l’action (charger la page, soumettre le formulaire).
  6. Lire debug.log + console navigateur.

Vérifications après correction

Une fois la solution appliquée :

  • Rechargez la page du formulaire en navigation privée (pour éviter le cache).
  • Testez une soumission simple (sans upload), puis une soumission avec upload si le plugin le permet.
  • Vérifiez /wp-content/debug.log : il ne doit plus y avoir de fatals au moment du test.
  • Ouvrez la console : pas d’erreurs 401/403/500 sur /wp-json/ ou admin-ajax.php.
  • Si vous avez un cache : purge complète (plugin + cache serveur + CDN).

Test REST API rapide

Dans votre navigateur, essayez :

https://votre-site.tld/wp-json/

Vous devez obtenir une réponse JSON (pas un 404).

Si ça ne marche toujours pas

Quand le problème persiste, suivez cet ordre. Il évite de partir dans tous les sens.

1) Confirmez la version PHP et la mémoire

  • PHP : 8.1 minimum recommandé (idéalement 8.2/8.3 si votre stack le supporte).
  • Mémoire PHP : 256M est un minimum réaliste avec Elementor/Divi/Avada + plugins lourds.

2) Cherchez le vrai fatal dans les logs serveur

debug.log est utile, mais les logs serveur (error_log) sont souvent plus complets, surtout si le fatal survient avant le chargement complet de WordPress.

3) Testez sans conflit (Health Check)

Avec Health Check :

  • Activez le mode dépannage.
  • Désactivez tous les plugins sauf Frontend Admin.
  • Passez temporairement sur un thème par défaut (si possible) pour confirmer si le thème/builder intervient.

4) Vérifiez le cache à trois niveaux

  • Navigateur : test incognito.
  • Plugin cache : purge, exclusions.
  • CDN/WAF (Cloudflare, etc.) : purge, règles pour ne pas mettre en cache /wp-json/.

5) Vérifiez les nonces et permissions

Si vous voyez “nonce invalid” ou 403 :

  • Assurez-vous que l’utilisateur a le bon rôle/capacité.
  • Vérifiez que vous n’avez pas un plugin de sécurité qui bloque l’endpoint.
  • Testez en désactivant temporairement Wordfence/équivalent pour confirmer.

6) Vérifiez un snippet cassé (très courant)

J’ai souvent vu le site “tomber” après une mise à jour, alors que la vraie cause était un snippet collé dans functions.php des mois avant. La mise à jour change l’ordre d’exécution, et le snippet devient fatal (fonction appelée trop tôt, mauvais hook, priorité).

Si vous utilisez un plugin de snippets, désactivez-le temporairement. Si vous avez modifié functions.php, renommez temporairement le thème enfant (en staging si possible) pour isoler.

Pièges et erreurs courantes

Symptôme / erreur Cause probable Solution recommandée
Écran blanc après avoir collé un code Parenthèse/point-virgule manquant dans functions.php Revenir via FTP, corriger la syntaxe, tester en staging
array_merge(): ... null given Option WP renvoie false/null Mu-plugin qui normalise l’option (Solution 1)
Too few arguments... Callback hook incompatible, mauvais accepted_args Ajuster add_action(..., ..., ..., 1) et signature (Solution 1)
Formulaire ne soumet plus, 403 Nonce expiré/caché, WAF Exclure pages et /wp-json/ du cache + désactiver optimisations JS (Solution 2)
/wp-json/ en 404 Rewrite rules cassées Enregistrer les permaliens ou wp rewrite flush --hard (Solution 2)
Ça marche en privé mais pas normal Cache navigateur / service worker Purge cache + désactiver cache agressif sur page FEA
Code collé dans le mauvais fichier Snippet mis dans un fichier du plugin (écrasé à la MAJ) Déplacer dans mu-plugin / plugin custom
Hook inadapté Exécution trop tôt (plugins_loaded vs wp_loaded) Utiliser un hook plus tardif (Solution 1, Cas C)

Variante / alternative

Méthode sans code : rollback + attendre patch + staging

Si vous débutez et que le site est critique :

  • Rollback à la version précédente (Solution 3).
  • Ouvrez un ticket/support auprès de l’éditeur du plugin avec le log complet.
  • Testez la prochaine release en staging avant production.

Méthode plus avancée : créer un plugin “shim” de compat

Quand l’erreur vient d’une donnée corrompue (options, meta), un shim (mu-plugin) qui normalise les valeurs est souvent plus stable qu’un patch direct dans le plugin. Vous avez vu l’exemple avec option_fea_settings. Vous pouvez appliquer la même approche à des metas via get_post_metadata (filtre) si nécessaire, mais faites-le seulement si vous avez identifié précisément la clé.

Doc filtres meta : developer.wordpress.org (get_post_metadata).

Éviter ce problème à l'avenir

  • Staging systématique : mise à jour plugin + test de vos formulaires front-end avant production.
  • Évitez les patches dans les plugins : utilisez un plugin custom ou mu-plugin.
  • Gardez un journal de snippets : notez pourquoi vous avez ajouté chaque snippet et à quel plugin il est lié.
  • Surveillez les logs après mise à jour (au moins 24h) : un fatal peut n’apparaître que sur une action précise.
  • Cache/optimisation : excluez par défaut les pages transactionnelles (formulaires, checkout, édition) et /wp-json/.

Petit garde-fou : alerte si Frontend Admin génère des fatals

Où coller : mu-plugin. Ce code n’empêche pas le fatal, mais vous aide à repérer rapidement les erreurs liées au plugin dans debug.log.

<?php
defined( 'ABSPATH' ) || exit;

add_action( 'shutdown', function() {
	if ( ! defined( 'WP_DEBUG_LOG' ) || ! WP_DEBUG_LOG ) {
		return;
	}

	$error = error_get_last();
	if ( empty( $error['file'] ) || empty( $error['message'] ) ) {
		return;
	}

	// On ne loggue que si l'erreur vient du plugin Frontend Admin.
	if ( strpos( $error['file'], '/plugins/frontend-admin/' ) !== false ) {
		error_log( '[FEA] Dernière erreur: ' . $error['message'] . ' dans ' . $error['file'] . ':' . $error['line'] );
	}
} );

Ressources

Questions fréquentes

Est-ce que WordPress 6.9.4 est la cause du fatal ?

Rarement “directement”. WordPress 6.9.4 déclenche des hooks de façon stable, mais une mise à jour de plugin peut révéler un bug latent (types PHP, données null, conflit de cache). Le message d’erreur vous dira si ça vient du plugin.

Je n’ai plus accès à wp-admin, je fais quoi en premier ?

Renommez le dossier du plugin via FTP/SFTP pour le désactiver (Solution 3). Ensuite, réactivez en staging pour diagnostiquer proprement.

Puis-je corriger en modifiant les fichiers du plugin Frontend Admin ?

Techniquement oui, mais ce n’est pas durable : la prochaine mise à jour écrasera vos modifications. Préférez un mu-plugin (Solution 1) ou un rollback temporaire (Solution 3).

Pourquoi ça marche en navigation privée ?

Ça pointe presque toujours vers un cache (navigateur, plugin cache, CDN) ou un nonce expiré. Passez par la Solution 2 : exclusions cache + test sans optimisation JS.

Comment savoir si c’est REST API ou PHP ?

Si vous avez une erreur 500/WSOD, regardez les logs (PHP). Si la page charge mais l’action échoue, regardez la console et Network (REST/AJAX).

Divi 5 / Elementor / Avada peuvent-ils casser Frontend Admin ?

Le builder en lui-même, rarement. Par contre, leurs options de performance (ou des plugins d’optimisation ajoutés “autour”) peuvent retarder/combiner des scripts et casser des nonces ou des endpoints. Désactivez temporairement les optimisations pour confirmer.

J’ai une erreur “nonce invalid” : c’est grave ?

C’est un blocage de sécurité, donc c’est “bon signe” : WordPress refuse une requête suspecte ou expirée. Le problème est généralement un cache qui sert une page trop ancienne, ou un plugin de sécurité/WAF qui bloque.

Dois-je repasser en PHP 8.0 pour éviter le problème ?

Non si vous pouvez éviter. PHP 8.1+ est la base recommandée en 2026. Revenir en arrière masque le bug et peut créer d’autres incompatibilités. Corrigez plutôt la source (Solution 1) ou faites un rollback du plugin (Solution 3) en attendant un patch.

Quel est le meilleur endroit pour coller un correctif ?

Un mu-plugin si le site est instable (chargé automatiquement), sinon un plugin custom. Le thème enfant est acceptable, mais plus fragile si vous changez de thème.

Je ne trouve pas /wp-content/mu-plugins/, c’est normal ?

Oui. Créez le dossier mu-plugins vous-même, puis ajoutez votre fichier PHP dedans. WordPress le chargera automatiquement.

Articles connexes

Submit a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.