Corriger l’erreur wp-admin Articles sur WordPress v3.1.1

Si vous avez déjà vu un écran blanc ou une page admin qui « charge dans le vide » dès que vous cliquez sur Articles (wp-admin/edit.php), vous connaissez la sensation : tout le back-office marche… sauf ce menu.

Le problème

Le libellé exact que je vois le plus souvent dans les tickets et captures d’écran ressemble à une phrase tronquée, typiquement issue d’un log ou d’un message d’erreur coupé par un écran blanc :

v3.1.1 fails to open wp-admin “articles” with a

Dans la pratique, ça correspond presque toujours à un scénario concret :

• Où : dans l’admin WordPress (wp-admin), en cliquant sur Articles ou Tous les articles.
• Quand : juste après une mise à jour (souvent un plugin en v3.1.1), l’activation d’un snippet, ou une migration (PHP/serveur).
• Effet : page blanche, erreur 500, ou écran « Il y a eu une erreur critique » uniquement sur cette page.

Ce guide s’adresse aux blogueurs débutants (et aux admins de site) qui veulent :

• identifier rapidement si le problème vient d’un plugin/thème/snippet, d’un JS admin, ou des droits/permaliens ;
• appliquer une correction propre compatible WordPress 6.9.4 et PHP 8.1+ ;
• éviter que ça se reproduise au prochain update.

---

Résumé rapide

• Si seule la page wp-admin/edit.php (Articles) casse, cherchez d’abord un code qui s’exécute sur admin_init ou init et qui suppose à tort que « on est sur un article ».
• Activez WP_DEBUG et lisez wp-content/debug.log : vous aurez presque toujours la fonction et le fichier responsables.
• Vérifiez la console du navigateur : un JS admin cassé (REST/AJAX/nonce) peut bloquer l’UI et donner l’impression d’un bug PHP.
• Désactivez les plugins sans risque via Health Check (mode dépannage), puis réactivez un par un.
• Après correction, videz les caches (plugin + serveur + navigateur) et retestez avec un compte admin.

---

Les symptômes

Selon la cause, vous pouvez observer un ou plusieurs de ces symptômes :

• Erreur 500 uniquement sur Articles, alors que Pages, Médias et Réglages fonctionnent.
• Écran blanc (white screen of death) quand vous ouvrez /wp-admin/edit.php.
• Message « Il y a eu une erreur critique sur ce site » (et éventuellement un e-mail de WordPress).
• Redirection en boucle quand vous cliquez sur Articles (souvent un wp_redirect() mal placé).
• La liste des articles s’ouvre mais :
• le bouton Ajouter renvoie une erreur ;
• les filtres (Tous / Publiés / Brouillons) ne répondent plus ;
• des colonnes personnalisées font planter l’affichage.
• Dans la console navigateur (F12) :
• Uncaught TypeError dans un fichier JS de plugin ;
• rest_cookie_invalid_nonce ou 401 Unauthorized sur une requête REST ;
• Failed to load resource (JS/CSS admin non chargé).

J’ai souvent croisé ce bug sur des sites qui utilisent un plugin “SEO / redirection / analytics” mis à jour récemment, ou un snippet collé dans le mauvais endroit (ex : dans le thème parent, ou via un plugin de snippets qui s’exécute partout).

---

Pourquoi ça arrive

Explication simple (niveau débutant)

La page Articles de l’admin n’est pas « une page comme les autres ». WordPress charge :

• des classes spécifiques (WP_Posts_List_Table) ;
• des hooks (actions/filtres) propres à l’écran ;
• souvent des requêtes AJAX/REST pour certaines extensions.

Si un plugin (par exemple en v3.1.1) injecte du code qui suppose qu’on est sur un écran différent, ou qui modifie la requête admin sans vérifier le contexte, la page Articles est l’une des premières à casser.

Explication technique (intermédiaire/pro)

Les causes les plus fréquentes, du plus courant au plus rare :

