Поправка на грешка v3.1.1 в статиите на wp-admin

Ако вече сте кликнали върху Cтатии в wp-admin и всичко замръзва със странна грешка като „v3.1.1 не успява да отвори wp-admin 'articles'…“, вероятно имате конфликт между плъгин (версия 3.1.1), фрагмент и страницата със списъка с публикации (edit.php).

Проблемът

Точното съобщение варира в зависимост от плъгина, сървъра и езика, но следа, която често започва така (в бял екран(500 страници или PHP лог):

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.

Къде се появява:

Само за администратори чрез отваряне Статии> Всички статии (Типичен URL адрес: /wp-admin/edit.php), понякога също Прибавям (URL адрес: /wp-admin/post-new.php).
Понякога в AJAX : L 'ECRAN зареждане, след което действие (филтър, търсене, бързо редактиране) задейства грешка.
По-рядко в REST API Ако плъгин промени заявката за публикуване чрез REST, това може да повлияе и на Gutenberg.

Типични обстоятелства, които съм наблюдавал при отстраняване на неизправности:

Веднага след актуализация на плъгина v3.1.1 (числото „3.1.1“ почти винаги е това на плъгин, а не на WordPress).
След добавяне на фрагмент „за преименуване на публикации в статии“, намерен в стар урок.
След активиране на SEO/пренасочващ/сигурност плъгин, който засяга възможностите или администраторското меню.
На сайтове, използващи Divi 5, Elementor или Avada: тези конструктори не се провалят директно edit.php, но те често съществуват едновременно с „фрагменти“ и плъгини, които го нарушават.

За кого е това ръководство? Ако сте начинаещ, ще можете да разберете Коя тухла чупи екрана? Статиивъзвърнете достъпа до администраторския панел и приложете чиста корекция към WordPress 6.9.4 (април 2026 г.) и PHP 8.1 +.

Бързо обобщение

Менюто Cтатии сочи към /wp-admin/edit.phpАко тази страница се срине, това почти винаги е защото... администратор на кука (действие/филтър) на плъгин или фрагмент.
Започнете с активиране WP_DEBUG_LOG и / или Здравен преглед да изолира дефектния плъгин, без да нарушава работата на публичния сайт.
Често срещан случай: неправилно деклариран CPT код „артикули“ (register_post_type()) с непоследователни възможности където слъг което влиза в конфликт.
След корекция: запазете отново постоянните връзки и изчистете кеша (плъгин/сървър/браузър).
Ако вече нямате достъп до wp-admin: деактивирайте плъгина чрез FTP (преименувайте папката) или WP-CLI.

Симптомите

Ето какво можете да наблюдавате, от най-честите до най-подвеждащите:

екран Блан кликване върху Cтатии, понякога с „Критична грешка“.
500 грешка само на /wp-admin/edit.php (другите администраторски страници работят).
„За съжаление, нямате право на достъп до тази страница.“ докато сте администратор.
Празен списък със статии (0 резултата), но съществуват статии.
Неработещи филтри/търсене (Страницата се зарежда, след което се срива при сортиране по автор/категория).
Бързо редактиране (Бързо редактиране), което вече не се отваря или работи безкрайно (често проблем с AJAX).
Конзола на браузъра (F12): JS грешки на edit.php (често свързано със скрипт, инжектиран от плъгин).

Признаци за конфликт между плъгин/тема:

Проблемът изчезва, ако деактивирате „наскоро актуализиран“ плъгин.
Проблемът се появява само за определени роли (редактор, автор): подозрение относно възможности.
Проблемът се появява след поставяне на „фрагмент“ в functions.php (дъщерна тема) или плъгин за фрагменти.

Бърза диагноза: ако /wp-admin/edit.php?post_type=page (Страници) работи, но /wp-admin/edit.php (Публикации) прекъсвания, често си имаме работа с код, който е насочен специално към post или менюто „Статии“.

Защо се случва това?

Версия за начинаещи: екранът Cтатии Това е стандартна администраторска страница. Много плъгини „подобряват“ тази страница (колони, филтри, сортиране, ограничения на ролите, статистика). Ако плъгин (или фрагмент) допусне PHP/JS грешка, това е страницата, която се срива.

Ето какво се случва зад кулисите: WordPress се зарежда wp-admin/edit.php, изгражда списъчна заявка (WP_Query), след което изпълнява серия от кукиКуката е точка на удължаване. действие изпълнява код в даден момент, a Филтър променя стойност (напр. заявката, колоните, HTML). Ако филтър върне неправилен тип (напр. null (вместо масив), PHP 8.1+ е по-малко разрешителен и може да задейства Тип грешка.

Вероятни причини (от най-честите към най-редките):

Плъгинът v3.1.1 е бъгав което добавя колони/филтри към списъка с публикации и задейства фатална грешка.
Стар фрагмент (преди PHP 8 / предмодерни версии на WordPress), който използва неподходяща кука или ненатоварена функция.
„статии“ на CPT регистрирано със slug/възможности, което е в конфликт с „post“ (Native Articles) и нарушава разрешенията.
Конфликт REST/презаписване след миграция: постоянните връзки не са регенерирани, правилата за пренаписване са остарели.
Агресивен кеш (кешът на администратора е изключително рядък, но е възможен чрез неправилно конфигуриран обратен прокси) или JS минификация, която нарушава администраторския интерфейс.
Проблем със сървъра : PHP паметта е твърде ниска, OPcache е повреден, разрешенията за достъп до файлове или PHP < 8.1.

Забележка „v3.1.1“: WordPress 6.9.4 няма „v3.1.1“. Ако видите „v3.1.1“, това почти винаги е версията на плъгин (или тема). Процесът на диагностика включва идентифициране на това кой е.

Предварителни изисквания преди започване

защита : база данни + файлове. Не тествайте „на случаен принцип“ в продукция.
Тестова среда ако е възможно (подготовка). Често съм виждал просто липсваща точка и запетая да блокира целия администраторски интерфейс.
Версии WordPress 6.9.4 и PHP 8.1+ (в идеалния случай 8.2/8.3, ако вашият хостинг доставчик го позволява). Регистрирайте се Инструменти > Състояние на сайта.
Инструменти :
- Монитор на заявките (вижте грешки, заявки, куки).
- Проверка на състоянието и отстраняване на неизправности (режим на отстраняване на неизправности без да се засягат посетителите).
- Достъп до сървърни логове (или поне wp-content/debug.log).

Активиране на лог файлове на WordPress (в wp-config.php(над „спиране на редактирането“):

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

Официална справка: Отстраняване на грешки в WordPress.

Риск за сигурността Никога не показвайте PHP грешки на екрана в производствения режим. Следата на стека може да разкрие пътища, версии и понякога тайни.

Решение 1: Поправете CPT „статии“ (slug/възможности), които нарушават администраторския екран

Това се случва, когато някой иска да „създаде тип съдържание „Статии“, когато WordPress вече нарича нативните публикации „Статии“ (post). Резултат: объркващи етикети, дублирани менюта и понякога екран „Нямате право да…“ или срив на страницата, ако плъгинът очаква post но получава друг post_type.

Концепции :

CPT = Персонализиран тип публикация (персонализиран тип съдържание), деклариран чрез register_post_type().
Слъг = URL идентификатор (напр. article), използва се в постоянни връзки и понякога в администраторския панел.
Възможности = разрешения (напр. edit_posts, edit_pagesАко са неправилно картографирани, администраторът отказва достъп.

Кога да подозирате тази причина

Имате меню „Статии“, което не отваря обичайния списък с публикации.
Виждате URL адрес от типа /wp-admin/edit.php?post_type=articles.
Проблемът започна след добавянето на фрагмент „register_post_type('articles', …)“.

Къде да се коригира

Правилното място: малък персонализиран плъгин (препоръчително) или mu-плъгин (изисква се плъгин), ако искате да сте сигурни, че се зарежда, дори ако темата се промени.

Не поставяйте това в плъгин за фрагменти. Ако сте в режим на отстраняване на неизправности: ако плъгинът за фрагменти се повреди, губите достъп.
Ако трябва да го направите бързо: детска тема functions.php, но е по-крехко.

Код ПРЕДИ (счупен)

Реалистичен пример, с който често се сблъсквам (неясен текст, наречен „articles“), непоследователни възможности и колизия на етикети):

<?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,
	] );
} );

