Надоїдлива помилка _load_textdomain_just_in_time у WordPress

Сьогодні розглянемо практичний кейс по боротьбі з надоїдливою помилкою, з якою часто стикаються програмісти WordPress при розробці на локальному сервері:

{PHP Notice: Function _load_textdomain_just_in_time was called incorrectly ...}

Чому надоїдливою? Тому що її важко перемогти, і майже неможливо відключити повідомлення про неї. При кожному завантаженні сторінки (включно з AJAX запитами), – у ваш файл логів буде записуватись безліч сповіщень про цю помилку _doing_it_wrong().

Вхідні дані: при розробці на локальному сервері (Wampserever 3.3.5, PHP 8.3.6, CMS WordPress 6.8.1) в логах постійно вилітає дана помилка. Рекомендації з Інтернету не допомагають, допомагає тільки повне відключення логування, але, як ви розумієте, – при локальній розробці це взагалі не варіант.

Спробуємо вимкнути сповіщення про неї у логах. Способи виправлення функцій та/або плагінів у WordPres, які не будуть викликати дану помилку – будуть розглянуті в майбутніх статтях. Сьогодні лише поговоримо про сповіщення у файлах логування.

Що означає помилка `_load_textdomain_just_in_time`?

Ця PHP помилка рівня Notice пов’язана з системою інтернаціоналізації (i18n) WordPress, яка відповідає за переклад сайту різними мовами. Функція _load_textdomain_just_in_time є внутрішньою функцією WordPress, призначеною для оптимізації завантаження перекладів.

Повідомлення Function was called incorrectly означає, що WordPress очікував, що ця функція буде викликана в певний момент життєвого циклу запиту, але якийсь плагін або код робить це раніше або пізніше, ніж передбачалося. Це може бути пов’язано з тим, що плагін намагається завантажити свій текстовий домен (файли перекладу) ще до того, як WordPress повністю готовий до цього.

Хоча це Notice (повідомлення, а не критична помилка), воно засмічує логи і може маскувати реальні проблеми, а також вказувати на потенційно неефективний код.

Можливі рішення відключення показу саме цього сповіщення `_doing_it_wrong()`

Якщо ви вже робили багато спроб вирішити цю проблему, але нічого не допомогло, давайте розглянемо найефективніші підходи, які зазвичай допомагають знизити рівень сповіщення, не вимикаючи повністю логування.

Рішення 1: Перевірка та оновлення версій

Найперше, що варто перевірити:

WordPress: Переконайтеся, що у вас встановлена найновіша версія WordPress (наразі 6.8.1).
Плагіни: Обов’язково оновіть плагіни до останніх доступних версій. Розробники зазвичай випускають оновлення, які виправляють подібні попередження, особливо з появою нових версій PHP.
Спробуйте інші (нижчі) версії PHP

Рішення 2: Зміна рівня логування PHP (на локальному сервері)

Це не “вимкнення логування”, а зменшення деталізації логів до більш важливих повідомлень (помилок та попереджень). Рівень помилок E_NOTICE на продакшн-сайтах часто відключають, оскільки вони не є критичними.

У файлі php.ini (якщо у вас WampServer: лінк на потрібний файл можна знайти через іконку WampServer -> PHP -> php.ini), знайдіть рядок error_reporting та встановіть його на:

error_reporting = E_ALL & ~E_NOTICE & ~E_DEPRECATED & ~E_STRICT

Пояснення коду:

E_ALL: Логувати всі типи помилок.
~E_NOTICE: Виключити повідомлення (Notices).
~E_DEPRECATED: Виключити попередження про застарілий код.
~E_STRICT: Виключити рекомендації щодо кодування.

Після зміни php.ini обов’язково перезапустіть всі сервіси локального серверу (наприклад, для WampServer через іконку WampServer -> Restart all services).

Це найпоширеніше та найбезпечніше рішення для розробки, оскільки воно дозволяє бачити критичні помилки та попередження, але ігнорує “шумні” Notices, які часто генеруються плагінами.

Правильне редагування файлу php.ini

Вам потрібно переконатися, що ви редагуєте саме той, потрібний, файл php.ini. Ось як переконатися та знайти необхідний файл:

Створіть PHP файл з кодом простої, але потужної функції для отримання інформації про поточний стан PHP:

<?php
phpinfo();
?>

Відкрийте цей файл у браузері і погляньте на шлях у рядку “Loaded Configuration File”: це саме той файл налаштувань, який потрібен. Наприклад, \wamp64\bin\apache\apache2.4.59\bin\php.ini
Відкрий цей файл за допомогою текстового редактора (наприклад, Notepad++, VS Code, Sublime Text, тощо).
Відредагуйте налаштування error_reporting у цьому файлі (як показано вище)
Перевірте інші налаштування: display_errors може мати значення Off (для продакшну) або On (для відладки на локалці); log_errors = On (включаємо логування); шлях у рядку error_log буде вказувати на шлях до файлу логів, наприклад, error_log = "c:/wamp64/logs/php_error.log"
Після змін та перезавантаження серверу, перевірте phpinfo() знову:
Відкрийте PHP файл із функцією phpinfo() у браузері.
Переконайтеся, що значення error_reporting тепер відображається як 32759 (це числове значення E_ALL & ~E_NOTICE & ~E_DEPRECATED & ~E_STRICT).
Переконайтеся, що display_errors відображається як Off.

Перевірте роботу сайту:
- Відкрийте свій сайт на WordPress.
- Перевірте лог файли PHP (php_error.log та/або wp-content/debug.log), чи зникли ці Notice повідомлення.

Рішення 3: Заборонити WordPress логувати Notice

Це найпряміший спосіб зупинити логування Notice у debug.log, якщо інші методи не працюють. Ви можете модифікувати файл wp-config.php так, щоб WordPress ігнорував E_NOTICE при логуванні.

Загалом, для логування у WP використовуються наступні конструкції:

define( 'WP_DEBUG', true ); // включити дебаг
define( 'WP_DEBUG_LOG', true ); // це повинно бути true, щоб лог працював і логування відбувалось у файл
// якщо включено, він буде знаходитись у wp-content/debug.log define( 'WP_DEBUG_DISPLAY', false ); // це нормально для розробки, щоб помилки не виводились на екран, але йшли в лог

Ми можемо спробувати трохи розширити цей дефолтний функціонал:

<?php
// Помістіть ці рядки якомога раніше у wp-config.php, бажано одразу після `<?php`
// і ПЕРЕД `define('WP_DEBUG', true);` або будь-яким `require_once`.
// Відключаємо E_NOTICE для внутрішнього логування WordPress
// Цей фільтр буде застосовуватися до того, як WordPress почне реєструвати свої помилки.
if ( defined( 'WP_DEBUG' ) && WP_DEBUG ) {
  error_reporting( E_ALL & ~E_NOTICE & ~E_DEPRECATED & ~E_STRICT );
  // Ці ini_set також можуть допомогти, але error_reporting() є головним
  @ini_set( 'log_errors', 'On' );
  @ini_set( 'display_errors', 'Off' ); // Важливо для розробки, щоб не виводити на екран
} else {
  // Для продакшн середовища
  error_reporting( 0 ); // Не показувати помилки
  @ini_set( 'display_errors', 'Off' );
  @ini_set( 'log_errors', 'Off' );
}
// ... решта коду у файлі wp-config.php

Пояснення по коду:

Ми переносимо встановлення error_reporting і ini_set максимально вище у файлі wp-config.php, перед більшістю інших визначень. Таким чином, ці налаштування застосовуються раніше, ніж WordPress починає реєструвати свої власні обробники помилок, які можуть ігнорувати системні налаштування.

Вказані рядки у wp-config.php перевизначають налаштування з php.ini. Це може бути причиною, чому зміни в php.ini можуть не мати потрібного вам ефекту.

Рекомендація: щоб налаштування в php.ini мали більший пріоритет, закоментуйте або видаліть будь-які рядки @ini_set() у wp-config.php, що стосуються error_reporting або display_errors.

Після змін у wp-config.php збережіть файл і перезавантажте локальний сервер.

Рішення 4: Використання `.htaccess` для локальної зміни `error_reporting`

Якщо php.ini і wp-config.php не дають результату, можна спробувати встановити рівень error_reporting через .htaccess. Цей метод впливає лише на той каталог, де розміщено .htaccess і його підкаталоги.

Відкрийте файл .htaccess у корені свого WordPress сайту і додайте наступні рядки:

# BEGIN WordPress
  … # наявний код
# END WordPress
# Налаштування PHP
php_value error_reporting 32759
php_flag display_errors off
php_flag log_errors on

Пояснення по коду:

php_value error_reporting 32759: Число 32759 є бітовою маскою для E_ALL & ~E_NOTICE & ~E_DEPRECATED & ~E_STRICT. Це еквівалент даного текстового значення.
php_flag display_errors off: Вимкнути виведення помилок на екран.
php_flag log_errors on: Увімкнути логування помилок.

Важливо: Цей метод працює лише, якщо у вас сервер Apache і на ньому активований mod_php або mod_fcgid.
Після змін у .htaccess перезавантажте локальний сервер (наприклад, LAMP, XAMPP, WampServer, тощо).

Рішення 5: Втручання в код (як крайній захід, не рекомендується)

Якщо попередні кроки не допомогли, і ви мусите позбутися цього повідомлення, можна спробувати обгорнути виклик функції _load_textdomain_just_in_time в try-catch або придушити помилку @ оператором. Приклад: якщо ви знайдете у «конфліктному» плагіні рядок на кшталт:

_load_textdomain_just_in_time( $domain, $mofile );

змініть його на:

@_load_textdomain_just_in_time( $domain, $mofile );

Але! Якщо ви робите таку модифікацію у файлах плагіна, ваші зміни буде втрачено після наступного оновлення.

Я не рекомендую цей метод, оскільки він створює “хак”, який ускладнює підтримку і може призвести до неочікуваних побічних ефектів в майбутньому.

Не використовуйте це на живому сайті.