1. Hook admin mal ciblé : un code s’exécute sur toutes les pages admin (via admin_init, current_screen, admin_enqueue_scripts) mais appelle une fonction qui n’existe pas, ou utilise get_post() / the_title() sans post courant. Résultat : fatal error sur edit.php.
2. Colonnes/tri personnalisés : filtre manage_posts_columns, action manage_posts_custom_column, ou tri via pre_get_posts qui casse la requête admin (mauvais meta_query, mauvais type, ou oubli de is_admin() + $query->is_main_query()).
3. JS admin cassé : un plugin enfile un script sur toutes les pages admin, mais oublie une dépendance (ex : wp-api-fetch), ou utilise un nonce REST invalide. L’écran charge partiellement puis se fige.
4. Capacités/rôles : après migration, un rôle a perdu edit_posts, ou un plugin de sécurité bloque edit.php (WAF, règles, ou plugin de restriction).
5. Cache/opcode : OPcache ou cache serveur sert un vieux fichier PHP après mise à jour, particulièrement sur hébergements agressifs.
6. Incompatibilité PHP : le serveur tourne encore en PHP 7.4/8.0 malgré WordPress 6.9.4, ou un plugin utilise des fonctionnalités non compatibles avec votre PHP.

Note sur “v3.1.1” : ce n’est pas une version WordPress. C’est quasiment toujours la version d’un plugin/thème/snippet. Mon approche : on diagnostique comme si c’était un conflit de code, puis on isole le composant en v3.1.1.

---

Prérequis avant de commencer

Sauvegarde et environnement

• Sauvegardez fichiers + base de données avant toute modification. Ne testez pas un snippet “directement en production” sans plan de retour arrière.
• Si possible, reproduisez sur un staging (site de test). Beaucoup d’hébergeurs le proposent en 1 clic.
• Vérifiez vos versions : WordPress 6.9.4 et PHP 8.1+. WordPress affiche ça dans Outils → Santé du site.

Outils utiles (gratuits)

• Health Check & Troubleshooting : mode dépannage sans impacter les visiteurs. Plugin Health Check
• Query Monitor : erreurs PHP, hooks, requêtes, REST, scripts. Plugin Query Monitor
• WP-CLI (si vous avez SSH) : désactiver un plugin qui casse l’admin. WP-CLI Commands

Activer les logs (temporairement)

Dans wp-config.php (à la racine WordPress), ajoutez ou ajustez ces constantes. Sauvegardez avant de modifier.

<?php
// wp-config.php

// Sauvegardez avant de modifier ce fichier.
// Active l'affichage des erreurs côté logs (pas à l'écran)
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

// Optionnel : utile si vous suspectez des warnings qui cassent un JSON/AJAX
@ini_set( 'display_errors', '0' );

Les erreurs iront dans wp-content/debug.log. Documentation officielle : Debugging in WordPress.

---

Solution 1 : corriger un hook admin mal utilisé (le cas le plus fréquent)

Quand Articles plante juste après l’update d’un plugin/snippet, j’ai très souvent retrouvé un code qui s’exécute sur toutes les pages admin, et qui fait une hypothèse fausse du type : “si on est dans l’admin, on a forcément un post courant”. Sur edit.php, ce n’est pas vrai.

Diagnostic rapide

1. Ouvrez wp-content/debug.log.
2. Cherchez un Fatal error au moment où vous chargez /wp-admin/edit.php.
3. Notez : fichier + ligne + nom de la fonction.

Exemples d’erreurs typiques :

PHP Fatal error:  Uncaught Error: Call to undefined method WP_Screen::get()
PHP Fatal error:  Uncaught TypeError: get_post(): Argument #1 ($post) must be of type WP_Post|int|null, string given
PHP Fatal error:  Uncaught Error: Call to undefined function get_current_screen() in ...

Code AVANT (cassé)

Ce snippet ressemble à ce que je vois dans des plugins “maison” ou des snippets copiés/collés. Il veut “faire quelque chose sur l’écran Articles”, mais il s’exécute trop tôt, et/ou appelle get_current_screen() au mauvais moment.

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

<?php
// functions.php (code cassé)

// Mauvaise pratique : admin_init tourne sur toutes les pages admin,
// parfois avant que l'écran soit correctement disponible.
add_action( 'admin_init', function () {
	$screen = get_current_screen(); // Peut être null selon le timing

	// Hypothèse fragile : $screen existe toujours et a certaines propriétés
	if ( $screen->id === 'edit-post' ) {
		// Exemple : chargement de fonctions, redirections, etc.
		do_action( 'mon_plugin_init_articles' );
	}
} );

