Надоедливая ошибка _load_textdomain_just_in_time в WordPress
Опубликовано

Надоедливая ошибка _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) в логах постоянно вылетает данная ошибка. Рекомендации по Интернету не помогают, помогает только полное отключение логирования, но, как вы понимаете, – при локальной разработке это вообще не вариант.

Попробуем выключить уведомление о ней в логах. Способы исправления функций и/или плагинов WordPress, которые не будут вызывать данную ошибку – будут рассмотрены в будущих статьях. Сегодня только поговорим об уведомлениях в файлах логирования.

 

Что означает ошибка _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»: это именно тот файл настроек, который нужен.
  • Откройте этот файл с помощью текстового редактора (например, 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.

 

Почему это трудно исправить:

  1. Порядок загрузки: WordPress и его плагины имеют сложный порядок загрузки. Вполне возможно, что плагины генерируют это «сообщение о некорректном вызове функции» настолько рано, что даже error_reporting() в wp-config.php не успевает полностью подавить его до того, как WordPress его «схватит» и запишет в debug.log. Это означает, что реализация функции _load_textdomain_just_in_time или ее вызов плагинами действительно генерирует Notice до того, как WordPress может его эффективно подавить.
  2. Внутренняя логика WordPress/Плагина: Функция _load_textdomain_just_in_time является внутренней функцией WordPress, и сообщение Function was called incorrectly генерируется самим WordPress (через E_NOTICE, WordPress может специально логировать _doing_it_wrong() сообщения, чтобы сообщить разработчикам о потенциально неправильном использовании своих функций.
  3. Неукротимые _doing_it_wrong(): Само сообщение о _doing_it_wrong() часто является устойчивым, поскольку оно предназначено для привлечения внимания. Его не всегда можно подавить стандартными error_reporting флагами, поскольку это не классический E_NOTICE, а специальный отладочный механизм WordPress.

Что делать дальше (если ничего не помогло):

К сожалению, если вы уже попробовали все стандартные и даже некоторые продвинутые методы конфигурации, и сообщение все равно появляется в debug.log, то наиболее вероятных шагов на локальном сервере у вас будет несколько:

  1. Смириться с этим (самое простое): Если это только Notice и он не влияет на функциональность сайта, а вы работаете на локальном сервере, то, возможно, самый простой путь – это просто игнорировать эти конкретные сообщения в debug.log. На живом сайте WP_DEBUG_LOG должен быть отключен (define('WP_DEBUG_LOG', false);), поэтому эти сообщения не будут появляться в продакшн логах. Можете периодически очищать debug.log вручную, чтобы он не разрастался.
  2. Связаться с разработчиками плагинов: Поскольку проблема часто идентифицируется как связанная с плагинами, попробуйте связаться с поддержкой разработчиков этих плагинов. Предоставьте им все подробности: версии WordPress, PHP, плагина, локального сервера, а также точное сообщение об ошибке. Они могут знать об этой проблеме и иметь патч или рабочее решение, или включить исправления в будущие обновления.
  3. Временно отключить WP_DEBUG_LOG (для разработки): Это уберет все сообщения из debug.log, включая потенциально важные предупреждения об ошибках в вашем собственном коде. Но если эти Notice действительно столь сильно вас беспокоят, это может быть временным компромиссом:
define('WP_DEBUG_LOG', false ); // Выставьте на false, чтобы отключить запись логов в debug.log

Помните: Это не исправляет первопричину, а лишь скрывает логирование. Вы теряете ценный инструмент отладки.

 

 

Вместо вывода

Скорее всего, проблему есть реальным решить одним из следующих шагов:

  1. Обновление WordPress до последней актуальной версии
  2. Обновление плагинов до последних версий
  3. Изменение error_reporting в php.ini на E_ALL & ~E_NOTICE & ~E_DEPRECATED & ~E_STRICT и перезапуск локального сервера

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

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

 

 

Теги: ,

Нужно больше информации?

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *