Modx журнал ошибок

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
Источник

Знакомясь с любой системой управления сайтом, в первую я стараюсь понять, что делать, если что-то идет не так. И конечно в данном случае большую роль играют средства самой системы управления, которые либо помогают понять, в чем проблема, либо совершенно не информативны. Поговорим о 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Реферальный спам »
Источник


май
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 для этого предусмотрен журнал ошибок. Но как читать эти ошибки? Вот в чем главный вопрос.

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

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

Источник

Все, кто работают с MODX, прекрасно знакомы с журналом ошибок, в который следует заглядывать в первую очередь, если что-то на сайте работает не так, как ожидается. Система записи системных сообщений в файл (лог) есть в любой CMS и фреймворке, этим никого не удивишь. Более того, при написании кода иногда полезно бывает записывать в лог отладочную информацию, которая может помочь впоследствии выявить проблему, если что-то пойдет не так.

Очень актуально это становится, когда приходится писать код для интеграции со сторонними системами. Например, когда другая система связывается с сайтом и записывает какие-то данные или даже просто обращается по API. В таком случае, запись входящих данных – производственная необходимость. Это нужно делать, чтобы быть уверенным, что данные приходят безопасные и обрабатываются правильно.

В MODX все такие события пишутся в файл /core/cache/logs/error.log. Начиная с версии 2.7.0 стало возможным на уровне системных настроек менять путь и имя файла для такого журнала ошибок (системные настройки error_log_filename и error_log_filepath). Но самое интересное, что если пользоваться MODX в режиме API, т.е. когда он вызывается внутри скрипта, возможность переопределять поведение регистрации ошибок имеется уже давно. Хотя по аннотациям к коду все не так однозначно, что в общем-то ожидаемо в случае MODX :).

У корневого класса MODX есть два метода, которые позволяют изменить поведение записи в журнал. Это setLogLevel и setLogTarget. Первый меняет уровень регистрации ошибок. Если коротко, то он говорит, какого уровня ошибки стоит записывать в журнал. Если установить xPDO::LOG_LEVEL_FATAL, то будут записывать только самые грубые ошибки, при которых вообще ничего не работает. А вот если xPDO::LOG_LEVEL_DEBUG, то будут записываться даже отладочные сообщения, которые обычно не нужны, но бывают полезны, если нужно разобраться в поведении приложения.

А вот метод setLogTarget любопытный. Исходя из описания, он позволяет поменять конечную цель, куда будут отправляться сообщения об ошибках. На выбор есть три варианта: ECHO, HTML и FILE. Первые два отправляют сообщения об ошибках прямо в стандартный поток вывода. HTML тоже самое, что и ECHO, но добавляет возможность форматирования сообщений с помощью HTML-тегов, что удобно, когда сообщения выводятся в браузер пользователя. Параметр со значением FILE позволяет записывать сообщения в файл, что следует из названия. Но для FILE существует еще вариант, когда можно указать вместо строки массив формата ['target' => 'FILE', 'options' => ['filename' => 'error.log', 'filepath' => 'core/cache/logs']]. И вот здесь уже можно проявить фантазию.

Покажу на практическом примере. У меня есть скрипт, который принимает запросы от стороннего сервиса и обновляет параметры отдельных товаров. Мне важно быть уверенным, что данные во-первых приходят, во-вторых я могу в любом момент сделать отчет, чтобы показать клиенту, что было обновлено, а что нет и нет ли ошибок. Мой код инициализации MODX в скрипте выглядит вот так:

require __DIR__ . '/config.core.php';
require MODX_CORE_PATH . 'model/modx/modx.class.php';

$modx = new modX();
$modx->initialize('mgr');
$modx->getService('error','error.modError', '', '');
	
$modx->setLogTarget(['target' => 'FILE', 'options' => ['filename' => 'import.log']]);
$modx->setLogLevel(xPDO::LOG_LEVEL_DEBUG);

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

Опытные программисты могут меня пожурить, что мол на пустом месте выдумал проблему и будут отчасти правы. Потому расскажу, как еще можно добиться записи результатов выполнения скрипта в файл. Сделать это очень просто средствами операционной системы, в моем случае Linux, при условии, что скрипт отдает все свои сообщения в стандартный поток вывода. Да, эта тот самый вариант с ECHO. А после вызываем наш скрипт и указываем, что нужно весь поток вывода записать в файл, например вот так: php /some/path/script.php > ~/core/cache/logs/import.log. Но в таком случае стоит учесть, что в лог будут попадать всё, что пишется в этот самый поток вывода, т.е. все конструкции echo, print_r и var_dump.

P.S. Напоминаю, что вы всегда можете поддержать меня финансово, что ускорит выход заметок о MODX в блоге.

Источник

Понравилась статья? Поделить с друзьями:
  • Modx вывод ошибок php
  • Mme ошибка внутреннего устройства adobe audition
  • Mmd ошибка не удалось запустить приложение
  • Mmcm ошибка 80010017 на ps3 как исправить
  • Mmccore ahk ошибка калина