Pourquoi ça casse :

• get_current_screen() n’est pas garanti à ce moment (selon le flux, plugins, ou erreurs en amont).
• si $screen vaut null, $screen->id déclenche un fatal error.
• même quand ça ne plante pas, edit-post n’est pas toujours l’ID attendu (selon le type de contenu, listes, etc.).

Code APRÈS (corrigé et robuste)

La correction consiste à :

• utiliser le bon hook : current_screen (déclenché quand l’écran admin est prêt) ;
• vérifier que l’objet écran est bien un WP_Screen ;
• cibler précisément l’écran edit.php pour les Articles standards (post type post).

Où coller le code : idéalement dans un mu-plugin (plugin obligatoire) pour stabiliser l’admin, surtout si votre thème change. Créez :

• wp-content/mu-plugins/ (si le dossier n’existe pas, créez-le)
• un fichier fix-admin-articles-screen.php

<?php
/**
 * Plugin Name: Fix Admin Articles Screen
 * Description: Stabilise l'écran "Articles" en corrigeant des hooks admin mal ciblés.
 * Version: 1.0.0
 * Author: Votre Nom
 *
 * Sauvegardez avant de modifier. Ne modifiez jamais le core WordPress.
 */

defined( 'ABSPATH' ) || exit;

/**
 * Action = hook qui exécute du code à un moment précis.
 * Ici, current_screen fournit l'objet écran admin (WP_Screen) une fois prêt.
 */
add_action( 'current_screen', function ( $screen ) {

	// Vérification défensive : évite les fatals si un plugin passe autre chose.
	if ( ! ( $screen instanceof WP_Screen ) ) {
		return;
	}

	// On cible la liste des Articles (post type "post") : /wp-admin/edit.php
	// $screen->base vaut souvent 'edit' pour la liste.
	// $screen->post_type vaut 'post' pour les Articles.
	if ( 'edit' === $screen->base && 'post' === $screen->post_type ) {

		/**
		 * Exemple : si vous aviez besoin de charger un fichier ou d'initialiser
		 * une fonctionnalité UNIQUEMENT sur la liste des Articles, faites-le ici.
		 */
		do_action( 'mon_plugin_init_articles' );
	}
}, 10 );

Pourquoi ça corrige

Vous évitez deux erreurs classiques :

• Timing : current_screen arrive au bon moment, contrairement à admin_init qui est trop générique.
• Contexte : vous n’exécutez pas de logique “Articles” sur d’autres écrans (Médias, Réglages, etc.).

Cas voisin : un pre_get_posts qui casse l’admin

Autre grand classique : modifier la requête principale sans vérifier qu’on est sur la bonne page admin.

AVANT (cassé) :

<?php
// functions.php (cassé)

// Ce code modifie TOUTES les requêtes, y compris l'admin.
add_action( 'pre_get_posts', function ( $query ) {
	$query->set( 'meta_key', 'featured' );
	$query->set( 'orderby', 'meta_value' );
} );

APRÈS (corrigé) :

<?php
// functions.php du thème enfant OU plugin custom (corrigé)

// Sauvegardez avant de modifier.
add_action( 'pre_get_posts', function ( $query ) {

	// Ne touchez pas à l'admin
	if ( is_admin() ) {
		return;
	}

	// Ne touchez qu'à la requête principale du front
	if ( ! $query->is_main_query() ) {
		return;
	}

	// Exemple : uniquement sur la page d'accueil du blog
	if ( $query->is_home() ) {
		$query->set( 'meta_key', 'featured' );
		$query->set( 'orderby', 'meta_value' );
	}
} );

Documentation : pre_get_posts.

---

Solution 2 : réparer un JS admin cassé (REST/AJAX, nonce, dépendances)

Quand la page Articles “s’ouvre” mais que l’interface se fige, ou que certains éléments ne répondent plus, je regarde tout de suite la console navigateur. Un script de plugin peut casser l’exécution JavaScript, et l’admin devient imprévisible.

Symptômes typiques côté navigateur

• Console : Uncaught ReferenceError: wp is not defined
• Console : Uncaught TypeError: apiFetch is not a function
• Réseau : appels vers /wp-json/ en 401 avec rest_cookie_invalid_nonce

