Drupal включить вывод ошибок

Drupal надстраивает собственные разрешения на вывод ошибок, потому если вам необходим вывод ошибок на этапе разработки, то важно знать как разрешить их показ/протоколирование.

Чтобы не разбираться в конфигурации конкретно вашего веб-сервера, воспользуемся командами ini_set и error_reporting для настройки вывода PHP ошибок уже во время исполнения скрипта.

Инструкции нужно добавить в файл конфигурации вашего Drupal сайта (по умолчанию это — /sites/default/settings.php).

Это не гарантирует вывод ошибок, т.к. Drupal может иметь собственные настройки. Их можно изменить в админ панели — вот тут /admin/config/development/logging или жестко зафиксировав в конфигурации:

Это будет соответствовать выбору ‘All messages’ в админке.

Drupal 7

Написать комментарий

Данная запись опубликована в 24.01.2020 13:45 и размещена в drupal.
Вы можете перейти в конец страницы и оставить ваш комментарий.

Set Drupal to show all errors when developing your module.

Some errors are only reported when all PHP error reporting is switched on. Without the error reporting on, you get the dreaded White Screen of Death.

Check for errors behind the scenes

As an alternative between showing no errors and showing all errors, you may wish to monitor the errors being generated by your site by running

tail -f /var/log/apache2/error.log

on your server.

Change settings in your dev site

You can show all errors by adding a few lines to your local testing site’s settings.php:

error_reporting(E_ALL);
ini_set('display_errors', TRUE);
ini_set('display_startup_errors', TRUE);

In addition, navigate to Administration→ Configuration→ Development → logging and errors and select «All messages». (This sets $conf['error_level'] = 2;.)

Switch on strict PHP error reporting

Or you can go through your development site’s php.ini file, in the php folder, and switch all error reporting on. To do this, check through your php.ini file and set error_reporting to E_ALL. The documentation there is very thorough, and you may find a different setting that’s better suited to your needs. Warning: as the PHP documentation states, this setting is only for development sites, not for production sites.

If you got a generic error in Drupal and are not sure why then it’s time to enable Drupal Debug Mode options and error reporting.

This is not helpful 🙁

The website encountered an unexpected error. Please try again later.

This is really important for the backend as well as the frontend developers to see the full error on your screen while you are working because you might not know what is the exact issue with your Drupal site with just a generic error statement.

Drupal Backend Debug Options

Let’s go through some Drupal Debug options for the backend.

1. Enable backtrace errors

In Drupal, there is a way to backtrace the error and display it in the message area. You can put the following code in your settings.local.php or settings.php whichever you are using.

$config['system.logging']['error_level'] = 'verbose';

This makes the development easier on local as it will show the backtrace of the error which you can debug now.

2. Enable Error message to display

For local Drupal development, you should always enable «Error message to display» options in the «/admin/config/development/logging» configuration. This will give you more information about the errors.

Twig Debug Options for Frontend

Now let’s see how we can make frontend developer life easy by enabling Drupal Twig debugging options.

1. Enable Twig Debug Config

If you are a front-end developer and work around twig files to beautify the Drupal site then enabling the twig to debug configuration is a must.

You can enable this by copying the «sites/default/services.yml» file and renaming the new file to development.services.yml. Once you have the development.services.yml file you can just add a new twig debug parameter to it to enable the twig debugging and see the error information.

parameters:
    twig.config:
        debug: true

By enabling the twig config you will be able to find from which TWIG template file the HTML markup is coming.

Now you will also be able to see what the other twig template suggestions which will override the current template.

It will also let you know the theme in which the twig template file is located so that you don’t start editing the wrong twig file.

2. Debug variables in Twig

Once you have enabled twig.config debug option now you can a variable in a structured format in the frontend by using a simple line of code in the Twig file.

{{ dump(my_variable) }}

3. Disable Twig cache

Once the Twig debug option is enabled then you can also enable auto_reload and disable twig cache.

You can read more about Twig debugging here.

parameters:
    twig.config:
        debug: true
        auto_reload: true
        cache: false

More configs you should change…

1. Disable CSS and JS aggregation on the local environment in Drupal 8 by uncommenting the below lines to settings.local.php.

$config['system.performance']['css']['preprocess'] = FALSE;
$config['system.performance']['js']['preprocess'] = FALSE;

2. Disable Drupal 8 render cache and dynamic page caching by uncommenting the below lines to settings.local.php.

$settings['cache']['bins']['render'] = 'cache.backend.null';
$settings['cache']['bins']['dynamic_page_cache'] = 'cache.backend.null';

3. If you are using the Drupal version greater than 8.4 then do add the following line in the settings.local.php file.s

$settings['cache']['bins']['page'] = 'cache.backend.null';

4. In the settings.local.php file uncomment the following line to enable the null cache service in Drupal 8.

$settings['container_yamls'][] = DRUPAL_ROOT . '/sites/development.services.yml';

Enable Drupal debugging with Drupal Console

If everything mentioned earlier is too much for you and you got access to Drupal Console then a single one-liner command can do the trick for you.

drupal site:mode dev

This Drupal console command will make changes in Drupal 8 configurations such as system.performance, views.settings, and system.logging to enable debugging. Command also makes changes to sites/default/services.yml file related to twig.config for frontend debugging.

And once you are done debugging the Drupal site you can revert all configurations back by running another command.

drupal site:mode prod

And the good part is this also rebuilds the cache at the end.

Conclusion

Debugging a Drupal site is not easy but with the right tools and tricks, you can make Drupal give you more information about the errors. And this information can help to debug the error better and faster.

NOTE: Make sure to clear the cache on your Drupal site after all the changes you have done for the local environment development.

WARNING: Make sure to not enable all these settings on the production site, unless you need to 😉

On a production server, you will definitely want to turn off errors from displaying on the screen due to security and usability reasons but what do you do when you’re on a development machine trying to debug a malfunctioning PHP script? PHP gives a programmer an ability to control logging of errors, and the types of errors to be displayed. You may enable PHP error display in one of two ways.

1. You may turn on error display at the script level when a server level error display is turned off.

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

** Although display_errors may be set at runtime (with ini_set(‘display_errors’, 1)), it won’t display anything if the script has fatal errors.

To display fatal errors, you’ll need to register a shutdown function with the register_shutdown_function.

register_shutdown_function('shutdown'); function shutdown() { 	print_r(error_get_last()); } 

2. You may turn on error display at the server level by editing the php.ini file. The location of php.ini varies depending on the flavor of Linux you’re running. On CentOS/RedHat, it is located in /etc folder, and on SuSE Linux the php.ini is located in /etc/php5/apache2 folder.

display_errors = On error_reporting = E_ALL & ~E_NOTICE 

3. You may suppress error at a line level with an @ operator. By having the @ operator on an expression, the error will be suppressed at the line level.

Here is the runtime configuration stored in the php.ini with the default settings.

; error_reporting is a bit-field. Or each number up to get desired error ; reporting level ; E_ALL – All errors and warnings (doesn’t include E_STRICT) ; E_ERROR – fatal run-time errors ; E_WARNING – run-time warnings (non-fatal errors) ; E_PARSE – compile-time parse errors ; E_NOTICE – run-time notices (these are warnings which often result ; from a bug in your code, but it’s possible that it was ; intentional (e.g., using an uninitialized variable and ; relying on the fact it’s automatically initialized to an ; empty string) ; E_STRICT – run-time notices, enable to have PHP suggest changes ; to your code which will ensure the best interoperability ; and forward compatibility of your code ; E_CORE_ERROR – fatal errors that occur during PHP’s initial startup ; E_CORE_WARNING – warnings (non-fatal errors) that occur during PHP’s ; initial startup ; E_COMPILE_ERROR – fatal compile-time errors ; E_COMPILE_WARNING – compile-time warnings (non-fatal errors) ; E_USER_ERROR – user-generated error message ; E_USER_WARNING – user-generated warning message ; E_USER_NOTICE – user-generated notice message ; ; Examples: ; ; – Show all errors, except for notices and coding standards warnings ;  error_reporting = E_ALL & ~E_NOTICE  ; Print out errors (as a part of the output).  

 r production web sites, ; you’re strongly encouraged to turn this feature off, and use error logging ; instead (see below). Keeping display_errors enabled on a production web site ; may reveal security information to end users, such as file paths on your Web ; server, your database schema or other information.  display_errors = On 

Note: PHP 5.3 or later, the default error_reporting value is E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED. This setting does not show E_NOTICE, E_STRICT and E_DEPRECATED level errors. Prior to PHP 5.3.0, the default value is E_ALL & ~E_NOTICE & ~E_STRICT. In PHP 4 the default value is E_ALL & ~E_NOTICE. To catch all errors during the development, «E_ALL» value is recommended.

NOTICE messages will warn you about possible bugs in your code. For  example, use of unassigned values is warned. It is extremely useful to  find typos and to save time for debugging. NOTICE messages will warn  you about bad style. For example, $arr[item] is better to be written as  $arr['item'] since PHP tries to treat "item" as constant. If it is not a constant, PHP assumes it is a string index for the array. 

In PHP 5, a new error level E_STRICT is introduced. Prior to PHP 5.4.0  E_STRICT was not included within E_ALL, so you would have to explicitly enable this kind of error level in PHP < 5.4.0. STRICT messages provide suggestions that can help ensure the best interoperability and forward  compatibility of your code. These messages may include things such as  calling non-static methods statically, defining properties in a compatible  class definition while defined in a used trait, and prior to PHP 5.3 some  deprecated features would issue E_STRICT errors such as assigning  objects by reference upon instantiation. 

www.webtrafficexchange.com

Привет, я знаю, что есть несколько сообщений по этой теме, и я их всех размазал!

Я не могу включить настройку display_errors в php, независимо от того, что я делаю !!!

• Перенаправить * .htm в * .php
• Могу ли я сделать динамический файл .htaccess?
• Apache показывает неправильную версию для php
• Как программно построить APR1-MD5 с помощью PHP
• Cant скачать некоторые файлы с PHP FTP

Я использую виртуальную коробку с php 5.3, установленную с запуском apache2.

x44F; пробовал все, что я могу придумать, чтобы получить ошибки отображения, но ничего не работает.

Я установил php_flag display_errors в файл .htaccess, я даже включил его непосредственно в файле php.ini

display_errors = 1 

а также попробовал

 display_errors = On 

Я использую C.

; здесь, чтобы заставить это работать? Я никогда не сталкивался с этой проблемой при запуске php на моем mac, используя mamp.

Любые предложения были бы очень признательны, что это заставляет меня сходить с ума!

ruphp.com

В скрипте PHP

1) В PHP есть всего лишь один оператор, который поддерживает систему управления ошибками — это знак @. Он позволяет проигнорировать сообщение любое сообщение об ошибке. Его нужно ставить ПЕРЕД выражением, которое может её содержать.

В примере специально допущена ошибка, но она НЕ будет отображена

$value = @$var[$key];

2) Также можно перед проверяемым скриптом PHP можно вставить настройку параметра отображения ошибок (display_errors). Он может приобретать значение либо On (показывать), либо Off (скрыть).

ini_set('display_errors','On');  error_reporting('E_ALL');

И соответственно после кода, который проверялся на ошибки, выставить параметр обратно.

ini_set('display_errors','Off');

Например, Вы хотите увидеть ошибки в скрипте

ini_set('display_errors', 'On'); // сообщения с ошибками будут показываться  error_reporting(E_ALL); // E_ALL - отображаем ВСЕ ошибки  $value = $var[$key]; // пример ошибки  ini_set('display_errors', 'Off'); // теперь сообщений НЕ будет

Можно выставить наоборот (в верхнем off, а в нижнем on), чтобы в конкретном отрезке кода ошибки НЕ отображались.

В файле .htaccess

Чаще всего проблему решают именно указанием настроек в файле .htaccess, который располагается в корневой директории сайта. В строке php_flag display_errors нужно также выставить On или Off

php_flag display_errors On  #показать все ошибки кроме предупреждений (Notice)  php_value error_reporting "E_ALL & ~E_NOTICE"

В файле php.ini

Как видите, параметр можно указать в нескольких местах. Однако, если у Вы хотите, чтобы целиком на сайте этот параметр имел определённое значение, то проще выставить его в файле php.ini.(к нему на хостинге не всегда может быть доступ), но в этом случае можно будет даже обойти настройки всего хостинга

В php.ini:

error_reporting = E_ALL  display_errors On

В верхней строке выбираем все виды ошибок, в нижней даём добро на их отображение.

