Поправете фаталната грешка на SMTP POST в Настройки

by | WordPress

Ако вече сте кликнали върху Публикуване на SMTP → Настройки и това WordPress ще отговориш с бял екран или фатална грешкаИмате работа с типичен случай на грешка, задействана само в...администратор, когато страницата с настройки се зареди.

Проблемът

Основният симптом: отварянето на страницата с настройки на Post SMTP причинява фатална PHP грешка. Често сайтът остава достъпен за посетителите, но администраторският интерфейс се срива на тази конкретна страница.

Ето някои реалистични съобщения за грешки, които съм виждал в лог файловете на сайтове на WordPress 6.9.x (точният текст варира в зависимост от доставчика на хостинг услуги и режима на отстраняване на грешки):

Fatal error: Uncaught TypeError: array_merge(): Argument #2 must be of type array, string given
in /wp-content/plugins/post-smtp/Postman/PostmanViewController.php:1234
Stack trace:
#0 ...
Fatal error: Uncaught Error: Call to undefined function wp_get_environment_type()
in /wp-content/plugins/post-smtp/Postman/Postman.php:210
Fatal error: Uncaught Error: Class "VendorPackageSomeClass" not found
in /wp-content/plugins/post-smtp/vendor/.../autoload.php:...
Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes)
in /wp-content/plugins/post-smtp/.../Settings.php on line ...

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

  • Admin особено на /wp-admin/admin.php?page=пощальон (или вариант).
  • AJAX Понякога, по време на зареждане на раздели, ако страницата с настройки извика админ-ajax.php.
  • REST API : по-рядко срещано, но някои съвременни плъгини зареждат данни чрез /wp-json/.

Типични обстоятелства:

  • Юсте след актуализация от Post SMTP или от WordPress (тук WordPress 6.9.4).
  • След промяна на PHP версия (преход към 8.1/8.2/8.3), което прави „тихите“ грешки по-строги (TypeError).
  • След активиране на плъгин за сигурност/кеширане, който променя администраторския файл (минификация, блокиране на REST/AJAX, WAF правила).

За кого е предназначено: Ако сте начинаещ блогър, ще се научите да извличане на истинската следа, изолиране на конфликтаСлед това приложете безопасно решение (без да докосвате ядрото на WordPress). Накрая ще знаете какво да предоставите на поддръжката (чисти лог файлове, предприети стъпки, версии).

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

  • Активирайте режим на чиста диагностика: WP_DEBUG + логи извличане на точната следа на грешката.
  • Тествайте страницата с настройки с Здравен преглед (режим на отстраняване на неизправности), за да потвърдите конфликт между плъгин/тема.
  • Много катастрофи произтичат отОпции за SMTP за повредени публикации след актуализация: целенасочено нулиране чрез WP-CLI или база данни.
  • Грешките „Класът не е намерен“ често сочат към доставчик/автоматично зареждане Незавършено: преинсталирайте плъгина (чисто), а не правете сляпа кръпка.
  • Грешките „Изчерпана памет“ се разрешават от страна на сървъра (PHP ограничение) + намаляване на претоварването на администратора (неправилно конфигуриран кеш/минимизиране).

Симптомите

В зависимост от сървъра, може да видите:

  • 500 грешка като отворите Post SMTP → Настройки.
  • Бял екран (WSOD) само на тази администраторска страница.
  • Съобщение "На този уебсайт възникна критична грешка„+ Имейл от WordPress с откъс от трасиране.“
  • Публикуване на SMTP раздели/секции, които не се зареждат, с грешки в конзолата (AJAX/REST блокиран).
  • Невъзможност за запазване на настройките (невалидни няма, разрешения или фатална грешка при изпращане).

Признаци, които сочат към конкретна причина:

  • Фронт-ендът работи, но администраторският интерфейс се срива: често администратор на кука злоупотреба или конфликт с плъгин „admin optimizer“.
  • Работи локално, но не и в продукцията: често PHP версия, mémoireИли WAF (приложна защитна стена).
  • Счупи се „веднага след актуализацията“: несъвместими опции, доставчик на автозареждаща програма, кеш на OPcache.

Бърза диагностична диаграма