Защо се чупи: с capability_type => 'page' et map_meta_cap => falseСъздавате тип, който се държи като страници за разрешения, но без правилно съпоставяне. В зависимост от ролите и плъгините за сигурност, достъпът до списъка може да бъде отказан или да причини грешки, когато WordPress изчислява ограниченията.

Код СЛЕД (коригиран)

Цел: да се избегне конфликт със „Статии“ (публикации в оригинала) и да се осигурят последователни разрешения. Препоръчвам:

Недвусмислен пълзящ код и идентификатор (напр. mag_article ou ressource).
Изрични етикети (напр. „Ресурси“).
Възможностите са правилно картографирани чрез 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 );

Защо се коригира

Избягвате психическия и технически сблъсък със „Статии“ (публикации, генерирани от оригинала).
WordPress знае как да изчислява разрешенията „като публикация“ (стандартно), което значително намалява конфликтите с плъгините за роли/сигурност.
CPT е съвместим с REST/Gutenberg (show_in_rest), което избягва странно поведение в редактора.

Важна стъпка след тази корекция

отивам Настройки> Постоянни връзки и щракнете Enregistrer (без да се променя нищо). Това принуждава WordPress да генерира отново правилата за пренаписване.

Официален документ: register_post_type().

Решение 2: Поправка на пренаписвания, REST и постоянни връзки след актуализация