Pourquoi ça arrive

Un plugin (v3.1.1 ou autre) enfile un script admin :

• sur toutes les pages admin (au lieu de cibler l’écran) ;
• sans déclarer les dépendances WordPress (wp-api-fetch, wp-i18n, etc.) ;
• avec un nonce REST non injecté, ou injecté mais jamais appliqué.

Code AVANT (cassé)

Exemple réaliste : un plugin charge un JS pour “améliorer” la liste des articles, mais oublie les dépendances et le nonce.

<?php
// plugin ou functions.php (cassé)

add_action( 'admin_enqueue_scripts', function () {
	// Chargé partout, pas de dépendances, pas de nonce
	wp_enqueue_script(
		'mon-admin-js',
		plugin_dir_url( __FILE__ ) . 'admin.js',
		array(),
		'3.1.1',
		true
	);
} );

// admin.js (cassé)
// Suppose que wp.apiFetch existe, mais la dépendance n'est pas chargée.
wp.apiFetch( { path: '/wp/v2/posts?per_page=1' } ).then( console.log );

Code APRÈS (corrigé, ciblé sur l’écran Articles)

Où appliquer : dans le plugin concerné si vous le maintenez. Si c’est un plugin tiers, créez un mini-plugin “correctif” qui désactive l’enqueue du plugin (si possible via un hook), ou contactez l’éditeur. Ici je montre la version “propre” à adopter.

<?php
// plugin ou mu-plugin (corrigé)

defined( 'ABSPATH' ) || exit;

add_action( 'admin_enqueue_scripts', function ( $hook_suffix ) {

	// $hook_suffix aide à cibler, mais le plus fiable reste current_screen.
	$screen = function_exists( 'get_current_screen' ) ? get_current_screen() : null;
	if ( ! ( $screen instanceof WP_Screen ) ) {
		return;
	}

	// Cibler la liste des Articles (post type "post")
	if ( 'edit' !== $screen->base || 'post' !== $screen->post_type ) {
		return;
	}

	// Dépendances WordPress : wp-api-fetch fournit window.wp.apiFetch
	wp_enqueue_script(
		'mon-admin-js',
		plugin_dir_url( __FILE__ ) . 'admin.js',
		array( 'wp-api-fetch', 'wp-i18n' ),
		'3.1.2',
		true
	);

	// Nonce REST : WordPress attend l'en-tête X-WP-Nonce
	wp_add_inline_script(
		'mon-admin-js',
		'window.MonPlugin = window.MonPlugin || {}; window.MonPlugin.restNonce = ' . wp_json_encode( wp_create_nonce( 'wp_rest' ) ) . ';',
		'before'
	);
}, 20 );

// admin.js (corrigé)
( function () {
	if ( ! window.wp || ! window.wp.apiFetch ) {
		return;
	}

	// Applique le nonce aux requêtes REST
	if ( window.MonPlugin && window.MonPlugin.restNonce ) {
		window.wp.apiFetch.use( window.wp.apiFetch.createNonceMiddleware( window.MonPlugin.restNonce ) );
	}

	// Test simple : récupérer 1 article
	window.wp.apiFetch( { path: '/wp/v2/posts?per_page=1&context=edit' } )
		.then( function ( data ) {
			// Vous pouvez vérifier dans la console si ça répond
			// console.log( data );
		} )
		.catch( function ( err ) {
			// console.error( err );
		} );
} )();

Pourquoi ça corrige

• Vous chargez le script uniquement là où il est utile (moins de risque de casser d’autres écrans).
• Les dépendances sont explicites : WordPress garantit l’ordre de chargement.
• Le nonce REST est correctement fourni, ce qui évite les 401 et les erreurs rest_cookie_invalid_nonce.

Références : REST API Authentication et wp_enqueue_script().

---

Solution 3 : permaliens, capacités et rôles (cas tordu mais courant après migration)

Quand le menu Articles renvoie une erreur d’accès, ou que seuls certains comptes sont touchés, je vérifie les capacités. Une capacité est un “droit” (ex : edit_posts) attaché à un rôle (Administrateur, Éditeur…).

Symptômes