симптом Вероятна причина проверка Решение
Фатална грешка „array_merge()… даден низ“ Опцията за SMTP за публикуване се очаква в масива, но е съхранена като низ. Гледайте трасирането + проверете опцията в базата данни Решение 3 (нулиране/конвертиране на опцията)
„Класът не е намерен … vendor/autoload.php“ Плъгинът е инсталиран неправилно / доставчикът е непълен Сравнете папката с плъгина, след което го изтеглете отново от wordpress.org Преинсталирайте плъгина чисто (и изчистете OPcache)
Грешка 500 без подробности Дневниците са деактивирани / WAF / кеш Активиране на WP_DEBUG_LOG + сървърни лог файлове Решение 1 + деактивиране на кеша/администраторското минифициране
Празна страница с настройки, грешка в JS конзолата JS (минификация) или REST/AJAX конфликт е блокиран Конзола на браузъра + раздел „Мрежа“ Деактивирайте минифицирането на администратора, позволете /wp-json/
„Разрешеният размер на паметта е изчерпан“ Недостатъчно PHP памет за администратора error_log + Състояние на сайта Увеличаване на memory_limit (сървър) + ограничаване на ресурсоемките плъгини

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

Версия за начинаещи: Когато отворите страница с настройки, WordPress зарежда плъгина, неговите PHP файлове, неговите скриптове и след това изпълнява кода му, за да покаже формата. Дори само едно парче код срещне неочаквани данни (напр. опция, съхранена в грешен формат), PHP спира всичко с фатална грешка.