Този сценарий е често срещан след:

Миграция на уебсайтове (промяна на URL адреси),
Активиране/деактивиране на плъгин, който създава CPT-ове/таксономии,
Актуализация „v3.1.1“ на плъгин, който променя неговите slugs,
възстановяване на частично резервно копие.

Това не винаги причинява фатална PHP грешка. Понякога екранът „Статии“ се отваря, но определени филтри или действия правят заявки, които се провалят (REST/AJAX) и интерфейсът изглежда „счупен“.

Бърза диагностика (не се изисква код)

тест /wp-admin/edit.php puis /wp-admin/edit.php?post_status=trash.
Отворете конзолата на браузъра (F12) и погледнете раздела Мрежа: извиквания към /wp-json/ в 404/401/500?
отивам Инструменти > Състояние на сайта и проверете препоръките (REST API, цикли и др.).

Корекция 1: Почистване на постоянните връзки (UI)

Най-безопасният вариант: Настройки> Постоянни връзки > Enregistrer.

Корекция 2: Флъшване чрез WP-CLI (ако администраторският интерфейс е нестабилен)

Ако имате WP-CLI (често на VPS/управляван хостинг), изпълнете:

wp rewrite flush --hard

Справка за WP-CLI: wp пренаписване на флъш.

ПРЕДИ код (счупен): пускане на неправилното място

Виждал съм този фрагмент да причинява забавяния, прекъсвания и дори непостоянно поведение в администраторски режим:

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

Код СЛЕД (коригиран): изплакване само при активиране

Поставете този код в персонализирани добавки (напр.: /wp-content/plugins/mon-fix/mon-fix.php), след което го активирайте. След това можете да го запазите (без постоянно изтриване) или да го изтриете.

<?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();
} );

Защо се коригира

Елиминирате анти-модел: flush_rewrite_rules() не трябва да обръщате всяка страница.
Нулирате правилата след промяна на CPT/slug, което стабилизира някои администраторски екрани и свързаните с тях REST/AJAX крайни точки.

Официален документ: flush_rewrite_rules().

Решение 3: Открийте фатална PHP грешка на екрана „Статии“ (администраторски куки, колони, филтри)

Това е най-честата причина за грешката „v3.1.1 не успява да отвори статии в wp-admin…“. Плъгин (v3.1.1) или фрагмент добавя колона, променя заявката или филтрира редовете и задейства PHP грешка (TypeError, неопределена функция и др.).

Стъпка 1: Открийте точната грешка

отворено wp-content/debug.log след възпроизвеждане на грешката (щракнете върху Cтатии). Потърсете ред с път „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 ...

Ако нямате лог, инсталирайте Query Monitor и погледнете раздела „PHP грешки“ (ако страницата се зарежда само частично). Документация на Query Monitor: WordPress.org.

Стъпка 2: Изолиране без нарушаване на обществения обект (Проверка на състоянието)

с Проверка на състоянието и отстраняване на неизправности :

Активирайте режим за отстраняване на неизправности (само за вашата сесия).
тест CтатииАко работи: проблемът идва от плъгин/тема, която е била деактивирана в режим на отстраняване на неизправности.
Активирайте отново плъгините един по един, докато не възпроизведете срива.

Според моя опит, това е най-бързият начин да се идентифицира „плъгинът v3.1.1“, без да се прави сайтът недостъпен.

Типичен случай: филтър на колона, който връща грешен тип

Sur edit.phpМного кодове използват филтъра manage_posts_columns (или manage_edit-post_columns) за добавяне на колони. Класическа грешка в PHP 8+: връщане null вместо картина.

Код ПРЕДИ (счупен)

Реалистичен пример: плъгин/фрагмент иска да изтрие колона, но забравя да върне масива:

<?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 );

Възможен резултат: по-нататък WordPress (или друг плъгин) извършва array_merge() от $columns и получава null → Грешка в типа → Екран „Артикули извън ред“.

Код СЛЕД (коригиран)

Поставете тази корекция в персонализиран плъгин (или functions.php (на детска тема) след запазванеАко подозирате проблем с плъгин, коригирайте го в собствения си код и деактивирайте проблемния плъгин.

<?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 );

Защо се коригира

Филтър дреболия върне стойност. В противен случай WordPress извлича null.
Защитната мярка is_array() защитава ви, дори ако друг плъгин върне неправилен тип.

Официална документация за куките (действия/филтри): API на плъгина: Кукички.

Типичен случай: кука за „предварителна заявка“, която прекъсва списъка (pre_get_posts)

Друга класическа грешка: искате да филтрирате публикации в администраторския панел и променяте всички заявки, включително тези в администраторския списък. Страницата „Статии“ става празна, бавна или се срива, ако заявката стане невалидна.

Код ПРЕДИ (счупен)

<?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' );

} );

Код СЛЕД (коригиран)

Цел: да се промени само основната заявка за front-end, а не административният панел. Поставете я в персонализиран плъгин или дъщерна тема.

<?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 );

Официален документ: pre_get_posts.

Типичен случай: JS скрипт, инжектиран в администраторския панел, който нарушава работата на edit.php

Ако конзолата показва JS грешки, потърсете плъгин, който поставя скрипт в опашката в администраторския панел, понякога минифициран, понякога зависим от липсваща библиотека.

Код ПРЕДИ (счупен)

<?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
	);
} );

Код СЛЕД (коригиран)

Насочваме се само към екрана „Статии“ (публикации) и декларираме разумни зависимости.

<?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 );

Официален документ: admin_enqueue_scripts et wp_enqueue_script ().

Проверки след корекция

Презареждане /wp-admin/edit.php в режим на частно сърфиране (избягва агресивен кеш).
Опитай го:
- Търсене на статия
- Филтриране по категория
- Бързо редактиране
- Кошница
Проверка wp-content/debug.log : вече няма „фатална грешка“ при щракване.
Ако имате плъгин за кеширане: изчистете кеша на плъгина + кеша на сървъра (ако е приложимо) + кеша на браузъра.

Ако грешката е конфликт на разрешения/възможности: тествайте с акаунт на „Редактор“ (не само с администраторски акаунт). Много сайтове „изглеждат“ поправени за администраторски потребители, но остават неработещи за по-ниски роли.

Ако това все още не работи

Процедура за отстраняване на неизправности, която прилагам, когато екранът „Статии“ остава недостъпен.

1) Деактивирайте дефектния плъгин без wp-admin (FTP)

Свържете се чрез FTP/SFTP.
отивам /wp-content/plugins/.
Преименувайте папката на подозрителния плъгин (напр. mon-plugin → mon-plugin.off).
Обновете wp-admin.