• Vous voyez « Désolé, vous n’êtes pas autorisé à accéder à cette page. »
• Le menu Articles a disparu pour un rôle qui l’avait avant.
• Après migration, un plugin de rôles/capacités (ou sécurité) a “nettoyé” des droits.

Étape 1 : vérifier via Santé du site + Health Check

Avant de toucher aux rôles, passez en mode dépannage avec Health Check et désactivez temporairement les plugins de sécurité/rôles. Si Articles revient, vous avez déjà isolé la classe de problème.

Étape 2 : corriger proprement les capacités (sans plugin tiers)

Attention sécurité : donner des capacités trop larges est un risque. Ne faites pas “au hasard”.

Où coller le code : dans un mu-plugin temporaire, le temps de réparer. Ensuite, retirez-le pour éviter de “forcer” la config.

<?php
/**
 * Plugin Name: Temporary Role Fix - edit_posts
 * Description: Répare temporairement les capacités nécessaires pour accéder aux Articles.
 * Version: 1.0.0
 */

defined( 'ABSPATH' ) || exit;

add_action( 'init', function () {

	// On ne fait ça qu'une fois : si c'est déjà OK, on ne touche à rien.
	$role = get_role( 'editor' );
	if ( ! $role ) {
		return;
	}

	// Exemple : un Éditeur doit avoir edit_posts pour voir Articles.
	if ( ! $role->has_cap( 'edit_posts' ) ) {
		$role->add_cap( 'edit_posts' );
	}

	// Optionnel : selon votre besoin.
	if ( ! $role->has_cap( 'edit_published_posts' ) ) {
		$role->add_cap( 'edit_published_posts' );
	}
}, 20 );

Ensuite :

1. Rechargez l’admin.
2. Testez avec le compte concerné.
3. Quand c’est bon, supprimez ce mu-plugin et gérez les rôles proprement (plugin dédié ou code d’initialisation contrôlé).

Étape 3 : permaliens (à faire si vous voyez des comportements “bizarres”)

La page Articles ne dépend pas des permaliens, mais j’ai vu des sites où une migration cassait tellement de choses (cache, règles, plugins) que “rafraîchir les règles” résolvait aussi des redirections admin.

1. Allez dans Réglages → Permaliens.
2. Ne changez rien.
3. Cliquez Enregistrer les modifications.

Alternative WP-CLI :

wp rewrite flush --hard

Référence : wp rewrite flush.

---

Vérifications après correction

Une fois votre solution appliquée, vérifiez de façon méthodique :

1. Accès : /wp-admin/edit.php s’ouvre sans erreur.
2. Actions de base : filtre “Tous”, recherche, pagination, édition rapide.
3. Ajout : /wp-admin/post-new.php fonctionne.
4. Console navigateur : plus d’erreurs JS liées à votre plugin/snippet.
5. Logs : wp-content/debug.log ne reçoit plus de fatal error à l’ouverture.

Si vous utilisez un cache (plugin ou serveur), videz :

• cache du plugin (ex : page cache) ;
• OPcache si vous y avez accès (souvent via l’hébergeur) ;
• cache navigateur (ou test en navigation privée).

---

Si ça ne marche toujours pas

Voici ma procédure “terrain” quand Articles refuse toujours de s’ouvrir.

1) Isoler plugin/thème sans casser le site public

1. Installez Health Check.
2. Activez le mode dépannage (visible uniquement pour vous).
3. Désactivez tous les plugins dans ce mode.
4. Testez Articles.

Si ça remarche : réactivez les plugins un par un jusqu’à retrouver le coupable (souvent celui en v3.1.1).

2) Lire le fatal error exact

Si l’admin est inaccessible :

• ouvrez wp-content/debug.log ;
• ou consultez les logs PHP de l’hébergeur ;
• ou regardez l’e-mail “erreur critique” (il contient souvent le plugin et la ligne).

3) Désactiver un plugin via FTP ou WP-CLI

Sans accès admin, renommez le dossier du plugin suspect :

• wp-content/plugins/nom-du-plugin → nom-du-plugin.disabled

Ou WP-CLI :

wp plugin deactivate nom-du-plugin

4) Vérifier la mémoire PHP et les limites