Ето какво се случва зад кулисите (по-техническа версия):

  • WordPress зарежда плъгините, след което ги задейства кукиКуката е „точка на прикрепване“, където плъгинът може да изпълнява код. Има мерки (изпълнявам) и филтри (промяна на стойност).
  • Страницата с настройки преминава през администраторско_меню (добавяне на менюто), след което чрез зареждане на екрана (често натоварване-$ hook_suffix), след това дисплеят.
  • Четения на SMTP следи опции (съхранява се в базата данни чрез get_option()Ако типът не е очакваният (низ вместо масив), PHP 8.1+ задейства по-строги TypeErrors.

Причини, подредени от най-честите към най-редките (в WordPress 6.9.4 / PHP 8.1+):

  1. Повредена или остаряла SMTP опция за публикуване от по-стара версия (непълна миграция).
  2. конфликт на плъгини (кеш/минимизиране/оптимизатор на администратор/сигурност), което нарушава AJAX/REST или променя реда на зареждане.
  3. Непълна инсталация плъгин (липсваща папка на доставчика, отрязани файлове след актуализация).
  4. Неподдържана версия на PHP (твърде старо) или обратното, по-стриктно поведение (TypeError), което разкрива скрита грешка.
  5. Ограничение на паметта твърде ниско ниво на администраторските права, особено на големи сайтове (WooCommerce, конструктори и др.).

Съвместимост с конструктора на страници: Divi 5, Elementor и Avada обикновено нямат нищо общо със страницата с настройки на плъгина. Според моя опит обаче, те допринасят косвено чрез добавки за „оптимизация за администратор“ или глобални скриптове, инжектирани навсякъде. Затова ще тестваме и със стандартна тема, използвайки Health Check.

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

  • защита Завършено (файлове + база данни). Не извършвайте тези операции директно в продукцията без предпазна мрежа.
  • Достъп до:
    • FTP/SFTP или файлов мениджър
    • файлът wp-config.php
    • В идеалния случай използвайте WP-CLI (по избор, но е много практично).
  • Препоръчителни версии: WordPress 6.9.4 et PHP 8.1 +(Ако използвате PHP 7.4/8.0, започнете с мигриране: много съвременни инструменти вече не тестват тези версии.)
  • Полезни инструменти:

Основен риск : докосване на грешен файл (напр. директна промяна на плъгин) и загуба на промените ви при следващата актуализация. За фрагменти използвайте mu-плъгин („задължителен“ плъгин) или персонализиран плъгин.

Решение 1: Изолиране на фаталната грешка и получаване на трасирането (WP_DEBUG, логове, Query Monitor)

Когато някой ми каже „Настройките на Post SMTP причиняват фатална грешка“, винаги започвам с едно и също нещо: получаване точната следаБез това ще деактивирате плъгините на случаен принцип.

Стъпка 1 — Активирайте чисто PHP регистриране (без показване на грешки на посетителите)

отворено wp-config.php (в главната директория на WordPress) и добавете/коригирайте тези константи. Поставете ги Avant редът „Това е всичко, спрете да редактирате!“

ПРЕДИ код (често срещано сред начинаещите: дебъгването липсва или се показва на екрана):

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

define('WP_DEBUG', false);

// ...

AFTER код (препоръчва се за диагностика в производствена среда без изтичане на данни):

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

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

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

// ...

Защо това помага: WordPress ще запише грешките в wp-content/debug.logТова е файлът, който ще прочетете след възпроизвеждане на срива.

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

Стъпка 2 — Възпроизвеждане на грешката и извличане на следата

  1. Отворете администраторския панел, щракнете върху SMTP на публикацията → Настройки (или еквивалентен запис).
  2. Ако екранът е бял: презаредете веднъж (понякога логът се записва при второто натискане).
  3. отворено wp-content/debug.log и копирай:
    • редът „Фатална грешка…“
    • 10–30-те реда от трасирането на стека

Si debug.log не се пълни:

  • Вашият доставчик на хостинг услуги може да е деактивирал достъпа за запис. Проверете разрешенията на wp-content.
  • Прегледайте лог файловете на сървъра (Apache/Nginx) чрез панела.
  • Ако използвате агресивен кеш на сървъра, изчистете го.

Стъпка 3 — Потвърждаване на конфликт без нарушаване на публичния сайт (Проверка на състоянието)

Инсталиране/активиране Здравен преглед, Тогава :

  1. Инструменти → Състояние на сайта → раздел помощ
  2. Активирайте режим за отстраняване на неизправности (вашите посетители няма да бъдат засегнати).
  3. Тестов пост SMTP → Настройки.
  4. Ако работи в режим на отстраняване на неизправности: активирайте отново плъгините един по един в този режим, докато грешката се възпроизведе.

Според моя опит, най-честите конфликти са:

  • плъгини за минифициране, които засягат администратора
  • плъгини за сигурност, които блокират admin-ajax.php ou /wp-json/
  • плъгини за фрагменти, които зареждат счупен код на admin_init

Стъпка 4 — Проверете конзолата на браузъра (ако страницата се зарежда само наполовина)

Ако виждате интерфейса на Post SMTP, но с празни раздели:

  • Отворете DevTools → Конзола: потърсете JS грешки
  • Отворете DevTools → Мрежа: филтър admin-ajax.php et /wp-json/

Ако видите грешки 403/401 в REST, това често се дължи на плъгин за сигурност или правила на сървъра. Вижте документацията за REST API: Наръчник за REST API

Решение 2: Поправете страница с настройки, която се поврежда поради неправилно зареден администраторски hook

Това се случва, когато фаталната грешка не произхожда „директно“ от SMTP публикацията, а от фрагмент или плъгин, работещ върху нея. toutes администраторските страници… и което се проваля само на страницата „Post SMTP“ (защото на този екран не съществува очаквана променлива).

Типично: код за „персонализиране от администратор“, който приема, че $_GET['page'] винаги е дефинирана или извиква функция твърде рано.

Бърза диагноза

  • В debug.logследата сочи към functions.php (тема), плъгин за фрагменти или плъгин за „персонализиране от администратора“.
  • В режим „Проверка на състоянието“ (отстраняване на неизправности), ако се върнете към Twenty Twenty-Five (или стандартна тема) и тя работи, проблемът е във вашата тема или в администраторско разширение.

Пример от реалния свят: прекалено агресивен admin_init hook (ПРЕДИ → СЛЕД)

Срок: действие = кука, която изпълнява функция. Тук admin_init работи при всяко администраторско зареждане.

Къде се намира този код? често в functions.php от темата (понякога дъщерна тема) или в плъгин за фрагменти. Не променяйте родителската тема. Работете в дъщерна тема или по-добре: mu-плъгин.

ПРЕДИ код (счупен: приема, че $_GET['page'] (съществува и манипулира опции без проверка):

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

Какво се чупи: ако get_option('postman_options') връща низ (повредена опция) или falseдостъп $settings['force_smtp'] причинява фатална грешка в PHP 8.1+.

Код СЛЕД (коригирано: проверяваме контекста + типа и не докосваме опциите за четене/запис при всяко зареждане):

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

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

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

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

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

Защо това го поправя: Предотвратявате „пробиване“ на екрана Post SMTP от код на трети страни чрез достъп до невалидирани данни. И най-вече, избягвате записване в базата данни при всяко администраторско зареждане, което е друг източник на грешки.

Създайте mu-плъгина (препоръчително)

Създаване на папка wp-content/mu-plugins ако не съществува, тогава файл postman-admin-guard.php вътре. MU-плъгините се зареждат автоматично от WordPress.

Официален документ: Задължителни плъгини

Решение 3: Почистване на повредена/несъвместима опция след актуализация (WP-CLI / база данни)

Това е най-рентабилната причина за отстраняване, когато проследяването споменава грешки от следния тип:

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

Сценарият: Post SMTP очаква опция, сериализирана като масив, но базата данни съдържа низ, понякога поради:

  • прекъсната миграция
  • плъгин за кеширане на обекти (Redis/Memcached), който е обслужвал остаряла стойност
  • откъс, който направи update_option() с лоша структура

Стъпка 1 — Определете въпросната опция

В трасирането намерете точното име на опцията. Имената варират в зависимост от версията, но често ще видите нещо подобно на:

  • postman_options
  • post_smtp_settings
  • postman_plugin_options

Ако не го виждаш, виж вътре debug.log линия с get_option или файл „Настройки/Опции“.

Вариант A — Чисто нулиране чрез WP-CLI (най-безопасният вариант)

Ако имате WP-CLI:

1) Избройте възможните варианти:

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

2) Проверете опция (за да проверите дали е низ, а не сериализиран масив):