Чому це погано:

Будь-яке оновлення плагіна перезапише ваші зміни.
Це маскує потенційну проблему в плагіні, а не виправляє її.

Якщо всі попередні кроки не спрацювали, це вказує на те, що проблема може бути трохи глибшою, або пов’язана з конкретною конфігурацією локального серверу або взаємодією версій PHP/WordPress/плагінів. Деякі плагіни (особливо старі або ті, що сильно модифікують ядро) можуть мати дуже агресивні методи завантаження своїх перекладів, які можуть ігнорувати стандартні налаштування PHP, або ж вони можуть використовувати якісь низькорівневі виклики, що генерують Notice навіть при придушенні на рівні error_reporting. Певні проблеми із цим виникали при використанні плагінів типу Polylang, AMP (Accelerated Mobile Pages), тощо. Якщо жоден з попередніх кроків не допоміг, це може бути специфічний баг у плагіна у комбінації з версією PHP, який не виправляється звичайними налаштуваннями. У цьому випадку, можливо, доведеться чекати оновлень від розробників плагінів або звертатися до їхньої підтримки, надаючи їм деталі про версії PHP, плагінів та WordPress.

Чому це так важко виправити:

Порядок завантаження: WordPress і його плагіни мають складний порядок завантаження. Цілком можливо, що плагіни генерують це “повідомлення про некоректний виклик функції” настільки рано, що навіть error_reporting() у wp-config.php не встигає повністю придушити його до того, як WordPress його “схопить” і запише в debug.log. Це означає, що саме реалізація функції _load_textdomain_just_in_time або її виклик плагінами дійсно генерує Notice до того, як WordPress може його ефективно придушити.
Внутрішня логіка WordPress/Плагіна: Функція _load_textdomain_just_in_time є внутрішньою функцією WordPress, і повідомлення Function was called incorrectly генерується самим WordPress (через _doing_it_wrong() функцію) для розробників. Це не “помилка PHP”, а “помилка використання WordPress API”. Навіть якщо PHP ігнорує E_NOTICE, WordPress може спеціально логувати _doing_it_wrong() повідомлення, щоб повідомити розробників про потенційно неправильне використання своїх функцій.
Неприборкувані _doing_it_wrong(): Саме повідомлення про _doing_it_wrong() часто є стійким, оскільки воно призначене для привернення уваги. Його не завжди можна придушити стандартними error_reporting прапорами, оскільки це не класичний E_NOTICE, а спеціальний механізм відладки WordPress.

Що робити далі (якщо нічого не допомогло):

На жаль, якщо ви вже спробували усі стандартні та навіть деякі просунуті методи конфігурації, і повідомлення все одно з’являється в debug.log, то найбільш ймовірних кроків, на локальному сервері, у вас буде кілька:

Змиритися з цим (найпростіше): Якщо це лише Notice і він не впливає на функціональність сайту, а ви працюєте на локальному сервері, то, можливо, найпростіший шлях – це просто ігнорувати ці конкретні повідомлення в debug.log. На живому сайті WP_DEBUG_LOG повинен бути вимкнений (define('WP_DEBUG_LOG', false);), тому ці повідомлення не будуть з’являтися у продакшн логах. Можете періодично очищати debug.log вручну, щоб він не розростався.
Зв’язатися з розробниками плагінів: Оскільки проблема часто ідентифікується як пов’язана із плагінами, спробуйте зв’язатись із підтримкою розробників цих плагінів. Надайте їм усі деталі: версії WordPress, PHP, плагіну, локального серверу, а також точне повідомлення про помилку. Вони можуть знати про цю проблему і мати патч або робоче рішення, або включити виправлення в майбутні оновлення.
Тимчасово вимкнути WP_DEBUG_LOG (для розробки): Це прибере всі повідомлення з debug.log, включаючи потенційно важливі попередження про помилки у вашому власному коді. Але якщо ці Notice дійсно настільки сильно вас турбують, це може бути тимчасовим компромісом:

define( 'WP_DEBUG_LOG', false ); // Виставте на false, щоб вимкнути запис логів у debug.log

Пам’ятайте: Це не виправляє першопричину, а лише приховує логування. Ви втрачаєте цінний інструмент відладки.

Замість висновку

Найімовірніше, проблему є реальна змога вирішити одним із наступних кроків:

Оновлення WordPress до останньої актуальної версії
Оновлення плагінів до останніх версій
Зміна error_reporting у php.ini на E_ALL & ~E_NOTICE & ~E_DEPRECATED & ~E_STRICT та перезапуск локального сервера

Ці кроки дозволять вам продовжувати логувати справжні помилки та попередження, ігноруючи при цьому некритичні Notices від сторонніх плагінів. Моя рекомендація – зосередитися на тому, чи впливає ця помилка Notice на функціональність вашого сайту. Якщо ні, то на локальному сервері її можна ігнорувати або періодично чистити лог. Для продакшн-сайту бажано завжди вимикати WP_DEBUG_LOG.

Спробуйте вказані в сьогоднішній практичному кейсі рішення, і проблему можна перемогти!