La page Articles peut charger beaucoup d’éléments (colonnes, taxonomies, filtres). Si vous avez des erreurs du type Allowed memory size exhausted, augmentez la mémoire WordPress :

<?php
// wp-config.php (exemple)
// Sauvegardez avant de modifier.
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Si l’hébergeur impose une limite plus basse, il faudra aussi ajuster côté serveur.

5) Vérifier la console et l’onglet Réseau

• Console : erreurs JS qui pointent vers un plugin précis.
• Réseau : requêtes /wp-json/ en 401/403, ou fichiers JS/CSS en 404.

6) Conflit avec un page builder ?

Divi 5, Elementor et Avada touchent surtout l’édition (éditeur), pas la liste des articles. Mais j’ai déjà vu :

• un add-on Elementor qui enfile du JS sur toute l’admin et casse edit.php ;
• un module Divi/Avada qui ajoute des colonnes personnalisées via hooks et déclenche un fatal.

Test : désactivez uniquement les add-ons (pas forcément le builder principal) en mode dépannage Health Check.

---

Pièges et erreurs courantes

Symptôme	Cause probable	Vérification	Solution
Écran blanc sur Articles	Fatal error PHP dans un snippet	wp-content/debug.log montre fichier/ligne	Déplacer la logique sur current_screen + vérifs défensives
Erreur 500 uniquement sur edit.php	pre_get_posts modifie aussi l’admin	Recherchez pre_get_posts dans thème/plugins	Ajouter is_admin() + is_main_query() + conditions
Interface figée, boutons inactifs	JS admin cassé / dépendances manquantes	Console : Uncaught TypeError	Déclarer dépendances wp-api-fetch + cibler l’écran
401 REST / nonce invalide	Nonce REST absent ou non appliqué	Réseau : rest_cookie_invalid_nonce	wp_create_nonce('wp_rest') + middleware createNonceMiddleware
“Désolé, vous n’êtes pas autorisé…”	Capacités manquantes	Test avec admin vs éditeur	Réparer rôle/capacités, vérifier plugin de rôles/sécurité

Erreurs que je vois tout le temps (et qui font perdre des heures)

• Copier le code au mauvais endroit : dans le thème parent au lieu du thème enfant, ou dans un builder (champ “Code”) qui n’est pas fait pour du PHP.
• Oublier un point-virgule et provoquer un fatal error qui bloque toute l’admin.
• Utiliser un hook inadapté : admin_init au lieu de current_screen.
• Confondre action et filtre : une action exécute, un filtre modifie une valeur et doit return.
• Tester sur production sans sauvegarde : le plus rapide pour transformer un “petit bug” en incident.
• Oublier de vider le cache : vous corrigez le code, mais le serveur sert l’ancien JS via cache.
• Snippet via un plugin de snippets : certains plugins chargent les snippets très tôt, et un code “OK ailleurs” casse l’admin.

---

Variante / alternative

Méthode sans code (recommandée si vous débutez)

• Utilisez Health Check pour isoler le plugin fautif.
• Revenez à la version précédente du plugin (temporairement) si l’éditeur a publié une v3.1.1 cassée.
• Ouvrez un ticket support sur wordpress.org (si plugin du répertoire) avec :
• votre version WP (6.9.4), PHP, plugin (v3.1.1) ;
• l’erreur exacte du log ;
• les étapes pour reproduire.

Méthode plus avancée (développeurs)

Si vous avez identifié le plugin en v3.1.1 :

• activez Query Monitor et regardez l’onglet Hooks & Actions / Scripts ;
• repérez ce qui s’exécute sur edit.php ;
• patch local (mu-plugin) : désenregistrer un script, ou neutraliser un hook via remove_action() si le plugin expose une fonction nommée (pas une closure anonyme).

Note réaliste : si le plugin utilise des closures anonymes pour ses hooks, remove_action() devient difficile. Dans ce cas, la solution propre est un correctif côté plugin (ou une mise à jour de l’éditeur).

---

Éviter ce problème à l’avenir

1) Encadrer vos snippets (et arrêter le “PHP au hasard”)

Si vous devez ajouter du code, privilégiez un plugin custom (ou mu-plugin) plutôt que functions.php. Vous évitez de perdre le code lors d’un changement de thème (Divi/Avada/Elementor).

2) Toujours cibler l’écran admin