wp option get postman_options

3) Запазете опцията, преди да я изтриете (много полезно, ако трябва да я възстановите):

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

4) Изтрийте повредената опция (Post SMTP ще я пресъздаде със стойности по подразбиране):

wp option delete postman_options

Документация на WP-CLI (препратка): Команда за опции на WP-CLI

Защо е ефективно Премахвате токсичните данни, които задействат грешката. Плъгинът се рестартира с чиста конфигурация и страницата с настройки се показва отново.

Вариант Б — Нулиране чрез phpMyAdmin (ако нямате WP-CLI)

Запазете базата данни Преди. След това:

  1. Отвори масата wp_options (префиксът може да е различен).
  2. Потърсете опцията (напр. postman_options).
  3. Копирайте стойността му в текстов файл (резервно копие).
  4. Изтрийте реда (или променете option_value en a:0:{} (ако знаеш какво правиш).

Забележка: заменете с a:0:{} (Сериализиран празен масив) може да избегне някои работни процеси при инсталиране, но не е универсален. Премахването често е по-чисто.

Вариант C — Временен пач за „оцеляване“ и достъп до администраторския панел

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

Къде да се залепи : /wp-content/mu-plugins/postman-option-safety.php

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

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

	$value = get_option($option_name, null);

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

Защо работи: SMTP вече няма да среща „невъзможна“ стойност и ще може да възстанови настройките си по подразбиране. Риск: Ще загубите SMTP конфигурацията си (оттук е важно предварителното архивиране чрез WP-CLI/DB).

Препратка към get_option() : get_option ()

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

След като причината е отстранена, проверете с прост контролен списък:

  1. отворено Публикуване на SMTP → Настройки Страницата трябва да се показва без грешки.
  2. отворено wp-content/debug.log : край на „фаталната грешка“.
  3. Изпратете тестов имейл от Post SMTP (или от формуляр за контакт).
  4. Проверете дали изпращането работи и чрез WP-Cron ако имате планирани имейли (бюлетини, WooCommerce).
  5. След това деактивирайте режима за отстраняване на грешки (или го оставете включен). WP_DEBUG_LOG активен само в тестова среда).

Ако имате кеш (плъгин, сървър, CDN), изчистете го:

  • плъгин за кеширане (кеш на страница)
  • кеш на сървъра (Varnish / Nginx microcache)
  • OPcache (ако вашият хостинг доставчик го позволява) — много полезен след преинсталиране на плъгина

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

Когато страницата с настройки продължава да се срива, следвам фиксирана процедура. Това избягва ненужното обсъждане на различни неща.

1) Преинсталирайте Post SMTP чисто (без да губите конфигурацията, ако е възможно)

