Modx revo логи ошибок

Знакомясь с любой системой управления сайтом, в первую я стараюсь понять, что делать, если что-то идет не так. И конечно в данном случае большую роль играют средства самой системы управления, которые либо помогают понять, в чем проблема, либо совершенно не информативны. Поговорим о MODX Revolution.

Система логирования MODX Revolution мне нравится, так как чем-то мне напоминает логирование в Linux и некоторых других open-source проектах. То есть позволяет выводить информацию в разные источники и позволяет группировать информацию по уровню важности, знакомыми всем системным администраторам log levels, что для меня очень важно. При этом система логирования задействуется уже на этапе установки, что упрощает решение проблем, происходящих в момент установки MODX, а они бывают.

Управление системой логирования производится через системные настройки log_target и log_level, которые расположены в блоке System and Server системных настроек MODX Revolution. На выводе в разные источники останавливаться не буду, скажу лишь, что источник задается системной настройкой log_target и по умолчанию логирование производится в файл (опция FILE). Сам файл с логами будет находиться по адресу: /core/cache/logs/error.log. Он же будет показываться, если выбрать пункт Error log (Журнал системы управления) в меню в админке.

На уровнях остановлюсь поподробнее, всего их 5: 0 (FATAL), 1 (ERROR), 2 (WARN), 3 (INFO), 4 (DEBUG). Использование данной группировки позволяет нам не только понимать уровень важности возникшей проблемы, но и задавать уровень, от которого информация будет в этот лог попадать (логироваться). Логика работы очень похожа на syslog. Например, если мы зададим уровень 1 (ERROR), то логироваться будут ошибки (1) и фатальные ошибки (0). Если же мы зададим 3 (INFO), то логироваться будут уровни 3 информация,2 предупреждения, 1 ошибки, 0 фатальные ошибки.

Кстати, как и любой лог в *nix системах за данным логом можно так же следить в режиме реального времени через tail:

tail -f /полный_путь_к_MODX/core/cache/logs/error.log

А еще мы можем сами добавлять информацию в лог через вызов метода MODX:

$modx->log(xPDO::LOG_LEVEL_ERROR,'Сообщение которое хотим отправить в лог');

, где LOG_LEVEL_ERROR означает уровень 1 (ERROR) и соответствует уровням логирования (FATAL, ERROR, WARN, INFO, DEBUG). Заменив последнее слово мы изменим и лог уровень, которому будет соответствовать важность сгенерированного нами сообщения.

« Буллеты через CSSРеферальный спам »
Источник

xPDO::log¶

Регистрирует сообщение с подробной информацией о том, где и когда произошло событие.

Синтаксис¶

API Docs: https://api.modx.com/revolution/2.2/db_core_xpdo_xpdo.class.html#\xPDO::log()

$xpdo->log($level, $msg, $target= '', $def= '', $file= '', $line= '');
  • $level — (целое число) Уровень детализации зарегистрированного сообщения. Смотрите константы многословия ниже
  • $msg — (строка) Сообщение для входа.
  • $target — (mixed) Цель регистрации. Если это строка, это должно быть FILE,HTML или ECHO. Если массив, см. Примеры ниже.
  • $def — (строка) Имя определяющей структуры (например, класса), помогающей определить источник событий журнала.
  • $file — (строка) Имя файла, в котором произошло событие журнала. Обычно вы используете константу __FILE__.
  • $line — (строка) Номер строки, помогающей определить источник события. Обычно вы используете константу __FILE__ 
void log (integer $level, string $msg, [string $target = ''], [string $def = ''], [string $file = ''], [string $line = ''])

Уровни журнала¶

Во многих случаях вы можете использовать эквивалентные константы MODX для уровней журнала.

То, что печатается, контролируется настройкой системы log_level. Вы можете переопределить это во время выполнения, используя метод setLogLevel.

Примеры¶

Просто¶

Простое сообщение журнала, записывает в файл журнала по умолчанию (например, core/cache/logs/error.log):

$xpdo->log(xPDO::LOG_LEVEL_ERROR, '[Mobile Detect] An error occurred.');

В журналах это будет выглядеть так:

[2013-09-15 14:21:25] (ERROR @ /index.php) [Mobile Detect] An error occurred.

Укажите Сниппет¶

Поскольку приложение MODX в конечном итоге запускается через файл index.php, полезно добавить дополнительную информацию:

$xpdo->log(xPDO::LOG_LEVEL_ERROR, 'An error occurred.', '', 'MySnippet');

[2013-09-15 14:22:48] (ERROR in MySnippet @ /index.php) An error occurred

Указать файл и строку¶

Помните, что в конечном итоге все сниппеты и плагины MODX запускаются из кэшированных файлов, поэтому в качестве исходного файла будет указан кэшированный файл.

$xpdo->log(xPDO::LOG_LEVEL_ERROR, 'This is my error message...', '', 'MySnippet', __FILE__, __LINE__);

