Modx вывод ошибок php

• Имя: Отладка
• Тип: String
• По умолчанию:
• Доступен в: Revolution 2.2.0+

Управляет включением/выключением отладки в MODX и/или устанавливает уровень PHP отладки error_reporting.
Возможные варианты: » = использовать текущий уровень error_reporting, ‘0’ = выключена отладка (error_reporting = 0), ‘1’ = включена отладка (error_reporting = -1), или любой другой корректный уровень error_reporting(целое число).

Посмотрите также¶

• PHP error-reporting

Open COllective

Support the team building MODX with a monthly donation.

The budget raised through OpenCollective is transparent, including payouts, and any contributor can apply to be paid for their work on MODX.

Backers

Budget

$400 per month—let’s make that $500!

Learn more

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);

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

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

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

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

Итак, что нужно делать.

• Зайти в phpMyAdmin в базу данных, где хранятся данные вашего сайта.
• Найти таблицу «modx_system_settings». Если вы выбирали другой префикс, то она будет выглядеть так: «ПРЕФИКС_system_settings».
• Нажимаем кнопку «Обзор»
• Листаем примерно на третью страницу
• Находим поле «validate_referer». Если оно установлено в 1 — меняем на 0.
• Сохраняем, проверяем.

Должно получиться.

Если ваш сайт поломался и вы не понимаете в чем дело — нужно продиагностировать его. Нужно понять что не так прежде чем пытаться чинить. PHP и MODx имеют механизмы отлавливания и отображения ошибок, но эти механизмы в MODx по-умолчанию отключены. Чтобы включить их, нужно сделать ряд действий.

Если вы разрабатываете свой сниппет, вам достаточно включить две строки в любом месте (лучше в начале) сниппета.

error_reporting(E_ALL | E_STRICT);
ini_set('display_errors', 1);

Эти две строки с большой долей вероятности включат отображение всех ошибок и предупреждений, которые найдет php.

Если вы просто пользователь сайта — создайте новый сниппет. Назовите его, например, ‘Debug’, заполните его вышеописанными строками кода и включите в шаблон страницы или любой чанк, участвующий в ее формировании:

[[Debug]]

Таким образом вы включите отображение ошибок там, где вызывается этот сниппет.

Зачастую включение этих строк в скрипт выводит сообщение:

Parse error: syntax error, unexpected ')' in /path2site/assets/plugins/phx/phx.parser.class.inc.php(220) : eval()'d code on line 1
Parse error: syntax error, unexpected ')' in path2site/assets/plugins/phx/phx.parser.class.inc.php(226) : eval()'d code on line 1

Не пугайтесь. Эта ошибка phx. Она, кажется, никак не влияет на работу сайта и самого phx, так что можно не обращать на нее внимания.

Но вот если вы увидели другие ошибки — это уже тревожный знак. Для начала попробуйте загуглить точный текст ошибки (поиск в кавычках). Разумеется, не надо включать в поисковую фразу то, что уникально для вашего сайта. Например, путь к файлу на сервере. Включайте только значимый текст. Например «Parse error: syntax error, unexpected ‘)’ in». Этого будет достаточно чтобы найти много материалов для изучения.

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

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

Поэтому когда у вас что-то не работает — не бойтесь, ищите, узнавайте, разбирайтесь. Конечно, стоит поостеречься вслепую вносить какие-то изменения в вашу систему, если не понимаете что эти изменения делают. Так можно не только починить сайт, но и доломать его окончательно так, что проще будет новый сделать. Вдруг вам какой-нибудь шутник подскажет скрипт для удаления всех данных? Или, хуже, для отправки логина-пароля администратора ему на e-mail? Так что будьте внимательны и не доверяйте всему, что пишут на заборе в интернете.

Самостоятельное решение проблем или использование знаний специалистов?

Когда вы сталкиваетесь с проблемой, у вас есть два выхода — взять на себя ответственность по исправлению ошибки, либо попросить кого-то, кто опытней (предполагается), сделать все за вас. В менеджменте это называется «делегировать». Люблю это слово:)

Понятно, что если вы делаете сами, вы делаете долго, без гарантии исправления и можете сделать не вполне верно. Коряво, то есть. Но с другой стороны, если вы самостоятельно решаете проблему, вы получаете много печенек. Вы получаете ценный опыт, вы лучше разбираетесь в собственной системе. Вы получаете знания, которые можно использовать при исправлении другой, может, совсем иной ошибки на другом сайте в следующей жизни. И главное — вы получаете удовольствие от того, что сами сусами.

С другой стороны, исправление проблемы профессионалом будет стоить вам денег, но проблема будет исправлена быстро и, скорее всего, качественно. Конечно, гарантии вам никто не даст, но на то они и узкие специалисты чтобы уметь что-то лучше, чем специалисты другой области или широкого профиля.

При выборе метода я бы ориентировался на срочность. Если у вас интернет магазин и вы теряете прибыль — исправлять ошибку нужно срочно. Не жалко заплатить эксперту, чтобы тот быстро все поправил. Потом можно доплатить чтобы объяснил что именно он сделал и где была проблема. Так вы сэкономите время и получите часть плюшек от варианта «сделай сам».

С другой стороны, если на том же интернет магазине не работает вывод баннеров — это не критично и можно поковырять самостоятельно.

Вообще, самостоятельная деятельность — это хорошо. Я больше предпочитаю так. Хотя, конечно не во всех областях. Например чтобы создать 3D-модель нужного качества мне потребуется, скажем, месяц, а спецу — день. Разница?:) Хотя, например, узнать как самостоятельно продвигать сайт ничего не стоит. Материалов в сети много и они в последнее время, приемлемого качества. Достаточного для того, чтобы сделать не так уж плохо. А до специалиста, при желании, докачаться можно за несколько месяцев. Не такая уж мудреная область.

Хватит разглагольствовать, пора закругляться. Планирую написать в ближайшее время пост про vCard и как его сделать на своем сайте на MODx — не пропустите. Кроме того, если у вас ошибка и вам нужен эксперт чтобы ее исправить — смело обращайтесь ко мне. Могу помочь советом или делом. Деньги возьму не всегда, зависит от количества работы:)

One of the common tools available for troubleshooting issues for a website is the error log.  It is important to understand that Modx shows an error log for problems or flags that are set by developers of Modx.  Additionally, you can see an error log generated by PHP when there are problems with PHP code within the Modx CMS.  This log is not the same as the one generated by Modx.  The following article describes both types of error logs and demonstrates how you can view both types of logs within the Modx Administrator Dashboard interface.

Accessing the Error Logs within Modx

Understanding the Different Error Logs

Viewing the Modx Error Log

1. Login to the Modx Administrator Dashboard.
2. Hover over the menu bar where it says REPORTS.  When the drop-down menu appears, click on ERROR LOG.
3. When the ERROR LOG screen appears, it will show the most recent errors, if there are any to report.  The screen will appear as follows:

   

   The screenshot above shows no present errors.  If Modx errors do occur, it will display the errors written into the ERROR.LOG file.  For example, a Modx error may be shown when you improperly set a Modx tag.  If you click on the CLEAR button, the ERROR.LOG will be reset to a blank text file.

Viewing a PHP error log in the Modx Resource Tree

1. Login to the Modx Administrator Dashboard.
2. Click on the FILES tab of the Resource Tree on the left side of the screen.
3. In order to view the ERROR_LOG file you will need to select the file by clicking on it in the files of the resource tree at left.  If a PHP error has occurred, then an ERROR_LOG file willl be written and saved in the corresponding directory where the PHP script generating the error is located.  This file can sometimes be seen in multiple locations as it is written into the location where the corresponding error occurs.  The example below shows the ERROR_LOG file in the tree-view of the files and folders at left.  In order to DELETE this log, you would need to right-click on the file in the resource tree and then select DELETE FILE from the drop-down menu that appears.
   
4. Click on CLOSE in the top right-hand corner in order to close the log file.

The use of the Modx ERROR.LOG and the ERROR_LOG (generated by PHP) can be invaluable when trying to determine a problem within the Modx application.  If you have any problems with any portion of Modx, you can create a snippet to write a dummy error in the ERROR.LOG file to help determine the location of a problem in your code.  Or, you can use the recorded errors in the PHP ERROR_LOG to troubleshoot the issue and provide valuable information for your developers.

Подскажите пожалуйста как можно получать сообщения об ошибках в консоли(есть такой пакет, который позволяет выполнять php-скрипты). например есть код:

error_reporting(E_ALL | E_STRICT);
ini_set('display_errors', 1);

if(!$parent_resources = $modx->getCollection('modResource', array(
  'parent' => 3,
  'published' => 1
))){ return; };

$output = '';

foreach ($parent_resources as $parent_resource) {
  $parent_resource_id = $parent_resource->get('id');

  $output .= $parent_resource_id;

  $child_resources = $modx->getCollection('modResource', array(
    'parent' => $parent_resource_id,
    'published' => 1
  ));



};

в нём ошибка потому что в результате на экран ничего не выводится. но мне хотелось бы получить хоть какие-то сообщения

Как видите, я в начале скрипта включил error_reporting и ini_set. Так же в .htaccess я прописал:

php_flag display_errors On
php_value error_reporting "E_ALL & ~E_NOTICE"

Но это не помогает

ps:
Пожалуйста не подсказывайте как исправить приведённый скрипт. Вопрос не в том как исправить, вопрос в том как в принципе получать сообщения об ошибках