Непълна инсталация (липсващ доставчик) причинява грешки „Класът не е намерен“. Процедура:

  1. Запазете опциите (експортирайте JSON от WP-CLI, ако е възможно).
  2. Деактивирайте SMTP протокола за изпращане.
  3. Изтриване на папката /wp-content/plugins/post-smtp/ (само този плъгин).
  4. Преинсталирайте от WordPress.org (SMTP публикация) (не от съмнителен ZIP файл).
  5. Активирайте отново и тествайте страницата с настройки.

2) Потвърдете версията и разширенията на PHP

  • В Инструменти → Състояние на сайта, проверете PHP. Цел 8.1 +.
  • Проверете разширенията: openssl, mbstring, curlPost SMTP често зависи от него косвено.

PHP документация (напр. OpenSSL): PHP OpenSSL

3) Временно деактивирайте плъгините „администратор“ и „сигурност“

В режим „Проверка на състоянието“ (режим на отстраняване на неизправности) деактивирайте:

  • минифициране/конциране на JS/CSS (особено ако това засяга администраторската област)
  • плъгини за сигурност, които филтрират REST/AJAX
  • плъгини за фрагменти (достатъчен е един счупен фрагмент)

Тествайте всеки път, като отидете на Post SMTP → Настройки. Когато проблемът се върне, значи сте открили виновника.

4) Проверете ограниченията на паметта

Ако следата споменава памет:

  • увеличаване memory_limit от страна на PHP (хостинг панел), а не чрез WordPress.
  • Избягвайте да разчитате на define('WP_MEMORY_LIMIT', ...) ако вашият доставчик на хостинг услуги налага по-нисък лимит.

WordPress справка (памет): WP_MEMORY_LIMIT

5) Проверете правилата за постоянни връзки / пренаписване (рядко срещано тук, но виждано преди)

Ако Post SMTP зареди вътрешни крайни точки и върне грешка 404:

  1. Настройки → Постоянни връзки → Запазване (без промяна)

Това принуждава WordPress да генерира отново правилата за пренаписване. Справка: flush_rewrite_rules() (да не се извиква на всяка страница).

6) Ако видите срив на определена кука

Често срещан проблем: объркване между мерки et филтриФилтърът трябва да връщане Стойност. Акцията не връща нищо.

Пример ПРЕДИ (неработещ: използва add_filter, но не връща нищо):

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

Пример СЛЕД (коригирано):

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

Документни куки: API на плъгина: Кукички

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

Симптом / грешка Вероятна причина Препоръчително решение
Поставяте фрагмента в грешен файл Код, поставен в родителската тема или в плъгин, който се самообновява Използвайте a mu-плъгин или персонализиран плъгин, никога основната, никога родителската тема
Фатална грешка след добавяне на код: „неочакван токен“ Забравена точка и запетая, допълнителна къдрава скоба, неправилно затворен PHP таг Върнете промените чрез FTP, коригирайте синтаксиса и ги валидирайте с редактор.
Дневникът остава празен Разрешения, WP_DEBUG е неправилно поставен, хостинг доставчикът блокира достъпа за запис Проверете местоположението в wp-config.php + сървърни логове
Работи в режим на отстраняване на неизправности „Проверка на състоянието“, но не „нормално“. Конфликт между плъгини или теми Активирайте ги отново един по един в режим на отстраняване на неизправности, докато не откриете виновника.
Страницата с настройки се зарежда, но разделите остават празни. REST/AJAX блокиран, минимизиране от администратора Конзола + Мрежа, деактивиране на минифициране на администратора, разрешаване /wp-json/
Грешка „Изчерпан е допустимият размер на паметта“ Лимитът на PHP паметта е твърде нисък увеличаване memory_limit от страна на сървъра, след което тествайте отново
Тествате в производство без резервно копие. Валежи Клониране на етапи или поне архивиране на базата данни преди премахване на опции
Използвате стар урок (PHP 7) за WordPress 6.9.4 Кодът не е съвместим с PHP 8.1+ (TypeError, остарели функции) Адаптиране с валидиране на типа, sanitize_*и правилни кукички

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

Метод без код: временно заместване на Post SMTP

Ако е абсолютно необходимо да възстановите изпращането на имейли, докато диагностицирате проблема:

  • Инсталирайте друг надежден SMTP плъгин, конфигурирайте го и тествайте изпращането.
  • Оставете SMTP протокола за публикации деактивиран за времето на corriger.

Внимание: два SMTP плъгина, активирани едновременно, могат да се конкурират за hook-а. wp_mail и да водят до непоследователно поведение (двойно изпращане, счупени заглавки).