[2013-09-15 14:48:02] (ERROR in MySnippet @ /path/to/core/cache/includes/elements/modsnippet/28.include.cache.php : 7) This is my error message...

Пользовательский файл журнала¶

Вы можете отправить ошибки в пункт назначения, отличный от журнала ошибок MODX по умолчанию. Для этого вы должны передать массив в аргумент $target. Вы должны подробно указать FILE в качестве цели, в противном случае сообщение будет возвращено на страницу.

$xpdo->log(xPDO::LOG_LEVEL_ERROR, 'Error for my custom log file', array(
    'target' => 'FILE',
    'options' => array(
        'filename' => 'custom.log'
    )
));

По умолчанию путь к файлам журнала — это core/cache/logs/, поэтому в этом примере мы находим наше сообщение журнала внутри файла custom.log:

[2013-09-15 15:01:07] (ERROR @ /index.php) Error for my custom log file

При желании вы также можете указать путь через аргумент filepath.

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

$log_target = array(
    'target'=>'FILE',
    'options' => array(
        'filename'=>'my_custom.log'
    )
);
$xpdo->log(xPDO::LOG_LEVEL_ERROR, 'My Error...',$log_target);
$xpdo->log(xPDO::LOG_LEVEL_ERROR, 'Some other error...',$log_target);

Отладка¶

Вы можете изменить уровень зарегистрированного сообщения, регулируя первый параметр. Например. для записи отладочного сообщения:

$xpdo->log(xPDO::LOG_LEVEL_DEBUG,'This is a debugging statement.');

Пользовательское использование в сниппетах¶

Это может быть очень удобно для увеличения подробности регистрации для отдельного сниппета или плагина. Для этого используйте функцию setLogLevel(). Вы можете использовать это, чтобы переопределить глобальное значение системного параметра log_level:

// Вызови свой сниппет так: [[mySnippet? &log_level=`4`]]
// Переопределить глобальное значение log_level
$log_level = $modx->getOption('log_level', $scriptProperties, $modx->getOption('log_level'));
$modx->setLogLevel($log_level);

Константы многословия¶

xPDO константа MODX константа Значение
xPDO::LOG_LEVEL_FATAL MODX_LOG_LEVEL_FATAL 0
xPDO::LOG_LEVEL_ERROR MODX_LOG_LEVEL_ERROR 1
xPDO::LOG_LEVEL_WARN MODX_LOG_LEVEL_WARN 2
xPDO::LOG_LEVEL_INFO MODX_LOG_LEVEL_INFO 3
xPDO::LOG_LEVEL_DEBUG MODX_LOG_LEVEL_DEBUG 4

Смотрите также¶

  • Системная настройка log_level
  • Системная настройка log_target
  • xPDO
Источник


май
19
, 2015

Рассмотрим примеры использования логов для отладки веб-приложения.

Используем логи Modx

По умолчанию логи Modx находятся в файле /core/cache/logs/error.log.
Это обычный текстовый документ, можете открывать его в любом редакторе.
Также он доступен в админке Modx, пункт Управление — Отчеты — Журнал ошибок
(в разных версиях меню может отличаться).
Но самый удобный способ при работе в командной строке Linux, это набрать 

    tail -f /path_to_modx_site/core/cache/logs/error.log

Команда будет выводить последние несколько строк из файла в режиме «онлайн»

Часто логи нужны нам не только для того, чтобы посмотреть ошибки, генерируемые Modx.
Иногда мы хотим записать туда свои данные в целях отладки.
Старый добрый вывод в браузер тоже работает, но не всегда это удобно, например,
при отладке скриптов, вызываемых аяксом. В Modx Revo записать в логи данные можно так: 

    $modx->log(1, 'message: '.$phone);

Вторым параметром передается сама строка для вывода. Вначале добавляется пояснения для удобства,
чтобы не запутаться, когда в логи выводим много данных.

Если мы работаем не с Modx или не хотим использовать его логи, то можем работать с логами веб-сервера.
Где они находятся, нужно смотреть в настройках веб-сервера.
Это тот же самый текстовый файл, который можем открывать, как угодно.
А записывать в него можем командой 

    error_log('ARRAY: '.var_export($array, true));

Обратите внимание, что можно использовать команду var_export со вторым параметром true.
Функция var_export выведет содержимое любого типа, например, массивов.
Капсом пояснение пишем, чтобы было легче ориентироваться в логах.
Можно даже записать отдельную функцию для записи в логи, например: 

    // Функция записи в логи
    function errorLog($caption, $param) {
        error_log(strtoupper($caption).': '.var_export($param, true));
    }
    // Вызов функции
    errorLog('список телефонов', $phones);

Как видим, запись стала читаться получше

Анонсы статей, обсуждения интернет-магазинов, vue, фронтенда, php, гита.