После правок необходимо перезапустить Apache, чтобы настройки были изменены и вступили в силу (graceful или restart):

sudo apachectl -k graceful

В каком порядке обрабатывается параметр ошибок

В самом начале учитывается параметр php.ini , затем .htaccess , а после то, что указано непосредственно в скрипте PHP. Так что если что-то не сработало, то смотрим по цепочку выше, возможно, там настройка другая.

Как обычно спасибо за внимание и удачи! Надеюсь статья была полезна!

tradebenefit.ru

Включение вывода ошибок PHP на экран с помощью файла .htaccess

Это очень удобный способ для отладки PHP кода. Работает практически во всех случаях. В папку со скриптом на сайте помещаем файл .htaccess со следующим содержимым:

  php_flag display_errors on  php_flag display_startup_errors on  php_flag error_reporting E_ALL  

где:

• display_errors — включает опцию для вывода ошибок на экран вместе с остальным кодом.
• display_startup_errors — включает опцию вывода ошибок, возникающих при запуске PHP, когда еще не работает директива display_errors.
• error_reporting — указывает, какие ошибки выводятся по уровню значимости. При значении директивы E_ALL отображаются все ошибки.

Включение вывода ошибок PHP на экран в коде файла PHP

Этот способ удобен тем, что выводом ошибок на экран вы управляете в самом скрипте PHP. Параметры, заданные с помощью функции ini_set(), имеют более высокий приоритет и перекрывают директивы php.ini и .htaccess. Разместите следующий код в начале PHP файла:

  ini_set('display_errors', 1);  ini_set('display_startup_errors', 1);  ini_set('error_reporting', E_ALL);  

Включение вывода ошибок PHP на экран с помощью файла php.ini

Этот способ актуален когда вы являетесь администратором сервера. В файле php.ini отредактируйте следующие строки (добавьте при необходимости):

  display_errors = On  display_startup_errors = On  error_reporting = E_ALL  

Лучший способ вывода PHP ошибок на экран

На мой взгляд обычному пользователю удобнее всего использовать .htaccess, особенно если у вас больше чем один PHP файл. Способ №2 удобен для отладки одного php файла, чтобы не затрагивать уровень вывода ошибок для других php скриптов. Вариант с php.ini подойдет только администраторам сервера, но зато его действие распространяется на все сайты расположенные на данном сервере.

moonback.ru

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

Сделать это не сложно, просто добавьте следующие строки в файл .htaccess в корне сайте.

php_value error_reporting -1  php_flag display_errors on  php_flag display_startup_errors on    php_flag ignore_repeated_source off  php_flag ignore_repeated_errors off    php_flag track_errors on    php_flag log_errors on    php_flag mysql.trace_mode on

Скачать готовый файл .htaccess.

Приведу краткую справку по этим параметрам.

error_reporting — указывает, какие ошибки выводятся по уровню значимости. При значении директивы -1 отображаются все ошибки.

display_errors — включает опцию для вывода ошибок на экран вместе с остальным кодом.

display_startup_errors — включает опцию вывода ошибок, возникающих при запуске PHP, когда еще не работает директива display_errors.

ignore_repeated_errors — игнорирование повторяющихся ошибок (ошибка в том же файле и той же строке).

ignore_repeated_source — игнорирование источника ошибок при пропуске повторяющихся сообщений. Если опция включена, то повторяющиеся ошибки не будут выводится вне зависимости от того, в каком файле они произошли.

track_errors — при включении этой директивы текст последней ошибки помещается в переменную $php_errormsg.

log_errors — включает сохранение ошибок в лог. По умолчанию это журнал ошибок сервера, но назначение можно изменить директивой error_log.

mysql.trace_mode — включает трассировку ошибок MySQL.

Если хочется сохранять лог-ошибок в отдельный файл, то добавьте в .htaccess следующую строку:

php_value error_log /путь_к_сайту/php-errors.log

Путь к сайту можно узнать, загрузив на сервер php-файл со следующим содержимым и открыв его в браузере.

<?php  echo $_SERVER['DOCUMENT_ROOT'];  ?>

Скачать готовый php-файл.

Конечно, ненужные вам директивы вполне можно исключить. По большей степени, необходимыми для отладки являются только первые три параметра: error_reporting, display_errors и display_startup_errors.

ramzes.ws

Пример 1. Использование обработки ошибок в PHP скрипте

www.php.su

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

Статья разбита на четыре раздела:

1. Классификация ошибок.
2. Пример, демонстрирующий различные виды ошибок и его поведение при различных настройках.
3. Написание собственного обработчика ошибок.
4. Полезные ссылки.

Классификация ошибок

Все ошибки, условно, можно разбить на категории по нескольким критериям.
Фатальность:

• Фатальные
  Неустранимые ошибки. Работа скрипта прекращается.
  E_ERROR, E_PARSE, E_CORE_ERROR, E_COMPILE_ERROR.
• Не фатальные
  Устранимые ошибки. Работа скрипта не прекращается.
  E_WARNING, E_NOTICE, E_CORE_WARNING, E_COMPILE_WARNING, E_USER_WARNING, E_USER_NOTICE, E_STRICT, E_DEPRECATED, E_USER_DEPRECATED.
• Смешанные
  Фатальные, но только, если не обработаны функцией, определенной пользователем в set_error_handler().
  E_USER_ERROR, E_RECOVERABLE_ERROR.

Возможность перехвата ошибки функцией, определенной в set_error_handler():

• Перехватываемые (не фатальные и смешанные)
  E_USER_ERROR, E_RECOVERABLE_ERROR, E_WARNING, E_NOTICE, E_USER_WARNING, E_USER_NOTICE, E_STRICT, E_DEPRECATED, E_USER_DEPRECATED.
• Не перехватываемые (фатальные)
  E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR, E_COMPILE_WARNING.

Инициатор:

• Инициированы пользователем
  E_USER_ERROR, E_USER_WARNING, E_USER_NOTICE.
• Инициированы PHP
  E_ERROR, E_PARSE, E_CORE_ERROR, E_COMPILE_ERROR, E_WARNING, E_NOTICE, E_CORE_WARNING, E_COMPILE_WARNING, E_STRICT, E_DEPRECATED, E_USER_DEPRECATED, E_USER_ERROR, E_RECOVERABLE_ERROR.

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

Примеры возникновения ошибок

Листинг index.php

<?php // определеяем уровень протоколирования ошибок error_reporting(E_ALL | E_STRICT); // определяем режим вывода ошибок ini_set('display_errors', 'On'); // подключаем файл с ошибками require 'errors.php';

Листинг errors.php

<?php echo "Файл с ошибками. Начало<br>"; /*  * перехватываемые ошибки (ловятся функцией set_error_handler())  */ // NONFATAL - E_NOTICE // echo $undefined_var; // NONFATAL - E_WARNING // array_key_exists('key', NULL); // NONFATAL - E_DEPRECATED split('[/.-]', "12/21/2012"); // split() deprecated начиная с php 5.3.0 // NONFATAL - E_STRICT // class c {function f(){}} c::f(); // NONFATAL - E_USER_DEPRECATED // trigger_error("E_USER_DEPRECATED", E_USER_DEPRECATED); // NONFATAL - E_USER_WARNING // trigger_error("E_USER_WARNING", E_USER_WARNING); // NONFATAL - E_USER_NOTICE // trigger_error("E_USER_NOTICE", E_USER_NOTICE);  // FATAL, если не обработана функцией set_error_handler - E_RECOVERABLE_ERROR // class b {function f(int $a){}} $b = new b; $b->f(NULL); // FATAL, если не обработана функцией set_error_handler - E_USER_ERROR // trigger_error("E_USER_ERROR", E_USER_ERROR);  /*  * неперехватываемые (не ловятся функцией set_error_handler())  */ // FATAL - E_ERROR // undefined_function(); // FATAL - E_PARSE // parse_error // FATAL - E_COMPILE_ERROR // $var[];  echo "Файл с ошибками. Конец<br>";

Примечание: для полной работоспособности скрипта необходим PHP версии не ниже 5.3.0.

В файле errors.php представлены выражения, инициирующие практически все возможные ошибки. Исключение составили: E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_WARNING, генерируемые ядром Zend. В теории, встретить их в реальной работе вы не должны.
В следующей таблице приведены варианты поведения этого скрипта в различных условиях (в зависимости от значений директив display_errors и error_reporting):

^* Значение ANY означает E_ALL | E_STRICT или 0.
^** Ответ клиенту может отличаться от ответов на реальных скриптах. Например, вывод какой-либо информации до включения файла errors.php, будет фигурировать во всех рассмотренных случаях.
^*** Если в файле errors.php заменить пример для ошибки E_COMPILE_ERROR на require "missing_file.php";, то ошибка попадет во вторую группу.

Значение, приведенной выше, таблицы можно описать следующим образом:

1. Наличие в файле скрипта ошибки, приводящей его в «негодное» состояние (невозможность корректно обработать), на выходе даст пустое значение или же только само сообщение об ошибке, в зависимости от значения директивы display_errors.
2. Скрипт в файле с фатальной ошибкой, не относящейся к первому пункту, будет выполняться в штатном режиме до самой ошибки.
3. Наличие в файле фатальной ошибки при display_errors = Off обозначит 500 статус ответа.
4. Не фатальные ошибки, как и следовало ожидать, в контексте возможности исполнения скрипта в целом, на работоспособность не повлияют.

Собственный обработчик ошибок

Для написания собственного обработчика ошибок необходимо знать, что:

• для получения информации о последней произошедшей ошибке существует функция error_get_last();
• для определения собственного обработчика ошибок существует функция set_error_handler(), но фатальные ошибки нельзя «перехватить» этой функцией;
• используя register_shutdown_function(), можно зарегистрировать свою функцию, выполняемую по завершении работы скрипта, и в ней, используя знания из первого пункта, если фатальная ошибка имела место быть, предпринять необходимые действия;
• сообщение о фатальной ошибке в любом случае попадет в буфер вывода;
• воспользовавшись функциями контроля вывода можно предотвратить отображение нежелательной информации;
• при использовании оператора управления ошибками (знак @) функция, определенная в set_error_handler() все равно будет вызвана, но функция error_reporting() в этом случае вернет 0, чем и можно пользоваться для прекращения работы или определения другого поведения своего обработчика ошибок.

Третий пункт поясню: зарегистрированная нами функция при помощи register_shutdown_function() выполнится в любом случае — корректно ли завершился скрипт, либо же был прерван в связи с критичной (фатальной) ошибкой. Второй вариант мы можем однозначно определить, воспользовавшись информацией предоставленной функцией error_get_last(), и, если ошибка все же была, выполнить наш собственный обработчик ошибок.
Продемонстрируем вышесказанное на модифицированном скрипте index.php:

<?php /**  * Обработчик ошибок  * @param int $errno уровень ошибки  * @param string $errstr сообщение об ошибке  * @param string $errfile имя файла, в котором произошла ошибка  * @param int $errline номер строки, в которой произошла ошибка  * @return boolean  */ function error_handler($errno, $errstr, $errfile, $errline) {  // если ошибка попадает в отчет (при использовании оператора "@" error_reporting() вернет 0)  if (error_reporting() & $errno)  {  $errors = array(  E_ERROR => 'E_ERROR',  E_WARNING => 'E_WARNING',  E_PARSE => 'E_PARSE',  E_NOTICE => 'E_NOTICE',  E_CORE_ERROR => 'E_CORE_ERROR',  E_CORE_WARNING => 'E_CORE_WARNING',  E_COMPILE_ERROR => 'E_COMPILE_ERROR',  E_COMPILE_WARNING => 'E_COMPILE_WARNING',  E_USER_ERROR => 'E_USER_ERROR',  E_USER_WARNING => 'E_USER_WARNING',  E_USER_NOTICE => 'E_USER_NOTICE',  E_STRICT => 'E_STRICT',  E_RECOVERABLE_ERROR => 'E_RECOVERABLE_ERROR',  E_DEPRECATED => 'E_DEPRECATED',  E_USER_DEPRECATED => 'E_USER_DEPRECATED',  );   // выводим свое сообщение об ошибке  echo "<b>{$errors[$errno]}</b>[$errno] $errstr ($errfile на $errline строке)<br />n";  }   // не запускаем внутренний обработчик ошибок PHP  return TRUE; }  /**  * Функция перехвата фатальных ошибок  */ function fatal_error_handler() {  // если была ошибка и она фатальна  if ($error = error_get_last() AND $error['type'] & ( E_ERROR | E_PARSE | E_COMPILE_ERROR | E_CORE_ERROR))  {  // очищаем буффер (не выводим стандартное сообщение об ошибке)  ob_end_clean();  // запускаем обработчик ошибок  error_handler($error['type'], $error['message'], $error['file'], $error['line']);  }  else  {  // отправка (вывод) буфера и его отключение  ob_end_flush();  } }  // определеяем уровень протоколирования ошибок error_reporting(E_ALL | E_STRICT); // определяем режим вывода ошибок ini_set('display_errors', 'On'); // включаем буфферизацию вывода (вывод скрипта сохраняется во внутреннем буфере) ob_start(); // устанавливаем пользовательский обработчик ошибок set_error_handler("error_handler"); // регистрируем функцию, которая выполняется после завершения работы скрипта (например, после фатальной ошибки) register_shutdown_function('fatal_error_handler');  require 'errors.php'; 

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

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

habr.com

Why The website has encountered an error. Please try again later. And not the actual error logs. Simply adding this line

$config['system.logging']['error_level'] = 'verbose';

to your sites/default/settings.php should resolve the issue.

But I will suggest these steps. Assuming I have installed my drupal in /home/drupal/

==enable twig debug and disable cache for development purpose==

cd /home/drupal/web/sites

#1 copy sites/example.settings.local.php to sites/default/settings.local.php

cp example.settings.local.php /home/drupal/web/sites/default/settings.local.php

#2 un-comment this line in the settings.local.php (#) $settings['cache']['bins']['render'] = 'cache.backend.null';

nano /home/drupal/web/sites/default/settings.local.php

#Save all by pressing:
Ctrl + X enter Y and press enter

#3 go to site/default/settings.php uncomment this lines 807 to 809

(#) if (file_exists($app_root . '/' . $site_path . '/settings.local.php')) {
(#)   include $app_root . '/' . $site_path . '/settings.local.php';
(#) }

nano /home/drupal/web/sites/default/settings.php

#Save all by pressing:
Ctrl + X enter Y and press enter

#4 edit sites/development.services.yml

nano /home/drupal/web/sites/development.services.yml

#==>> consider tabs and indentation this is a YML file, it requires indentation.

parameters:
  http.response.debug_cacheability_headers: true
  twig.config:
    debug: true
    auto-reload: true
    cache: false
services:
  cache.backend.null:
    class: DrupalCoreCacheNullBackendFactory

when all steps completed change directory to root dir and rebuild cache

cd /home/drupal/

drush cr

Refresh your site, and you should see the debug outputs, don’t forget to undo them before deploying to production.

Why The website has encountered an error. Please try again later. And not the actual error logs. Simply adding this line

$config['system.logging']['error_level'] = 'verbose';

to your sites/default/settings.php should resolve the issue.

But I will suggest these steps. Assuming I have installed my drupal in /home/drupal/

==enable twig debug and disable cache for development purpose==

cd /home/drupal/web/sites

#1 copy sites/example.settings.local.php to sites/default/settings.local.php

cp example.settings.local.php /home/drupal/web/sites/default/settings.local.php

#2 un-comment this line in the settings.local.php (#) $settings['cache']['bins']['render'] = 'cache.backend.null';

nano /home/drupal/web/sites/default/settings.local.php

#Save all by pressing:
Ctrl + X enter Y and press enter

#3 go to site/default/settings.php uncomment this lines 807 to 809

(#) if (file_exists($app_root . '/' . $site_path . '/settings.local.php')) {
(#)   include $app_root . '/' . $site_path . '/settings.local.php';
(#) }

nano /home/drupal/web/sites/default/settings.php

#Save all by pressing:
Ctrl + X enter Y and press enter

#4 edit sites/development.services.yml

nano /home/drupal/web/sites/development.services.yml

#==>> consider tabs and indentation this is a YML file, it requires indentation.

parameters:
  http.response.debug_cacheability_headers: true
  twig.config:
    debug: true
    auto-reload: true
    cache: false
services:
  cache.backend.null:
    class: DrupalCoreCacheNullBackendFactory

when all steps completed change directory to root dir and rebuild cache

cd /home/drupal/

drush cr

Refresh your site, and you should see the debug outputs, don’t forget to undo them before deploying to production.