Règle simple : si votre code concerne un écran admin, utilisez current_screen et vérifiez $screen->base / $screen->post_type.

<?php
// Exemple de garde-fou réutilisable

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

	// Ne rien faire en dehors de la liste des Articles
	if ( 'edit' !== $screen->base || 'post' !== $screen->post_type ) {
		return;
	}

	// Votre logique ici
} );

3) Mettre en place une routine de mise à jour

• Mettre à jour d’abord sur staging.
• Lire le changelog du plugin (surtout si vous voyez “v3.1.1”).
• Après update : vérifier 3 pages admin critiques (Tableau de bord, Articles, Médias) + le front.

4) Garder PHP à jour

WordPress 6.9.4 tourne très bien en PHP 8.1+. Beaucoup de “bugs mystérieux” disparaissent quand on sort d’une version PHP trop ancienne. Référence PHP : PHP Supported Versions.

5) Sécurité : ne “désactivez pas tout” n’importe comment

Désactiver un plugin de sécurité peut rouvrir des portes. Utilisez le mode dépannage Health Check quand c’est possible, et réactivez dès que vous avez isolé le problème.

---

Ressources

• Debugging in WordPress (WP_DEBUG, logs)
• get_current_screen()
• Hook current_screen
• Hook pre_get_posts
• wp_enqueue_script()
• Authentification REST API (nonce)
• Query Monitor (plugin)
• Health Check & Troubleshooting (plugin)
• WordPress Core sur GitHub (référence code)
• WordPress Core Trac (tickets)

---

Questions fréquentes

Le message “v3.1.1 fails to open wp-admin articles” vient de WordPress ?

Non. WordPress 6.9.4 n’affiche pas ce message tel quel. C’est presque toujours un extrait de log, un titre de ticket, ou une note liée à un plugin/thème en version 3.1.1.

Pourquoi seule la page Articles casse, alors que tout le reste marche ?

Parce que edit.php déclenche des hooks et un affichage spécifiques (liste, colonnes, filtres). Un plugin qui touche la requête ou l’UI admin se voit immédiatement sur cet écran.

Je ne peux plus accéder à l’admin du tout. Je fais quoi ?

Renommez le dossier du plugin suspect via FTP, ou désactivez-le via WP-CLI. Ensuite activez WP_DEBUG_LOG pour récupérer l’erreur exacte.

Divi 5 / Elementor / Avada peuvent-ils provoquer ça ?

Le builder lui-même, rarement. Les add-ons et modules tiers, plus souvent (scripts admin globaux, colonnes, intégrations). Testez en mode dépannage en désactivant les add-ons avant de toucher au thème.

Est-ce que vider le cache peut suffire ?

Si la cause est un JS/CSS admin servi en cache (ou OPcache), oui. Mais si vous avez un fatal error PHP, vider le cache ne corrigera pas le code.

Quel est le meilleur endroit pour coller un correctif ?

Pour stabiliser l’admin : un mu-plugin. Pour une personnalisation liée au design : thème enfant. Évitez le thème parent et évitez de modifier WordPress lui-même.

J’ai corrigé le code, mais l’erreur persiste.

Videz cache plugin + navigateur, et vérifiez OPcache côté hébergeur. Ensuite, relisez debug.log : vous avez peut-être corrigé une erreur, mais une deuxième apparaît maintenant.

Je vois “rest_cookie_invalid_nonce” dans la console. C’est grave ?

C’est surtout bloquant pour les fonctionnalités qui utilisent la REST API (AJAX moderne). La correction est de générer un nonce REST côté PHP et de l’appliquer via wp.apiFetch côté JS. Évitez de “désactiver la vérification”, ce serait une faille.

Est-ce que je peux “forcer” l’accès à Articles en modifiant les rôles ?

Oui, mais faites-le prudemment. Ajoutez uniquement les capacités nécessaires (ex : edit_posts) et retirez le code temporaire une fois la situation rétablie, surtout sur un site multi-auteurs.

À quel moment dois-je contacter le support du plugin ?

Dès que vous avez : la version du plugin (v3.1.1), la version WP/PHP, et l’erreur exacte (fichier + ligne). Avec ça, un éditeur sérieux peut reproduire et publier un correctif rapidement.