Wenn Sie bereits darauf geklickt haben Artikel Wenn in wp-admin alles einfriert und eine seltsame Fehlermeldung wie „v3.1.1 kann wp-admin 'articles' nicht öffnen…“ erscheint, besteht wahrscheinlich ein Konflikt zwischen einem Plugin (Version 3.1.1), einem Snippet und der Beitragsliste (edit.php).


das Problem

Die genaue Fehlermeldung variiert je nach Plugin, Server und Sprache, aber ein typischer Trace beginnt oft so (in einem leerer Bildschirm(eine 500-Fehlerseite oder ein PHP-Log):

v3.1.1 fails to open wp-admin "articles" with a fatal error:
Uncaught TypeError: ... in /wp-content/plugins/mon-plugin/...
or
PHP Fatal error:  Uncaught Error: Call to undefined function ...
or
There has been a critical error on this website.

Wo es erscheint:

  • Nur für Administratoren : durch Öffnen Artikel> Alle Artikel (Typische URL: /wp-admin/edit.php), manchmal auch hinzufügen (URL: /wp-admin/post-new.php).
  • Manchmal in AJAX : L 'Bildschirm Beim Laden der Datei und anschließender Ausführung einer Aktion (Filter, Suche, Schnellbearbeitung) tritt ein Fehler auf.
  • Seltener in REST API Wenn ein Plugin die POST-Anfrage über REST verändert, kann dies auch Gutenberg beeinträchtigen.

Typische Umstände, die ich bei der Fehlersuche beobachtet habe:

  • Direkt nach einem Plugin-Update v3.1.1 (Die Zahl „3.1.1“ ist fast immer die eines Plugins, nicht die eines WordPress).
  • Nachdem ich einen Code-Schnipsel aus einem alten Tutorial hinzugefügt hatte, der „Beiträge in Artikel umbenannt“.
  • Nach der Aktivierung eines SEO-/Weiterleitungs-/Sicherheits-Plugins, das die Funktionen oder das Admin-Menü beeinflusst.
  • Auf Websites, die Divi 5, Elementor oder Avada verwenden: Diese Builder verursachen keine direkten Probleme. edit.phpSie existieren jedoch häufig zusammen mit „Snippets“ und Plugins, die das System zum Absturz bringen.

Für wen ist dieser Leitfaden gedacht? Wenn Sie Anfänger sind, können Sie Folgendes erkennen: Welcher Ziegelstein zerbricht den Bildschirm? ArtikelErhalten Sie wieder Zugriff auf das Admin-Panel und führen Sie eine saubere Reparatur von WordPress durch. 6.9.4 (April 2026) und PHP 8.1.

Kurze Zusammenfassung

  • Die Speisekarte Artikel zeigen auf /wp-admin/edit.phpWenn diese Seite abstürzt, liegt das fast immer daran, dass... Hook-Admin (Aktion/Filter) eines Plugins oder Snippets.
  • Beginnen Sie mit der Aktivierung. WP_DEBUG_LOG und / oder Gesundheitscheck um das fehlerhafte Plugin zu isolieren, ohne die öffentliche Website zu beeinträchtigen.
  • Häufiger Fall: ein fälschlicherweise deklarierter CPT-Code „Artikel“ (register_post_type()) mit etwas inkonsistente Fähigkeiten oder Schnecke was in einen Konflikt gerät.
  • Nach der Korrektur: Permalinks erneut speichern und leeren Sie die Caches (Plugin/Server/Browser).
  • Falls Sie keinen Zugriff mehr auf wp-admin haben: Deaktivieren Sie das Plugin per FTP (benennen Sie den Ordner um) oder WP-CLI.

Symptome

Hier ist eine Liste der Beobachtungen, von den häufigsten bis zu den irreführendsten:

  • Bildschirm weiß en cliquant sur Artikel, manchmal mit „kritischem Fehler“.
  • Fehler 500 nur an /wp-admin/edit.php (Die anderen Admin-Seiten funktionieren.)
  • „Sie sind leider nicht berechtigt, auf diese Seite zuzugreifen.“ während Sie Administrator sind.
  • Leere Artikelliste (0 Ergebnisse), aber es existieren Artikel.
  • Defekte Filter/Suche (Die Seite wird geladen, stürzt dann aber beim Sortieren nach Autor/Kategorie ab).
  • Schnellbearbeitung (Schnellbearbeitung), die sich nicht mehr öffnen lässt oder endlos läuft (oft ein AJAX-Problem).
  • Browserkonsole (F12): JS-Fehler bei edit.php (oftmals verknüpft mit einem Skript, das von einem Plugin eingebunden wird).

Anzeichen für Plugin-/Theme-Konflikte:

  • Das Problem verschwindet, wenn man ein „kürzlich aktualisiertes“ Plugin deaktiviert.
  • Das Problem tritt nur bei bestimmten Rollen auf (Redakteur, Autor): Verdacht bezüglich der Ressourcen.
  • Das Problem tritt auf, nachdem ein „Codeausschnitt“ eingefügt wurde in functions.php (Child-Theme) oder ein Snippets-Plugin.

Schnelle Diagnose: wenn /wp-admin/edit.php?post_type=page (Pages) funktioniert, aber /wp-admin/edit.php (Beiträge) Fehler, wir haben es oft mit Code zu tun, der speziell darauf abzielt post oder das Menü „Artikel“.

Warum passiert das

Anfängerversion: der Bildschirm Artikel Dies ist eine Standard-Adminseite. Viele Plugins erweitern diese Seite (Spalten, Filter, Sortierung, Rollenbeschränkungen, Statistiken). Wenn ein Plugin (oder ein Code-Snippet) einen PHP-/JS-Fehler verursacht, stürzt diese Seite ab.

Folgendes passiert im Hintergrund: WordPress wird geladen wp-admin/edit.php, erstellt eine Listenabfrage (WP_Queryführt dann eine Reihe von HakenEin Haken ist ein Verlängerungspunkt. Aktion führt Code zu einem bestimmten Zeitpunkt aus, ein Filter ändert einen Wert (z. B. die Abfrage, Spalten, HTML). Wenn ein Filter einen falschen Typ zurückgibt (z. B. null (anstelle eines Arrays) ist PHP 8.1+ weniger tolerant und kann einen Fehler auslösen Typfehler.

Mögliche Ursachen (von der häufigsten zur seltensten):

  • Plugin v3.1.1 ist fehlerhaft wodurch Spalten/Filter zur Liste der Beiträge hinzugefügt werden und ein schwerwiegender Fehler ausgelöst wird.
  • Alter Ausschnitt (vor PHP 8 / vor dem modernen WordPress) das einen ungeeigneten Hook oder eine nicht geladene Funktion verwendet.
  • CPT-Artikel Registriert mit einem Slug/Capabilities, der mit „post“ (Native Articles) in Konflikt steht und Berechtigungen verletzt.
  • REST/Rewrite-Konflikt Nach der Migration: Permalinks werden nicht neu generiert, Rewrite-Regeln sind veraltet.
  • Aggressiver Cache (Ein Admin-Cache ist äußerst selten, aber durch einen falsch konfigurierten Reverse-Proxy möglich) oder durch eine JS-Minifizierung, die die Admin-Oberfläche beeinträchtigt.
  • Serverproblem : PHP-Speicher zu gering, OPcache beschädigt, Dateiberechtigungen oder PHP < 8.1.

Hinweis zu „v3.1.1“: WordPress 6.9.4 kennt die Versionsnummer „v3.1.1“ nicht. Wenn „v3.1.1“ angezeigt wird, handelt es sich fast immer um die Versionsnummer eines Plugins (oder Themes). Zur Diagnose muss ermittelt werden, welches Plugin oder Theme betroffen ist.

Voraussetzungen vor Beginn

  • Sauvegarde Datenbank + Dateien. Nicht „zufällig“ in der Produktionsumgebung testen.
  • Test Umgebung Wenn möglich (Staging-Umgebung). Ich habe schon oft erlebt, dass ein fehlendes Semikolon die gesamte Admin-Oberfläche blockiert hat.
  • Versionen WordPress 6.9.4 und PHP 8.1+ (idealerweise 8.2/8.3, falls Ihr Hosting-Anbieter dies zulässt). Bitte prüfen Sie die Kompatibilität. Tools > Site-Status.
  • Werkzeuge :

WordPress-Protokolle aktivieren (in wp-config.php(über „Bearbeitung beenden“):

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false ); // Affichez false en prod pour éviter de divulguer des infos

Offizielle Referenz: Debuggen in WordPress.

Sicherheitsrisiko PHP-Fehler sollten in der Produktionsumgebung niemals auf dem Bildschirm angezeigt werden. Ein Stacktrace kann Pfade, Versionen und mitunter auch Geheimnisse offenlegen.

Lösung 1: Beheben Sie einen CPT-Eintrag „Artikel“ (Slug/Capabilities), der die Admin-Oberfläche beeinträchtigt.

Dies geschieht, wenn jemand einen „Artikel-Inhaltstyp erstellen“ möchte, obwohl WordPress native Beiträge bereits als „Artikel“ bezeichnet.postErgebnis: verwirrende Beschriftungen, doppelte Menüs und manchmal eine Meldung wie „Sie sind nicht autorisiert…“ oder ein Seitenabsturz, wenn ein Plugin erwartet, post erhält aber einen anderen post_type.

Konzepte :

  • CPT = Benutzerdefinierter Beitragstyp (benutzerdefinierter Inhaltstyp), deklariert über register_post_type().
  • Schnecke = URL-Kennung (z.B. article), die in Permalinks und manchmal auch im Adminbereich verwendet werden.
  • Leistungsportfolio = Berechtigungen (z.B., edit_posts, edit_pagesWenn sie falsch zugeordnet sind, verweigert der Administrator den Zugriff.

Wann ist diese Ursache zu vermuten?

  • Es gibt ein Menü „Artikel“, das nicht die übliche Liste der Beiträge öffnet.
  • Sie sehen eine URL des Typs /wp-admin/edit.php?post_type=articles.
  • Das Problem begann nach dem Hinzufügen des Code-Snippets „register_post_type('articles', …)“.

Wo korrigieren?

Der richtige Ort: ein kleines, individuell angepasstes Plugin (empfohlen) oder ein Mu-Plugin (Plugin erforderlich) Wenn Sie sichergehen möchten, dass es auch bei einem Theme-Wechsel geladen wird.

  • Fügen Sie dies nicht in ein Snippets-Plugin ein. Wenn Sie sich im Fehlerbehebungsmodus befinden: Wenn das Snippets-Plugin nicht mehr funktioniert, verlieren Sie den Zugriff.
  • Wenn es schnell gehen muss: Kinderthema functions.phpAber es ist zerbrechlicher.

VORHERiger Code (defekt)

Ein realistisches Beispiel, dem ich häufig begegne (Slug „Artikel“, inkonsistente Fähigkeiten und Label-Kollisionen):

<?php
// functions.php (thème enfant) - EXEMPLE CASSÉ
add_action( 'init', function() {
	register_post_type( 'articles', [
		'label' => 'Articles',
		'public' => true,
		'show_in_menu' => true,
		'show_in_rest' => true,
		'rewrite' => [ 'slug' => 'articles' ],
		// Problème : capabilities bricolées, et parfois l’auteur n’a plus accès à edit.php
		'capability_type' => 'page',
		'map_meta_cap' => false,
	] );
} );

Warum es kaputt geht: mit capability_type => 'page' et map_meta_cap => falseSie erstellen einen Typ, der sich wie Seiten für Berechtigungen verhält, jedoch ohne korrekte Zuordnung. Abhängig von Rollen und Sicherheits-Plugins kann der Zugriff auf die Liste verweigert werden oder Fehler verursachen, wenn WordPress die Berechtigungen berechnet.

Code NACH (korrigiert)

Ziel: Konflikte mit „Artikeln“ (eigenen Beiträgen) vermeiden und einheitliche Berechtigungen gewährleisten. Ich empfehle:

  • Ein eindeutiger Slug und Bezeichner (z. B. mag_article ou ressource).
  • Explizite Bezeichnungen (z. B. „Ressourcen“).
  • Funktionen korrekt abgebildet über map_meta_cap => true.
<?php
/**
 * Plugin: Mon CPT Ressources (corrigé)
 * Emplacement : /wp-content/mu-plugins/cpt-ressources.php
 * (Créez le dossier mu-plugins s'il n'existe pas)
 */

add_action( 'init', function() {

	$labels = [
		'name'                  => 'Ressources',
		'singular_name'         => 'Ressource',
		'add_new'               => 'Ajouter',
		'add_new_item'          => 'Ajouter une ressource',
		'edit_item'             => 'Modifier la ressource',
		'new_item'              => 'Nouvelle ressource',
		'view_item'             => 'Voir la ressource',
		'search_items'          => 'Rechercher des ressources',
		'not_found'             => 'Aucune ressource trouvée',
		'not_found_in_trash'    => 'Aucune ressource dans la corbeille',
		'all_items'             => 'Toutes les ressources',
		'menu_name'             => 'Ressources',
	];

	register_post_type( 'ressource', [
		'labels'            => $labels,
		'public'            => true,
		'show_in_menu'      => true,
		'show_in_rest'      => true, // Compatible Gutenberg + REST
		'menu_position'     => 21,
		'menu_icon'         => 'dashicons-media-document',
		'supports'          => [ 'title', 'editor', 'thumbnail', 'excerpt', 'author' ],
		'has_archive'       => true,
		'rewrite'           => [ 'slug' => 'ressources', 'with_front' => false ],
		'capability_type'   => 'post',
		'map_meta_cap'      => true, // Important : mapping correct des permissions
	] );

}, 10 );

Warum korrigiert es?

  • Sie vermeiden die mentale und technische Kollision mit „Artikeln“ (nativen Beiträgen).
  • WordPress weiß, wie Berechtigungen „wie bei einem Beitrag“ (Standard) berechnet werden, was Konflikte mit Rollen-/Sicherheits-Plugins stark reduziert.
  • Der CPT ist REST/Gutenberg-kompatibel (show_in_rest), wodurch seltsames Verhalten im Editor vermieden wird.

Ein unerlässlicher Schritt nach dieser Korrektur

gehen Einstellungen> Permalinks und klicken Sie auf Speichern (ohne etwas zu ändern). Dadurch wird WordPress gezwungen, die Rewrite-Regeln neu zu generieren.

Offizielles Dokument: register_post_type().

Dieses Szenario tritt häufig nach folgenden Ereignissen auf:

  • Website-Migration (URL-Änderung),
  • Aktivieren/Deaktivieren eines Plugins, das CPTs/Taxonomien erstellt,
  • Aktualisierung „v3.1.1“ eines Plugins, das seine Slugs ändert,
  • Wiederherstellung einer Teilsicherung.

Dies führt nicht immer zu einem schwerwiegenden PHP-Fehler. Manchmal öffnet sich die Seite „Artikel“, aber bestimmte Filter oder Aktionen senden Anfragen, die fehlschlagen (REST/AJAX), und die Benutzeroberfläche erscheint „defekt“.

Schnelldiagnose (kein Code erforderlich)

  • Test /wp-admin/edit.php puis /wp-admin/edit.php?post_status=trash.
  • Öffnen Sie die Browserkonsole (F12) und sehen Sie sich den Tab „Netzwerk“ an: Aufrufe an /wp-json/ in 404/401/500?
  • gehen Tools > Site-Status und beachten Sie die Empfehlungen (REST-API, Schleifen usw.).

Korrektur 1: Vollständige Löschung der Permalinks (UI)

Die sicherste Option: Einstellungen> Permalinks > Speichern.

Korrektur 2: Leeren Sie den Cache über WP-CLI (falls die Admin-Oberfläche instabil ist).

Wenn Sie WP-CLI verwenden (häufig auf VPS/Managed Hosting), führen Sie Folgendes aus:

wp rewrite flush --hard

WP-CLI-Referenz: wp rewrite flush.

VORHERIGER Code (fehlerhaft): Spülung an der falschen Stelle

Ich habe beobachtet, dass dieser Codeabschnitt im Administratormodus zu Verlangsamungen, Timeouts und sogar zu unberechenbarem Verhalten führt:

<?php
// EXEMPLE CASSÉ : flush à chaque chargement
add_action( 'init', function() {
	flush_rewrite_rules(); // Très mauvais : lourd, et peut provoquer des effets de bord
} );

NACH Code (korrigiert): Nur bei Aktivierung leeren

Fügen Sie diesen Code in eine benutzerdefinierte Plugins (Ex: /wp-content/plugins/mon-fix/mon-fix.phpAktivieren Sie es anschließend. Danach können Sie es behalten (ohne es endgültig zu löschen) oder löschen.

<?php
/**
 * Plugin Name: Fix Permaliens (flush à l'activation)
 * Description: Force une régénération des règles de réécriture à l'activation uniquement.
 */

register_activation_hook( __FILE__, function() {
	// On régénère proprement les règles une seule fois
	flush_rewrite_rules();
} );

register_deactivation_hook( __FILE__, function() {
	// Optionnel : on flush à la désactivation si le plugin ajoutait des règles
	flush_rewrite_rules();
} );

Warum korrigiert es?

  • Sie eliminieren ein Anti-Muster: flush_rewrite_rules() sollte nicht auf jeder Seite umgeblättert werden.
  • Sie setzen die Regeln nach einer Änderung des benutzerdefinierten Beitragstyps (CPT) bzw. des Slugs zurück, wodurch einige Administrationsbildschirme und die zugehörigen REST/AJAX-Endpunkte stabilisiert werden.

Offizielles Dokument: spülen_umschreiben_regeln().

Lösung 3: Aufspüren eines schwerwiegenden PHP-Fehlers auf der Seite „Artikel“ (Admin-Hooks, Spalten, Filter)

Dies ist die häufigste Ursache für den Fehler „v3.1.1 kann wp-admin-Artikel nicht öffnen…“. Ein Plugin (v3.1.1) oder ein Code-Snippet fügt eine Spalte hinzu, ändert die Abfrage oder filtert die Zeilen und löst dadurch einen PHP-Fehler aus (TypeError, undefinierte Funktion usw.).

Schritt 1: Ermitteln Sie den genauen Fehler.

geöffnet wp-content/debug.log nach Reproduktion des Fehlers (klicken Sie auf ArtikelSuchen Sie nach einer Zeile mit einem Pfad wie diesem: „PHP Fatal error“.

PHP Fatal error:  Uncaught TypeError: array_merge(): Argument #2 must be of type array, null given
in /wp-content/plugins/mon-plugin/includes/admin-columns.php:123
Stack trace:
#0 ...

Falls das Protokoll fehlt, installieren Sie Query Monitor und überprüfen Sie den Tab „PHP-Fehler“ (falls die Seite nur teilweise geladen wird). Dokumentation zu Query Monitor: WordPress.org.

Schritt 2: Isolation ohne Unterbrechung des öffentlichen Bereichs (Gesundheitscheck)

Mit Health Check & Fehlerbehebung :

  1. Aktivieren Sie den Fehlerbehebungsmodus (nur für Ihre Sitzung).
  2. Test ArtikelWenn es funktioniert: Das Problem liegt an einem Plugin/Theme, das im Fehlersuchmodus deaktiviert wurde.
  3. Aktivieren Sie die Plugins nacheinander wieder, bis der Absturz reproduzierbar ist.

Meiner Erfahrung nach ist dies der schnellste Weg, das „v3.1.1-Plugin“ zu identifizieren, ohne die Website unzugänglich zu machen.

Typischer Fall: Ein Spaltenfilter gibt den falschen Datentyp zurück.

auf edit.phpViele Codes verwenden den Filter manage_posts_columns (oder manage_edit-post_columns) zum Hinzufügen von Spalten. Ein klassischer Fehler in PHP 8+: Rückgabewert null anstelle eines Gemäldes.

VORHERiger Code (defekt)

Realistisches Beispiel: Ein Plugin/Code-Snippet möchte eine Spalte löschen, vergisst aber, das Array zurückzugeben:

<?php
// EXEMPLE CASSÉ : filtre qui ne retourne rien (donc null)
add_filter( 'manage_posts_columns', function( $columns ) {

	unset( $columns['comments'] );

	// Oubli : return $columns;
}, 10, 1 );

Mögliches Ergebnis: Im weiteren Verlauf führt WordPress (oder ein anderes Plugin) Folgendes aus: array_merge() von $columns und erhält null → TypeError → Bildschirm „Artikel in falscher Reihenfolge“.

Code NACH (korrigiert)

Fügen Sie diesen Fix in ein benutzerdefiniertes Plugin ein (oder functions.php (zum Thema Kinder) nach dem SpeichernWenn Sie ein Problem mit einem Plugin vermuten, korrigieren Sie es in Ihrem eigenen Code und deaktivieren Sie das fehlerhafte Plugin.

<?php
/**
 * Correctif : toujours retourner un tableau de colonnes.
 * Emplacement : functions.php (thème enfant) OU plugin custom.
 */
add_filter( 'manage_posts_columns', function( $columns ) {

	if ( ! is_array( $columns ) ) {
		// Sécurité : évite les TypeError si un autre code a renvoyé n'importe quoi
		$columns = [];
	}

	unset( $columns['comments'] );

	return $columns;

}, 10, 1 );

Warum korrigiert es?

  • Ein Filter doit Gibt einen Wert zurück. Andernfalls ruft WordPress einen Wert ab. null.
  • Die Schutzmaßnahme is_array() Schützt Sie auch dann, wenn ein anderes Plugin einen falschen Typ zurückgibt.

Offizielle Dokumentation zu Hooks (Aktionen/Filtern): Plugin-API: Hooks.

Typischer Fall: ein "Pre-Request"-Hook, der die Liste unterbricht (pre_get_posts)

Ein weiterer klassischer Fehler: Man möchte Beiträge im Adminbereich filtern und ändert dabei alle Abfragen, auch die in der Adminliste. Die Seite „Artikel“ wird leer, lädt langsam oder stürzt ab, wenn die Abfrage ungültig wird.

VORHERiger Code (defekt)

<?php
// EXEMPLE CASSÉ : modifie toutes les requêtes, y compris l'admin
add_action( 'pre_get_posts', function( $query ) {

	// Mauvais : pas de garde-fous, touche REST, admin, widgets, etc.
	$query->set( 'posts_per_page', 500 );
	$query->set( 'post_status', 'publish' );

} );

Code NACH (korrigiert)

Ziel: Nur die Hauptanfrage im Frontend ändern, nicht das Admin-Panel. Dies soll in einem benutzerdefinierten Plugin oder Child-Theme implementiert werden.

<?php
/**
 * Correctif : limiter l'impact de pre_get_posts.
 * Emplacement : functions.php (thème enfant) OU plugin custom.
 */
add_action( 'pre_get_posts', function( $query ) {

	// Toujours vérifier qu'on ne casse pas l'admin
	if ( is_admin() ) {
		return;
	}

	// Ne modifier que la requête principale
	if ( ! $query->is_main_query() ) {
		return;
	}

	$query->set( 'posts_per_page', 12 );

}, 10, 1 );

Offizielles Dokument: pre_get_posts.

Typischer Fall: Ein in das Admin-Panel eingeschleustes JavaScript-Skript beschädigt edit.php.

Falls in der Konsole JS-Fehler angezeigt werden, suchen Sie nach einem Plugin, das ein Skript im gesamten Adminbereich einbindet, manchmal minimiert, manchmal abhängig von einer fehlenden Bibliothek.

VORHERiger Code (defekt)

<?php
// EXEMPLE CASSÉ : charge un script admin partout, sans dépendances ni ciblage
add_action( 'admin_enqueue_scripts', function() {
	wp_enqueue_script(
		'mon-admin',
		plugin_dir_url( __FILE__ ) . 'admin.js',
		[],
		'3.1.1',
		true
	);
} );

Code NACH (korrigiert)

Wir konzentrieren uns ausschließlich auf die Seite „Artikel“ (Beiträge) und deklarieren angemessene Abhängigkeiten.

<?php
/**
 * Correctif : charger le JS uniquement sur l'écran des articles.
 * Emplacement : plugin custom (recommandé).
 */
add_action( 'admin_enqueue_scripts', function( $hook_suffix ) {

	// L'écran liste des posts natifs est généralement edit.php
	if ( 'edit.php' !== $hook_suffix ) {
		return;
	}

	// Optionnel : s'assurer qu'on est bien sur post (et pas un CPT)
	$post_type = isset( $_GET['post_type'] ) ? sanitize_key( $_GET['post_type'] ) : 'post';
	if ( 'post' !== $post_type ) {
		return;
	}

	wp_enqueue_script(
		'mon-admin',
		plugin_dir_url( __FILE__ ) . 'admin.js',
		[ 'jquery' ], // Exemple : dépendance explicite si votre script utilise jQuery
		'3.1.2', // Bump de version pour casser le cache navigateur
		true
	);

}, 10, 1 );

Offizielles Dokument: admin_enqueue_scripts et wp_enqueue_script ().

Nachkorrekturprüfungen

  • Aufladen /wp-admin/edit.php im privaten Browsermodus (vermeidet einen aggressiven Cache).
  • Probieren Sie es aus:
    • Suche nach einem Artikel
    • Nach Kategorie filtern
    • Schnellbearbeitung
    • Korb
  • Scheck wp-content/debug.log : Es erscheint keine Fehlermeldung mehr beim Klicken.
  • Falls Sie ein Caching-Plugin verwenden: Leeren Sie den Plugin-Cache + Server-Cache (falls zutreffend) + Browser-Cache.

Falls der Fehler auf einem Berechtigungskonflikt beruht: Testen Sie mit einem Redakteurskonto (nicht nur mit einem Administratorkonto). Viele Websites scheinen für Administratoren zu funktionieren, bleiben aber für Benutzer mit niedrigeren Berechtigungen weiterhin fehlerhaft.

Wenn das immer noch nicht funktioniert

Fehlerbehebungsverfahren, das ich anwende, wenn der Bildschirm „Artikel“ nicht zugänglich bleibt.

1) Deaktivieren Sie das fehlerhafte Plugin ohne wp-admin (FTP)

  1. Verbindung via FTP/SFTP herstellen.
  2. gehen /wp-content/plugins/.
  3. Benennen Sie den Ordner des verdächtigen Plugins um (z. B. mon-pluginmon-plugin.off).
  4. Aktualisieren Sie wp-admin.

Falls Sie nicht wissen, welches: Benennen Sie es vorübergehend um. plugins en plugins.off (Deaktiviert alle Plugins), dann können sie einzeln wieder aktiviert werden.

2) PHP-Speicher prüfen

Eine große Artikelliste (viele Spalten, Abfragen, Statistiken) kann zu einem extrem hohen Speicherverbrauch führen. Achten Sie auf die Fehlermeldung „Zulässige Speichergröße…“.

Sie können das WordPress-Limit erhöhen (sofern Ihr Hosting-Anbieter dies zulässt):

<?php
// wp-config.php
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' ); // Pour l'admin

Reference: wp-config.php (Konstanten).

3) Überprüfen Sie die PHP-Version

Bei Verwendung von PHP 7.4/8.0 verhalten sich einige neuere Plugins (oder WordPress 6.9.4) möglicherweise anders. Wir empfehlen mindestens PHP 8.1.

Dokument: Unterstützte PHP-Versionen.

4) Auf REST/AJAX-Fehler prüfen

  • geöffnet /wp-json/ : muss im JSON-Format antworten (nicht mit einem HTML 404-Fehler).
  • Prüfen Sie, ob ein Sicherheits-Plugin dies blockiert. /wp-json/ ou admin-ajax.php.

REST-Dokumentation: WordPress REST API-Handbuch.

5) Abfragemonitor: Identifizieren Sie den fehlerhaften Hook/Filter.

Wenn die Seite nur teilweise geladen wird, kann Ihnen der Abfragemonitor Folgendes anzeigen:

  • PHP-Fehler
  • langsame Abfragen
  • Skript-/Stilfehler
  • ausgelöste Hooks

6) Letzter Ausweg: Wiederherstellungsmodus aktivieren

WordPress verfügt über einen Wiederherstellungsmodus, der aktiviert wird, wenn ein Plugin einen schwerwiegenden Fehler im Administrationsbereich verursacht. Sollten Sie eine E-Mail mit dem Hinweis „Auf Ihrer Website ist ein technischer Fehler aufgetreten“ erhalten, verwenden Sie den Wiederherstellungslink, um das fehlerhafte Plugin zu deaktivieren.

Dokument: Wiederherstellungsmodus (Unterstützung).

Häufige Fallstricke und Fehler

Diagnosetabelle

Symptom Mögliche Ursache Überprüfung Lösung
Kritischer Fehler nur bei „Artikeln“ Plugin v3.1.1 fügt Spalten/Filter und Pflanzen hinzu Die Datei debug.log zeigt einen Pfad in /plugins/... an. Deaktivieren/Rollback des Plugins, Hook reparieren (Lösung 3).
„Tut mir leid, Sie sind nicht berechtigt…“ Falsch zugeordnete CPT-Funktionen oder Rollen-Plugin Testen Sie mit Administratorrechten im Vergleich zu Bearbeitungsrechten und prüfen Sie die benutzerdefinierten Beitragstypen. Korrekte CPT-/CAPS-Codes (Lösung 1), Rollen-Plugin überprüfen
Leere Liste (0 Einträge), aber sie existieren pre_get_posts modifiziert die Admin-Anfrage Code-Snippet deaktivieren, Code von pre_get_posts prüfen Füge Schutzmechanismen für is_admin/is_main_query hinzu (Lösung 3)
Schnellbearbeitung lässt sich nicht öffnen JS-Admin- oder Admin-Ajax-Blockierungsfehler Konsole F12 + Registerkarte Netzwerk Warteschlange anvisieren, Minifizierung deaktivieren, AJAX zulassen
Problem nach der Migration Überholte Regeln neu schreiben Einstellungen > Permalinks, Test /wp-json/ Permalinks leeren (Lösung 2)

Fehler, die ich ständig sehe

  • Kopieren Sie den Code an die falsche Stelle Wenn man einen PHP-Codeausschnitt in ein "CSS"-Feld im Builder oder im Seiteneditor einfügt, funktioniert entweder gar nichts oder der Code wird als Klartext angezeigt.
  • Ein Semikolon vergessen in functions.php Ein einfacher Fehler blockiert den gesamten Zugriff auf wp-admin. Arbeiten Sie in einer Testumgebung und stellen Sie den FTP-Zugriff sicher.
  • Verwendung eines unpassenden Hakens Ändern Sie beispielsweise die Administratoranfrage über pre_get_posts ohne is_admin().
  • Verwechslung von Aktien und Filtern Ein Filter muss einen Wert zurückgeben. Eine Aktion hingegen nicht. Hier kann ein Rückgabefehler die Funktion „Artikel“ beeinträchtigen.
  • Cache nicht geleert Sie haben es korrigiert, aber der Browser liefert immer noch die alte JavaScript-Version. Aktualisieren Sie die Skriptversion und leeren Sie den Cache.
  • Test im Produktivbetrieb ohne Backup : Im Admin-Panel kann es dazu führen, dass Sie ausgesperrt werden.
  • Code-Snippet durch ein Snippet-Plugin beschädigt Wenn das Snippets-Plugin abstürzt, lässt es sich nicht mehr so ​​einfach deaktivieren. Für Fehlerbehebungen ist ein MU-Plugin vorzuziehen.
  • Code aus einem alten Tutorial Nicht kompatibel mit PHP 8.1+ (TypeError, erforderliche Parameter usw.).

Variante / Alternative

Methode ohne Code: Zurücksetzen auf Version „v3.1.1“

Wenn Sie festgestellt haben, dass „v3.1.1“ die Version eines Plugins ist und der Fehler unmittelbar danach aufgetreten ist:

  • Überprüfen Sie die Plugin-Seite auf WordPress.org, um zu sehen, ob es einen Abschnitt gibt. Erweiterte Ansicht Ermöglichung des Herunterladens einer früheren Version.
  • Oder verwenden Sie ein Rollback-Plugin (z. B. WP Rollback). mit Vorsicht und nur aus einer zuverlässigen Quelle.

Als Nächstes erstellen Sie ein Support-Ticket für das Plugin mit folgender Adresse:

  • Ihre WordPress-Version (6.9.4), PHP,
  • das vollständige Fehlerprotokoll,
  • die Schritte zur Reproduktion.

Erweiterte Methode: mu-Plugin „Bumper“, um schwerwiegende Fehler in edit.php zu verhindern.

Wenn Sie einen Administrator dringend stabilisieren müssen, können Sie einen bekannten Sicherheitsfehler (z. B. einen Spaltenfilter) neutralisieren, indem Sie ihn durch defensiven Code ersetzen. Achtung: Dies ist nur eine Notlösung. Sie müssen anschließend das zugrundeliegende Problem beheben.

Beispiel: Sie haben einen Filter identifiziert, der manchmal Folgendes zurückgibt nullSie können das Plugin nicht verändern (oder Sie möchten dessen Code nicht anfassen). Sie fügen einen Filter in einer späten Phase hinzu, der Folgendes "behebt":

<?php
/**
 * Emplacement : /wp-content/mu-plugins/admin-edit-php-safety.php
 * Objectif : sécuriser le tableau des colonnes si un plugin renvoie un type invalide.
 */

add_filter( 'manage_posts_columns', function( $columns ) {

	// Si un plugin a renvoyé null, on rétablit un tableau minimal
	if ( ! is_array( $columns ) ) {
		$columns = [
			'cb'    => '<input type="checkbox" />',
			'title' => 'Titre',
			'date'  => 'Date',
		];
	}

	return $columns;

}, 9999, 1 );

Dies behebt das Problem mit dem Plugin nicht, ermöglicht Ihnen aber möglicherweise wieder den Zugriff auf den Bildschirm, um die Diagnose fortzusetzen.

Vermeiden Sie dieses Problem in Zukunft

  • Vermeiden Sie es, einen CPT als „Artikel“ zu bezeichnen. : Verwenden Sie die Kategorie „Artikel“ für native Beiträge. Benennen Sie Ihre benutzerdefinierten Beitragstypen (CPTs) entsprechend ihrer geschäftlichen Rolle (Ressourcen, Projekte, Rezepte usw.).
  • Keine dauerhafte Spülung : flush_rewrite_rules() nur bei Aktivierung/Deaktivierung.
  • Defensiver Code auf Filtern : die Typen validieren (is_array, is_string) wenn Sie Werte filtern, die von anderen Plugins verwendet werden.
  • Systematische Stadieneinteilung Vor größeren Plugin-Updates kann Version 3.1.1 einen Fehler auf einer bestimmten Admin-Oberfläche enthalten.
  • Auf Fehler überwachen halten WP_DEBUG_LOG Einfache Aktivierung und Einrichtung der serverseitigen Logrotation.
  • Plugins und Builder Divi 5, Elementor und Avada verhindern diese Fehler nicht. Vermeiden Sie jedoch „All-in-One“-Performance-Plugins, die gleichzeitig die Admin-Funktionalität einschränken: Dies ist eine häufige Ursache für JavaScript-Fehler. edit.php.

Wenn Sie entwickeln: Dokumentieren Sie Ihre Hooks. Ein Filter, der nichts zurückgibt, ist eine tickende Zeitbombe, insbesondere mit PHP 8.1+.

Ressourcen

Häufig gestellte Fragen

Wie finde ich heraus, welches Plugin zu „v3.1.1“ gehört?

aussehen wp-content/debug.log Der Pfad zur fehlerhaften Datei verweist fast immer auf /wp-content/plugins/nom-du-plugin/Alternativ können Sie den Health Check nutzen, indem Sie die Plugins einzeln reaktivieren.

Ich habe keinen Zugriff auf wp-admin, was soll ich tun?

Benennen Sie den Ordner des verdächtigen Plugins per FTP/SFTP um (oder deaktivieren Sie alle Plugins durch Umbenennen). /wp-content/pluginsDann stellen Sie die Verbindung wieder her und reaktivieren Sie sie schrittweise.

Könnte Divi 5 / Elementor / Avada diesen Fehler verursachen?

Sie provozieren es selten direkt. edit.phpEin Add-on, ein Snippet-Plugin oder eine Optimierung (Minifizierung), die zusammen mit dem Builder installiert wurde, kann jedoch die Admin-Oberfläche beeinträchtigen. Die Diagnose bleibt dieselbe: Protokolle analysieren und das betroffene Plugin isolieren.

Warum tritt der Fehler nur bei „Artikeln“ und nicht an anderen Stellen auf?

Da viele Plugins spezifische Hooks im Zusammenhang mit der Beitragsliste verwenden (Spalten, Sortierung, Filter, Einschränkungen), wird ein Fehler in diesem Code nur bei bestimmten Ereignissen ausgelöst. wp-admin/edit.php.

Kann ich das Problem beheben, indem ich das fehlerhafte Plugin modifiziere?

Vermeiden Sie dies. Jedes Update überschreibt Ihre Änderungen. Versuchen Sie stattdessen: (1) eine Fehlerbehebung in einem benutzerdefinierten Plugin/MU-Plugin, (2) eine Meldung des Fehlers an den Entwickler, (3) den Wechsel zu einem anderen Plugin, falls kein Support verfügbar ist.

Ich habe den Code korrigiert, aber es hat sich nichts geändert.

Leeren Sie die Caches (Plugin, Server, Browser). Falls es sich um JavaScript auf Administratorebene handelt, erhöhen Sie die Versionsnummer in … wp_enqueue_script()Prüfen Sie außerdem, ob Sie die richtige Datei geändert haben (Child-Theme vs. Parent-Theme).

„Tut mir leid, Sie sind nicht autorisiert…“, obwohl ich Administrator bin.

Dies tritt auf, wenn ein Rollen-/Sicherheits-Plugin die Berechtigungen geändert hat oder wenn ein benutzerdefinierter Personentyp (CPT) inkonsistente Berechtigungen aufweist. Deaktivieren Sie vorübergehend das Rollen-Plugin und korrigieren Sie anschließend die CPT-Deklaration (Lösung 1).

Die Artikelliste ist leer, aber im Frontend werden weiterhin Beiträge angezeigt.

Ein Haken pre_get_posts Alternativ kann ein Einschränkungs-Plugin die Anfrage nur im Administratormodus modifizieren. Suchen Sie nach einem Code-Snippet, das dies erzwingt. post_status, authoroder posts_per_page ohne Schutzmaßnahmen is_admin().

Wie bringt man ein Langzeitpflaster am besten an?

Un Mu-Plugin Soll die Korrektur auch bei einem Theme-Wechsel aktiv bleiben, verwenden Sie ein standardmäßiges benutzerdefiniertes Plugin. Vermeiden Sie es, sich bei der Administrationslogik auf ein Theme zu verlassen.

Wann sollte ich meinen Hosting-Anbieter kontaktieren?

Wenn Sie 500-Fehler ohne Fehlermeldung sehen debug.logEs könnten auch Berechtigungs- oder OPcache-Probleme vorliegen, oder PHP ist zu alt und lässt sich nicht aktualisieren. Geben Sie ihm den genauen Zeitpunkt des Tests und die URL an. /wp-admin/edit.php um mit Serverprotokollen zu korrelieren.