Истории из жизни айти и обсуждение кода.

Источник

Для получения отладочных сообщений в журнале отчетов MODX следует использовать $modx->log(). Объявление функции имеет вид:

public function log($level, $msg, $target = '', $def = '', $file = '', $line = '')

Первый параметр

Первый параметр указывает уровень/тип сообщения — ошибка, предупреждение, информационное сообщение или отладочная информация. Для каждого уровня константы:

  • MODX_LOG_LEVEL_FATAL = 0
  • MODX_LOG_LEVEL_ERROR = 1
  • MODX_LOG_LEVEL_WARN = 2
  • MODX_LOG_LEVEL_INFO = 3
  • MODX_LOG_LEVEL_DEBUG = 4

Второй параметр

Второй параметр содержит информацию, которая будет записана в журнал ошибок.

Обычно ограничиваются указанием только первых двух параметров

Третий параметр

В него передается «назначение», куда будет выводится информация. Возможные значения:

  • FILE — сообщение сохраняется в файл core/cache/logs/error.log (по умочанию)
  • ECHO — информация выводится на экран
  • HTML — информация выводится на экран обёрнутая в тег <pre>

Четвертый параметр

В нём можно передать название скрипта или метода класса, в котором вызван метод log(). Особенно это удобно, когда таких вызовов несколько.

  • «MySnippet» — выведется именно эта строка
  • __METHOD__ — выведется название метода, где производится логирование

Пятый и шестой параметры

Они отвечают за вывод информации о скрипте и номере строки. Если их не указать, то они определятся автоматически как:

  • __FILE__
  • __LINE__

Системные настройки

Есть две системные настройки, влияющие на работу метода log() — это log_target и log_level. По умолчанию они имеют значение FILE и 1, соответственно.

Первая (log_target) указывает куда выводить информацию (см. «третий параметр»).

Вторая (log_level) указывает текущий уровень логирования MODX. Возможные значения:

  • 0 — для фатальных сообщений (fatal)
  • 1 — для ошибок (error)
  • 2 — для предупреждений (warn)
  • 3 — для информационных сообщений (info)
  • 4 — для отладочных сообщений (debug)

Эта настройка ограничивает логирование сообщений указанным уровнем. Таким образом log() с уровнем выше, чем в настройке, будет отклонён. Например, если в настройке указано log_level = 1 (т.е. логируются только ошибки), то все вызовы метода log() с уровнем WARN, INFO и DEBUG в журнал записаны не будут. Как правило, при отладке на эти уровни не обращают внимание и используют текущий уровень логирования для ошибок.

Примеры

$modx->log(MODX_LOG_LEVEL_ERROR, 'Сообщение');
// или так
$modx->log(modX::LOG_LEVEL_ERROR, 'Сообщение');
// или ещё короче
$modx->log(1, 'Сообщение');

В режиме разработки полезно работать с уровнем DEBUG. Это полезно тем, что даже если вы забудете потом удалить этот вызов, то он не будет забивать журнал ошибок, так как на продакшн сайте уровень логирования всегда выставляется в 1 (записывать в журнал только ошибки).

Если нужно вывести только отладочную информацию на странице без контента, то указываем вывод в HTML и добавляем die() или exit(), например:

$modx->log(MODX_LOG_LEVEL_ERROR, print_r($modx->config, 1),'HTML'); die();

Copyright © Majestio, 2006-2023

Источник

Практически любой вопрос решается достаточно легко, если знать откуда растут ноги. В MODx для этого предусмотрен журнал ошибок. Но как читать эти ошибки? Вот в чем главный вопрос.

Конечно же плюсом будет знание английского, потому как не всегда есть возможность понять, что от нас хотят логичесим путем.

Notice: Undefined variable: first in /var/www/admin/data/www/site.ru/core/cache/includes/elements/modsnippet/18.include.cache.php on line 440

Как прочесть данную ошибку?

Разберем по пунктам:

  1. Переведем первую часть ошибки. В ней говорится о том, что вызвана неизвестная переменная под названием first.
  2. Папка modsnippet указывает, что данный ресурс является сниппетом.
  3. 18.include.cache.php — это сниппет с ID 18. Чтобы быстро перейти к редактированнию сниппета, подставьте ID к ссылке /manager/?a=element/snippet/update&id=18 и перейдите по ней.
  4. on line 440 — на линии 440. После того, как вы перешли в сниппет, перейдите сразу на 440 линию. Именно там и образовалось ошибка с переменной first.

Оригинал статьи: https://litosh-web.ru/blog/modx/kak-chitat-oshibki-v-modx

Источник

Понравилась статья? Поделить с друзьями:
  • Mk10 exe ошибка приложения 0xc0000142
  • Modx 500 ошибка после переноса
  • Modulenotfounderror no module named requests ошибка
  • Mk10 exe ошибка при запуске приложения
  • Mk mobile ошибка соединения