Ако не знаете кой е: преименувайте го временно plugins en plugins.off (деактивира всички плъгини), след което ги активирайте отново един по един.

2) Проверете PHP паметта

Голям списък със статии (много колони, заявки, статистики) може да доведе до рязко увеличаване на използването на паметта. Потърсете грешката „Разрешен размер на паметта…“.

Можете да увеличите лимита на WordPress (ако вашият доставчик на хостинг услуги го позволява):

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

Справка: wp-config.php (константи).

3) Проверете версията на PHP

Ако използвате PHP 7.4/8.0, някои по-нови плъгини (или WordPress 6.9.4) може да се държат различно. Стремете се към PHP минимум 8.1.

Документ: Поддържани версии на PHP.

4) Проверете за REST/AJAX грешки

отворено /wp-json/ : трябва да отговаря в JSON (не HTML 404).
Проверете дали плъгин за сигурност го блокира. /wp-json/ ou admin-ajax.php.

REST документ: Ръководство за WordPress REST API.

5) Монитор на заявки: идентифициране на счупения hook/филтър

Ако страницата се зарежда само частично, Query Monitor може да ви покаже:

PHP грешки
бавни заявки
грешка в скриптове/стилове
задействани куки

6) Последна мярка: активирайте режим на възстановяване

WordPress има механизъм за „режим на възстановяване“, който се активира, когато плъгин предизвика фатална грешка в администраторския панел. Ако получите имейл, в който се казва „Вашият сайт има техническа грешка“, използвайте връзката за възстановяване, за да деактивирате проблемния плъгин.

Документ: Режим на възстановяване (поддръжка).

Често срещани капани и грешки

Диагностична диаграма

симптом	Вероятна причина	проверка	Решение
Критична грешка само в „Статии“	Плъгинът v3.1.1 добавя колони/филтри и растения	debug.log показва път в /plugins/...	Деактивиране/връщане на плъгина назад, отстраняване на проблема (Решение 3)
„За съжаление, не сте оторизирани…“	Неправилно съпоставени CPT възможности или плъгин за роли	Тествайте с администратор срещу редактор, проверете CPT	Коригиране на CPT/табели (Решение 1), преглед на плъгина за роли
Празен списък (0 елемента), но те съществуват	pre_get_posts променя администраторската заявка	Деактивиране на фрагмента, проверка на кода pre_get_posts	Добавяне на защитни мерки за is_admin/is_main_query (Решение 3)
Бързото редактиране не се отваря	Грешка при блокиране на JS администратор или admin-ajax	Конзола F12 + раздел „Мрежа“	Насочване към опашката, деактивиране на минифицирането, разрешаване на AJAX
Проблем след миграция	Пренапишете остарелите правила	Настройки > Постоянни връзки, тест /wp-json/	Изчистване на постоянните връзки (Решение 2)

Грешки, които виждам през цялото време

Копиране на кода на грешното място Поставянето на PHP фрагмент в поле „CSS“ в конструктора или в редактора на страници води до това, че нищо не работи или кодът се показва като обикновен текст.
Забравяне на точка и запетая в functions.php Една проста грешка блокира целия wp-admin достъп. Работете в тестова среда и поддържайте FTP достъп.
Използване на неподходяща кука Например, променете администраторската заявка чрез pre_get_posts без is_admin().
Объркване между акции и филтри Филтърът трябва да върне нещо. Действието не го прави. Тук грешка при връщане може да прекъсне „Статии“.
Кешът не е изчистен Коригирахте го, но браузърът показва старата версия на JS. Увеличете версията на скрипта и изчистете кеша.
Тестване в производство без резервно копие : в администраторския панел може да ви заключи.
Фрагмент, повреден от плъгин за фрагменти Ако плъгинът за фрагменти се срине, вече не можете лесно да го деактивирате. За поправки е за предпочитане mu-плъгин.
Код от стар урок Несъвместимо с PHP 8.1+ (TypeError, задължителни параметри и др.).

Вариант / алтернатива

Метод без код: връщане към версия „v3.1.1“

Ако сте установили, че „v3.1.1“ е версията на плъгин и грешката се е появила веднага след това:

Проверете страницата на плъгина на WordPress.org, за да видите дали има раздел Разширен изглед позволява изтегляне на предишна версия.
Или използвайте плъгин за връщане към предишни версии (напр. WP Rollback) с повишено внимание и само от надежден източник.

След това отворете заявка за поддръжка за плъгина с:

вашата версия на WordPress (6.9.4), PHP,
пълният дневник на грешките,
стъпките за възпроизвеждане.

Разширен метод: mu-plugin „bumpers“ за предотвратяване на фатални грешки в edit.php

Когато е необходимо спешно да стабилизирате администратор, можете да неутрализирате известен кук (например филтър на колона), като го замените със защитен код. Внимание: това е заобиколно решение. След това трябва да отстраните основния проблем.

Пример: идентифицирали сте филтър, който понякога връща nullНе можете да променяте плъгина (или не искате да докосвате кода му). Добавяте филтър в късен етап, който „поправя“:

<?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 );

Това не „поправя“ плъгина, но може да ви даде отново достъп до екрана, за да продължите диагностиката.

Избягвайте този проблем в бъдеще

Избягвайте да наричате CPT „статии“ Запазете „Статии“ за публикации, базирани на оригиналния текст. Наименувайте вашите CPT-та според тяхната бизнес роля (ресурси, проекти, рецепти...).
Без постоянно промиване : flush_rewrite_rules() само при активиране/деактивиране.
Защитен код на филтрите : валидиране на типовете (is_array, is_string) когато филтрирате стойности, използвани от други плъгини.
Систематично стадиране Преди основните актуализации на плъгините, версия 3.1.1 може да съдържа регресия на специфичен администраторски екран.
Следете за грешки пазя WP_DEBUG_LOG лесно активиране и настройване на ротация на лог файлове от страна на сървъра.
Плъгини и конструктори Divi 5, Elementor и Avada не предотвратяват тези корекции. Избягвайте обаче плъгини за производителност „всичко в едно“, които също така минимизират администраторската функционалност: това е класически източник на JS грешки. edit.php.

Ако разработвате: документирайте вашите hooks-и. Филтър, който не връща нищо, е бомба със закъснител, особено с PHP 8.1+.

ресурси

Често задавани въпроси

Как да разбера кой плъгин съответства на „v3.1.1“?

Regardez wp-content/debug.log пътят до дефектния файл почти винаги сочи към /wp-content/plugins/nom-du-plugin/Като алтернатива, използвайте „Проверка на състоянието“, като реактивирате плъгините един по един.

Нямам достъп до wp-admin, какво да правя?

Преименувайте папката на подозрителния плъгин чрез FTP/SFTP (или деактивирайте всички плъгини, като ги преименувате). /wp-content/pluginsСлед това се свържете отново и постепенно реактивирайте.

Може ли Divi 5 / Elementor / Avada да причини този бъг?

Те рядко го провокират директно върху edit.phpВъпреки това, добавка, плъгин за фрагменти или оптимизация (минификация), инсталирани „с конструктора“, могат да нарушат работата на администраторския интерфейс. Диагнозата остава същата: лог файлове + изолация на плъгина.

Защо грешката се появява само в „Статии“, а не другаде?

Тъй като много плъгини използват специфични куки, свързани със списъка с публикации (колони, сортиране, филтри, ограничения). Грешка в този код се задейства само при wp-admin/edit.php.

Мога ли да поправя това, като променя дефектния плъгин?

Избягвайте това. Всяка актуализация ще презапише промените ви. Вместо това, опитайте: (1) корекция в персонализиран плъгин/mu-плъгин, (2) докладване на грешката на разработчика, (3) преминаване към друг плъгин, ако поддръжката не е налична.

Коригирах кода, но нищо не се промени.

Изчистете кешовете (плъгин, сървър, браузър). Ако е JavaScript на администраторско ниво, увеличете версията в... wp_enqueue_script()Също така проверете дали сте променили правилния файл (дъщерна тема спрямо родителска тема).

„Съжалявам, не сте оторизирани...“, въпреки че съм администратор.

Това се случва, ако плъгин за роли/сигурност е променил възможностите или ако CPT има непоследователни възможности. Временно деактивирайте плъгина за роли, след което коригирайте декларацията на CPT (Решение 1).

Списъкът със статии е празен, но интерфейсът все още показва публикации.

Кука pre_get_posts Или плъгин за ограничения може да променя заявката само в администраторски режим. Потърсете фрагмент, който налага post_status, authorИли posts_per_page без предпазни мерки is_admin().

Кой е най-добрият начин за поставяне на трайна лепенка?

Un mu-плъгин Ако искате корекцията да остане активна, дори ако темата се промени, използвайте стандартен персонализиран плъгин. Избягвайте да разчитате на тема за администраторска логика.

Кога трябва да се свържа с моя доставчик на хостинг услуги?

Ако видите 500 грешки без следа в debug.log, или може да има проблеми с разрешенията/OPcache, или ако PHP е твърде стар и не можете да го промените. Дайте му точния час на теста и URL адреса /wp-admin/edit.php за съпоставяне със сървърните лог файлове.

Поправка на грешка v3.1.1 в статиите на wp-admin

Проблемът

Бързо обобщение

Симптомите

Защо се случва това?

Предварителни изисквания преди започване

Решение 1: Поправете CPT „статии“ (slug/възможности), които нарушават администраторския екран

Кога да подозирате тази причина

Къде да се коригира

Код ПРЕДИ (счупен)

Код СЛЕД (коригиран)

Защо се коригира

Важна стъпка след тази корекция

Решение 2: Поправка на пренаписвания, REST и постоянни връзки след актуализация

Бърза диагностика (не се изисква код)

Корекция 1: Почистване на постоянните връзки (UI)

Корекция 2: Флъшване чрез WP-CLI (ако администраторският интерфейс е нестабилен)

ПРЕДИ код (счупен): пускане на неправилното място

Код СЛЕД (коригиран): изплакване само при активиране

Защо се коригира

Решение 3: Открийте фатална PHP грешка на екрана „Статии“ (администраторски куки, колони, филтри)

Стъпка 1: Открийте точната грешка

Стъпка 2: Изолиране без нарушаване на обществения обект (Проверка на състоянието)

Типичен случай: филтър на колона, който връща грешен тип

Код ПРЕДИ (счупен)

Код СЛЕД (коригиран)

Защо се коригира

Типичен случай: кука за „предварителна заявка“, която прекъсва списъка (pre_get_posts)

Код ПРЕДИ (счупен)

Код СЛЕД (коригиран)

Типичен случай: JS скрипт, инжектиран в администраторския панел, който нарушава работата на edit.php

Код ПРЕДИ (счупен)

Код СЛЕД (коригиран)

Проверки след корекция

Ако това все още не работи

1) Деактивирайте дефектния плъгин без wp-admin (FTP)

2) Проверете PHP паметта

3) Проверете версията на PHP

4) Проверете за REST/AJAX грешки

5) Монитор на заявки: идентифициране на счупения hook/филтър

6) Последна мярка: активирайте режим на възстановяване

Често срещани капани и грешки

Диагностична диаграма

Грешки, които виждам през цялото време

Вариант / алтернатива

Метод без код: връщане към версия „v3.1.1“

Разширен метод: mu-plugin „bumpers“ за предотвратяване на фатални грешки в edit.php

Избягвайте този проблем в бъдеще

ресурси

Често задавани въпроси

Как да разбера кой плъгин съответства на „v3.1.1“?

Нямам достъп до wp-admin, какво да правя?

Може ли Divi 5 / Elementor / Avada да причини този бъг?

Защо грешката се появява само в „Статии“, а не другаде?

Мога ли да поправя това, като променя дефектния плъгин?

Коригирах кода, но нищо не се промени.

„Съжалявам, не сте оторизирани...“, въпреки че съм администратор.

Списъкът със статии е празен, но интерфейсът все още показва публикации.

Кой е най-добрият начин за поставяне на трайна лепенка?

Кога трябва да се свържа с моя доставчик на хостинг услуги?

Статии

Коментирай Отказване на отговора

Коментирай