По-напреднал метод: проследяване на wp_mail и куките без модифициране на плъгина

За разработчици (или ако работите с доставчик на услуги), можете да внедрите изпращане на имейли от страната на WordPress чрез mu-плъгин. Целта: да се провери дали SMTP публикацията е правилно променена. wp_mail и дали грешката произхожда от администраторски екран или от пощенския канал.

Къде да се залепи : /wp-content/mu-plugins/mail-trace.php

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

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

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

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

Официална справка: wp_mail филтър

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

  • Извършете актуализациите на промежуточно копие. Когато можете. Страниците с настройки често са първото място, където се вижда грешка при миграция.
  • Поддържайте PHP актуален (Препоръчва се минимум 8.1+). Много „странни“ грешки идват от остаряла версия на PHP или от комбинация от липсващи разширения.
  • Избягвайте използването на „глобални“ фрагменти в admin_init без предпазни мерки. Винаги проверявайте:
    • контекстът (страница/екран)
    • разрешения (current_user_can())
    • видът на опциите (is_array(), is_string())
  • Не прилагайте минификация към администратора Освен ако не знаете точно какво правите. Често съм виждал страници с настройки да се счупват поради конкатениран JavaScript.
  • Следете лог файловете : поддържайте лесно завъртане и достъп. Фатална грешка почти винаги е предшествана от полезни предупреждения.

Фрагмент „Safeguard“ за администраторски страници (шаблон за многократна употреба)

Този модел ви спестява необходимостта от изпълнение на код на всички администраторски страници. Значително намалява риска от конфликти.

Къде да се залепи mu-плъгин или персонализиран плъгин.

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

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

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

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

Справка: Кука current_screen

ресурси

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

Трябва ли веднага да деактивирам Post SMTP?

Ако публичният сайт работи и само страницата с настройки се срива, първо можете да активирате регистрирането и да използвате проверката на състоянието, за да изолирате проблема. Ако администраторският панел стане нестабилен (глобална грешка), деактивирайте плъгина чрез FTP, като преименувате папката. post-smtp.

Получавам „Възникна критична грешка...“, но без подробности.

Активиране WP_DEBUG_LOG (Решение 1) и също така проверете лог файловете на сървъра. При някои хостинг планове WordPress няма право да записва в wp-content стига разрешенията да не са правилни.

Ще изтриването на опция ще наруши ли имейлите ми?

Да, потенциално: нулирате конфигурацията. Запазете опцията предварително (експортиране на JSON от WP-CLI или копиране на база данни), след което преконфигурирайте SMTP в интерфейса, след като грешката бъде коригирана.

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

Не директно. Но техните екосистеми често включват плъгини за оптимизация, плъгини за сигурност или администраторски добавки. Тестът за проверка на състоянието със стандартна тема позволява бързо определяне.

Използвам PHP 8.0 и ме е страх да ъпгрейдна до 8.1+

В WordPress 6.9.4 през 2026 г., PHP 8.1+ е препоръчителната базова версия. Много плъгини поправят грешки само в тези версии. Преминете към подготвителна версия и проверете критичните си плъгини.

Защо грешката се появява само на страницата с настройки?

Защото кодът, който чете/записва определени опции, зарежда определени файлове или инициализира специфичен потребителски интерфейс, се изпълнява само на този екран. Останалата част от сайта може да продължи да работи.

Получавам грешка „Класът не е намерен“ във vendor/autoload.php

Това често се дължи на непълна актуализация (съкратен ZIP файл, проблеми с разрешенията, антивирусна програма на сървъра). Най-бързото решение е чисто преинсталиране на плъгина от wordpress.org, последвано от почистване на кеша/OPcache, ако е възможно.

Трябва ли да променя файловете на плъгина, за да го поправя?

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

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

Временно преименувайте папката на плъгина чрез FTP (post-smtp → post-smtp.off) за да принудите деактивирането му. След това активирайте отново WP_DEBUG_LOG и възобновете диагностиката.

Каква е „минималната“ сума, която да се изпрати до поддръжката на Post SMTP?

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

Статии

Коментирай

Вашият имейл адрес няма да бъде публикуван. Задължителните полета са отбелязани *

Този сайт използва Akismet за намаляване на спама. Научете как се обработват вашите коментарни данни.