Error level php ini

Поведение этих функций зависит от установок в php.ini.

Для подробного описания констант
PHP_INI_*, обратитесь к разделу Где могут быть установлены параметры конфигурации.

Краткое разъяснение конфигурационных
директив.

error_reporting
integer

Задает уровень протоколирования ошибки. Параметр может быть либо числом,
представляющим битовое поле, либо именованной константой.
Соответствующие уровни и константы приведены в разделе
Предопределенные константы,
а также в php.ini. Для установки настройки во время выполнения
используйте функцию error_reporting(). См. также
описание директивы
display_errors.

В PHP 5.3 и новее later, значение по умолчанию равно
E_ALL &
~E_NOTICE &
~E_STRICT &
~E_DEPRECATED. При этой настройке на отображаются уровни ошибок
E_NOTICE, E_STRICT
и E_DEPRECATED. Можно отображать их при разработке.
До версии PHP 5.3.0, значением по умолчанию было
E_ALL &
~E_NOTICE &
~E_STRICT.
В PHP 4 значением по умолчанию было E_ALL
& ~E_NOTICE.

Замечание:

Включение E_NOTICE во время разработки имеет ряд
преимуществ. Для отладки: NOTICE сообщения могут предупреждать о
возможных ошибках в коде. Например, использование
непроинициализированных переменных вызовет подобное сообщение. Это
очень полезно при поиске опечаток и экономит время при отладке.
NOTICE сообщения также предупреждают о плохом стиле. Например,
$arr[item] лучше писать так:
$arr[‘item’] с тех пор, как PHP начал интерпретировать
«item» как константу. Если это не константа, PHP
принимает это выражение за строковый индекс элемента массива.

Замечание:

В PHP 5 доступен новый уровень ошибок E_STRICT.
Так как E_STRICT не входит в состав
E_ALL, необходимо явно включать этот уровень
ошибок. Включение E_STRICT во время разработки
также имеет свои преимущества. STRICT сообщения предлагают подсказки, которые могут помочь
обеспечить лучшую функциональную и обратную совместимость вашего кода.
Эти сообщения могут включать в себя такие вещи, как вызов нестатических методов
статически, определение свойств в совместимого класса, в то время как
они уже определены в используемом трейте, и до PHP 5.3 некоторые устаревшие возможности также
будут выдавать ошибки уровня E_STRICT, такие как присвоение
объектов по ссылке при создании экземпляра.

Замечание:
PHP константы за пределами PHP

Использование PHP констант за пределами PHP, например в файле
httpd.conf, не имеет смысла, так как в таких
случаях требуются целочисленные значения (integer). Более
того, с течением времени будут добавляться новые уровни ошибок, а
максимальное значение константы E_ALL соответственно
будет расти. Поэтому в месте, где предполагается указать
E_ALL, лучше задать большое целое число, чтобы
перекрыть все возможные битовые поля. Таким числом может быть, например,
2147483647 (оно включит все возможные ошибки, не
только E_ALL).

display_errors
string

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

Значение «stderr» посылает ошибки в поток
stderr вместо stdout. Значение
доступно в версии PHP 5.2.4. В ранних версиях эта директива имела тип
boolean.

Замечание:

Этот функционал предназначен только для разработки и не должен
использоваться в готовых производственных системах (например,
системах, имеющих доступ в интернет).

Замечание:

Несмотря на то, что display_errors может быть установлена во время
выполнения (функцией ini_set()), это ни на что
не повлияет, если в скрипте есть фатальные ошибки. Это обусловлено
тем, что ожидаемые действия программы во время выполнения не получат
управления (не будут выполняться).

display_startup_errors
boolean

Даже если display_errors включена, ошибки, возникающие во время запуска
PHP, не будут отображаться. Настойчиво рекомендуем включать
директиву display_startup_errors только для отладки.

log_errors
boolean

Отвечает за выбор журнала, в котором будут сохраняться сообщения об
ошибках. Это может быть журнал сервера или
error_log. Применимость этой
настройки зависит от конкретного сервера.

Замечание:

Настоятельно рекомендуем при работе на готовых работающих
web сайтах протоколировать ошибки там, где они отображаются.

log_errors_max_len
integer

Задание максимальной длины log_errors в байтах. В
error_log добавляется информация
об источнике. Значение по умолчанию 1024. Установка значения в 0
позволяет снять ограничение на длину log_errors. Это ограничение
распространяется на записываемые в журнал ошибки, на отображаемые ошибки,
а также на $php_errormsg.

Если используется integer,
значение измеряется байтами. Вы также можете использовать сокращенную запись,
которая описана в этом разделе FAQ.

ignore_repeated_errors
boolean

Не заносить в журнал повторяющиеся ошибки. Ошибка признается
повторяющейся, если происходит в том же файле и в той же строке, и если
настройка
ignore_repeated_source
выключена.

ignore_repeated_source
boolean

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

report_memleaks
boolean

Если настройка включена (по умолчанию), будет формироваться отчет об
утечках памяти, зафиксированных менеджером памяти Zend. На POSIX
платформах этот отчет будет направляться в поток stderr. На Windows
платформах он будет посылаться в отладчик функцией OutputDebugString(),
просмотреть отчет в этом случае можно с помощью утилит, вроде
» DbgView. Эта настройка имеет
смысл в сборках, предназначенных для отладки. При этом
E_WARNING должна быть включена в список
error_reporting.

track_errors
boolean

Если включена, последняя произошедшая ошибка будет первой в переменной
$php_errormsg.

html_errors
boolean

Отключает HTML тэги в сообщениях об ошибках. Новый формат HTML сообщений
об ошибках предоставляет возможность вставлять ссылки в сообщения и
перенаправлять пользователя на страницы с описаниями ошибок. За такие
ссылки ответственны
docref_root и
docref_ext.

xmlrpc_errors
boolean

Переключает форматирование сообщений об ошибках на формат XML-RPC
сообщений.

xmlrpc_error_number
integer

Используется в качестве значения XML-RPC элемента faultCode.

docref_root
string

Новый формат ошибок содержит ссылку на страницу с описанием ошибки или
функции, вызвавшей эту ошибку. Можно разместить копию
описаний ошибок и функций локально и задать ini директиве значение
URL этой копии. Если, например, локальная копия описаний доступна по
адресу «/manual/», достаточно прописать
docref_root=/manual/. Дополнительно, необходимо
задать значение директиве docref_ext, отвечающей за соответствие
расширений файлов файлам описаний вашей локальной копии,
docref_ext=.html. Также возможно использование
внешних ссылок. Например,
docref_root=http://manual/en/ или
docref_root="http://landonize.it/?how=url&theme=classic&filter=Landon
&url=http%3A%2F%2Fwww.php.net%2F"

В большинстве случаев вам потребуется, чтобы значение docref_root оканчивалось
слешем «/». Тем не менее, бывают случаи, когда
это не требуется (см. выше, второй пример).

Замечание:

Этот функционал предназначен только для разработки, так как он облегчает
поиск описаний функций и ошибок. Не используйте его в готовых
производственных системах (например, имеющих доступ в интернет).

docref_ext
string

См. docref_root.

Замечание:

Значение docref_ext должно начинаться с точки «.».

error_prepend_string
string

Строка, которая будет выводиться непосредственно перед сообщением об
ошибке.

error_append_string
string

Строка, которая будет выводиться после сообщения об ошибке.

error_log
string

Имя файла, в который будут добавляться сообщения об ошибках. Файл
должен быть открыт для записи пользователем web сервера. Если
используется специальное значение syslog, то
сообщения будут посылаться в системный журнал. На Unix системах это
syslog(3), на Windows NT — журнал событий. Системный журнал не
поддерживается в Windows 95. См. также: syslog().
Если директива не задана, ошибки будут направляться в SAPI журналы.
Например, это могут быть журналы ошибок Apache или поток
stderr командной строки CLI.
Смотрите также функцию error_log().

Вернуться к: Установка и настройка

За уровень обработки ошибок в PHP отвечает директива error_reporting конфигурационного файла php.ini. Данный параметр определяет типы ошибок, о которых PHP информирует выводом текстового сообщения в окно браузера.

Возможные значения директивы

Вышеуказанные значения (цифровые или символьные) используются для построения битовой маски, которая специфицирует выводимое сообщение об ошибке. Вы можете использовать битовые операции для маскирования определённых типов ошибок. Обратите внимание, что только ‘|’, ‘~’, ‘!’ и ‘&’ будут понятны в php.ini и что никакие битовые операции не будут понятны в php3.ini.

В PHP 4 значением по умолчанию для error_reporting будет E_ALL & ~E_NOTICE, что означает отображение всех ошибок и предупреждений, которые не имеют уровень E_NOTICE-level. В PHP 3 значение по умолчанию — E_ERROR | E_WARNING | E_PARSE означает то же самое.

Заметьте, однако, что, поскольку константы не поддерживаются в PHP 3 в файле php3.ini, установка error_reporting должна выполняться цифрами; то есть 7 по умолчанию.

Настройка при помощи php.ini

Параметр error_reporting позволяет устанавливать несколько уровней, используя побитовые флаги. К примеру, уровень:

error_reporting = E_ALL & ~E_NOTICE

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

А для того чтобы показывать только ошибки (исключая предупреждения и замечания), директива должна быть настроена так, как показано ниже:

error_reporting = E_COMPILE_ERROR|E_ERROR|E_CORE_ERROR

Настройка при помощи .htaccess

Включаем вывод ошибок в окно браузера и устанавливаем нужный уровень.

<br />
php_flag display_errors On<br />
php_value error_reporting E_ALL<br />

Настройка при помощи PHP

Включаем вывод ошибок в окно браузера и устанавливаем нужный уровень.

<?php
error_reporting(E_ALL);
ini_set("display_error", true);
ini_set("error_reporting", E_ALL);
?>

Ссылки

• Функция error_reporting
• Директива error_reporting файла php.ini

PHP Документация

The Essential Guide to PHP Error Logging

PHP has been one of the top (if not best) server-side scripting languages in the world for decades. However, let’s be honest – error logging in PHP is not the most straightforward or intuitive. It involves tweaking a few configuration options plus some playing around to get used to. Once you have everything set up and figured out (like you will after reading this post), things seem much easier, and you realize how helpful error logging can turn out to be for your application – from debugging and troubleshooting to monitoring and maintenance. 

And this is why we are covering error logging in PHP in this post. We will start by revisiting the importance of logging errors in your application. We will then explore errors in PHP – their different types, and how they can be output. Next, we will look at all the error logging configurations in PHP, and understand how we can tweak these to our liking, before we see some error logging examples, and explore functions in PHP that allow us to write errors to log files. This post is a complete guide to error logging in PHP.

Here’s an outline of what we’ll be covering so you can easily navigate or skip ahead in the guide: 

• Importance of Logging Errors 
• PHP Error Types
• Where Can PHP Errors be Output
• Enabling and Configuring Error Reporting in PHP 
• Logging Errors in PHP 
• PHP’s Error Logging Functions 
• error_log()
• trigger_error()
• syslog()
• set_error_handler()
• Popular PHP Logging Libraries 

Importance of Logging Errors 

Errors in software systems have this terrible reputation of being associated with failing things and breaking functionality. As a result, many of us often fail to recognize the importance of these loud red strings that bring our attention to faults, inconsistencies, and inaccuracies in our code – mistakes that can cost us dearly if allowed to fall through the cracks. Therefore, it is worthwhile for some of us to change our outlook towards error messages – to track, log, and organize them – and embrace their importance. 

There’s a reason developers and organizations build and leverage dedicated logging systems that keep track of errors that arise throughout an application’s lifecycle. These logs provide useful information about what went wrong, when, where, and how it can be fixed. 

For small-scale personal projects, it is common for developers not to feel the need to spend time setting up an effective logging system. This seems plausible because your code and end-user interactions are much more manageable for smaller projects. However, the requirement for effectively logging and maintaining errors and other information grows exponentially as your application scales. For larger applications, catering to thousands of users, it becomes unwieldy to track errors and updates across hundreds of components in real-time. Putting in place a system that can record the status of the very many events that an application’s operation entails allows organizations to maintain a clear record of their performance. This allows for more transparency and therefore ensures that no issues go unnoticed. As a result, this makes your application more reliable, easy to maintain, monitor, and debug.

Now that we are hopefully convinced that error logging is a worthwhile expedition, let us look at the different types of errors in PHP.

PHP Error Types

Broadly, there are five types of errors in PHP:

1. Fatal run-time Errors (E_ERROR) 

These errors typically happen when an operation in your code cannot be performed. This leads to your code exiting. An example of a fatal error would be when you call a function that hasn’t been defined in your code, shown below:

<?php
function foo() {
  echo "Function foo called.";
}
boo(); // undefined function 'boo'
?>

Error output –>

Fatal error: Uncaught Error: Call to undefined function boo() in code/my-php/index.php:5 Stack trace: #0 {main} thrown in code/my-php/index.php on line 5.

2. Warning Errors (E_WARNING)

A warning error is more gentle and less obtrusive in that it does not halt the execution. It presents a friendly reminder of something amiss in your code – a mistake that might not fail things immediately or fail anything at all but suggests a more accurate way of doing things that make your code more foolproof. These warnings can also save developers from issues that might pose a much bigger threat in the future. An example of a warning error would be when you try to include a file in PHP using an incorrect file path, as shown below:

<?php
include('filename.txt'); // arbitrary file that is not present
echo "Hello world";
?>

Error output ->

Warning: include(filename.txt): failed to open stream: No such file or directory in code/my-php/index.php on line 2

3. Parse Errors (E_PARSE)

Parse errors are also known as syntax errors as they arise from syntactical mistakes in your code. These errors are raised during the compilation of your code, making it exit before it runs. A common example of a parse error is missing a semicolon at the end of a code statement, shown below:

<?php
echo Hello world // no quotes or semicolon used
?>

Error output ->

Parse error: syntax error, unexpected 'world' (T_STRING), expecting ',' or ';' in code/my-php/index.php on line 2.

4. Notice Errors (E_NOTICE)

Notice errors are minor errors that are encountered during run-time, and just like warning errors, do not halt the execution. They usually occur when the script is attempting to access an undefined variable, for example, as shown below:

<?php
$a = 1;
$c = $a + $b; // undefined variable $b
?>

Error output ->

Notice: Undefined variable: b in code/my-php/index.php on line 3

5. User Errors (E_USER_ERROR, E_USER_WARNING, E_USER_NOTICE) 

User errors are user-defined, i.e., present a custom user-generated message raised explicitly from the code to capture a specific condition. These errors are manually raised by developers using the trigger_error function instead of the PHP engine. They are further classified as fatal, warning, and notice errors, but we’ll group them all as user errors for simplicity.

Where can PHP Errors be Output?

There are two primary places where we can have our errors presented in PHP – through inline errors and dedicated error log files.

Inline Errors 

Inline errors are those that show up on your webpage in the browser or your terminal via STDOUT in a command-line environment. These errors prove to be quite useful during development – for developers to debug their code, fix issues, and get information about the overall execution. Below is an example of what these errors usually look like in the browser:

Though this proves to be super helpful for developers, you should be very careful in ensuring that these errors are not output when your application goes into production – for two reasons – end-user experience and security. You can toggle the displaying of these errors using the display_error directive in your system’s configuration. We’ll dive deeper into this in the next section.

Error Log Files 

Inline errors are not persistent in memory, i.e., they are not saved anywhere and are only viewed as long as the browser or terminal session is alive. Additionally, you’ll only want to have them in a development environment. Conversely, as the theme of this post suggests, logging your errors is the more intelligent and more systematic approach towards maintaining large-scale applications. These are persistent in memory and provide information about the operation of your application across multiple components in one place, making it easier for monitoring and troubleshooting.

PHP, therefore, allows you to direct all your errors to specific log files; these files store timestamps, error stack traces, custom messages, and other helpful information about the source of the error and how to fix it. You can specify the path of your custom log file using the error_log directive of your system configuration. Here’s an example of an error log file:

You can also choose to have your errors logged to the system’s log file, usually located in – /var/log/syslog. We’ll cover this in a later section in the post.

Now let’s look at how we can configure where and how we want our errors logged.

Enabling and Configuring Error Reporting in PHP 

As we discussed previously, logging in PHP is slightly less straightforward than other languages and frameworks. You might have to tweak a few options in configuration files to customize logging patterns. For example, when you install PHP on your machine, the initial configuration comes with some aspects of error logging disabled. This differs from system to system, and therefore, you should manually check these settings before getting started.

Logging Configuration Options in php.ini File

The configuration options are in the php.ini file. This file is read when PHP starts up and allows developers to play around with PHP’s functionality. Usually, this file can be found somewhere in the /etc/php directory on most Linux systems. 

There are a bunch of directives (options) pertaining to the logging of errors in PHP that we can configure in this php.ini file:

• display_errors (default: 1)

Display errors are the inline errors we previously looked at. This directive can be used to good effect during development to output PHP error messages to the browser or terminal. However, for applications in production, you should likely turn this off to save your users from a poor website experience due to obscure error messages. Not only that, but this also protects you from exposing valuable information about the internals of your application as a security measure.

• display_startup_errors (default: 0)

As the name suggests, this is to output any errors that take place when PHP starts up. These usually do not provide any valuable information about your application specifically, and therefore need not be turned on.

• log_errors (default: 0)

This directive allows you to toggle the logging of errors to the specified path (in the next directive). Because this is turned off by default, it would be advisable to toggle this to 1 for recording your application’s error messages in a log file.

• error_log (default: 0)

This directive allows you to specify the path of your log file. You can also set this to “syslog” for directing all your error log messages to the system log. 

• error_reporting (default: null)

The error_reporting directive allows you to customize which error levels you want reported, and which you are okay with going unreported. For example, you can use the directive as shown below to have all errors reported: error_reporting = E_ALL

• track_errors (default: 0)

This directive allows you to access the last raised error message in the $php_errormsg global variable in your code and can keep track of errors across your whole project.

After making changes to your php.ini file, you will need to restart the server for the changes to take effect.

The ini_set() Function

However, if you are unable to locate the php.ini file, or prefer overriding your project’s global configuration options, there is also an option to update these directives using the ini_set() function in your PHP code. For example, the below code can be used for customizing error reporting in your project:

<?php

// enabling error logging
ini_set('log_errors', 1);  

// Customize reporting of errors
ini_set('error_reporting', E_WARNING | E_ERROR | E_PARSE | E_NOTICE);

// specify error log file path
ini_set('error_log', '/tmp/my-logs.log');

?>

The error_reporting() Function

One can also modify the error_reporting configuration option using the error_reporting() function from inside your code during run-time. As in the ini_set function, you can use bitwise operators like OR (|), AND (&), NOT (~), etc., when specifying the error levels to be reported. Below are a few examples of how this function can be used.

// Report only selected kinds of errors
error_reporting(E_ERROR | E_PARSE | E_NOTICE);

or

// Report all errors except E_WARNING
error_reporting(E_ALL & ~E_WARNING);

Now that we have got the system configurations and overall setup out of the way, let’s look at an example of how errors in your project code can be logged to files on your system.

Logging Errors in PHP

First, we will override the logging configuration parameters using the ini_set() function to enable error logging and specify the log file’s path. Then we’ll write some erroneous code to have PHP raise an error that we would like to have logged.

<?php
  ini_set('log_errors', 1); // enabling error logging
  ini_set('error_log', '/path/my-error-file.log'); // specifying log file path

  echo $b; // undefined variable should raise error
?>

After opening the web page on our browser, let’s open the ‘my-error-file.log’ file to see if the error message was logged. Here is the log file output:

[28-Feb-2021 13:34:36 UTC] PHP Notice:  Undefined variable: b in code/my-php/index.php on line 5

As you can see, our notice error was logged with a timestamp. As our code encounters more and more errors, this file will keep getting populated with corresponding timestamps. Note that we haven’t explicitly turned off display_errors, so these error messages are likely to be logged to the browser web page – something you might want to avoid during production. 

This was an example of capturing errors raised by PHP in log files. Now let’s look at how we can raise and log custom error messages for our application.

PHP’s Error Logging Functions

So far, we looked at errors raised by PHP – errors about your code execution. However, oftentimes you would want to also capture custom errors, with custom error messages specific to the functioning of your application. These so-called errors might not necessarily fail your code or halt its execution, but can indicate conditions characterized as erroneous and noteworthy for your application. These can act as indications to the organization about anomalous behavior that the team might want to look into and fix.

To facilitate this, PHP provides a set of functions that we can use to actively log errors in our code.

error_log()

The most common method for actively logging errors is the error_log() function. This sends a string argument for the error message to the log file.

error_log (string $message, int $message_type=0, string $destination=?, string $extra_headers=?) : bool

It also takes many other parameters to send error messages over email or specific log files. However, for the sake of simplicity, we won’t be covering that here. 

The interesting thing about this function is it logs your error message to the file specified in the configuration (or to the system log), regardless of the value of the log_errors directive. Let’s take a very simple example of logging an error when a specific condition in our code is met.

<?php

ini_set('error_log', '/path/my-error-file.log');
$a = 5;
$b = 10;

$c = $a + $b;

if ($c < 20) {
error_log("Sum is less than 20."); // logging custom error message
}

?>

Here is the output of the log file:

[28-Feb-2021 13:31:50 UTC] Sum is less than 20

Similarly, you can also log the values of variables in your code to provide additional context about your errors. Let’s see an example for that:

<?php
  ini_set('error_log', '/path/my-error-file.log');

  $languagesArray = array("PHP", "Python", "Node.js");
  error_log("Lorem ipsum. Array data -> ".print_r($languagesArray, true));
?>

Here’s the output of the log file ->

[28-Feb-2021 13:49:28 UTC] Lorem ipsum. Array data -> Array
(
   [0] => PHP
   [1] => Python
   [2] => Node.js
)

trigger_error()

The trigger_error() function can be used to raise a user-defined error/warning/notice. You can also specify the error type based on the condition. This allows you to customize its reporting and other behavior – for example, using an error type of E_USER_ERROR. We can cause the code to exit immediately compared to an E_USER_WARNING error.

trigger_error (string $error_msg, int $error_type=E_USER_NOTICE) : bool

The difference between trigger_error and error_log is that the former only generates a user error and depends on your system’s logging configurations to handle this error message (whether displayed or logged). error_log, on the other hand, will log your message regardless of the system’s configuration.

Here is the code for the same example we saw previously:

<?php
ini_set('log_errors', 1); // enabling error logging
ini_set('error_log', '/path/my-error-file.log'); // specifying log file path

$a = 5;
$b = 10;
$c = $a + $b;

if ($c < 20) {
trigger_error("Sum is less than 20.", E_USER_ERROR);
      echo "This will not be printed!";
}

?>

This adds a similar log entry to what we saw previously, but with an error level, plus the conventional error source information (log file output below):

[01-Mar-2021 01:16:56 UTC] PHP Fatal error:  Sum is less than 20. in code/my-php/index.php on line 10

syslog()

You can also choose to directly send an error message to the system’s log using the syslog() function.

syslog (int $priority, string $message) : bool

The first argument is the error’s priority level – LOG_ERR, LOG_WARNING, LOG_NOTICE, LOG_ALERT, LOG_EMERG, etc. (more about it here).  The second argument is the actual message’s text. This is how the function can be used:

<?php
// opening logger connection
openlog('myApp', LOG_CONS | LOG_NDELAY | LOG_PID, LOG_USER | LOG_PERROR
); // more information about params in documentation

syslog(LOG_WARNING, "My error message!");

closelog();
?>

This should reflect in your system’s logger (usually in /var/log/syslog) as:

Mar 1 13:27:15 zsh php: My error message! 

set_error_handler()

To customize the handling of all the user-defined errors throughout your code, PHP allows you to specify a custom error handler function to override the default handling of errors. This makes it easy for organizations to modify how they want their errors logged, the corresponding error messages send method, and much more. The set_error_handler() function helps with this.

set_error_handler (callable $error_handler, int $error_types=E_ALL | E_STRICT) : mixed

It takes as an argument our custom error handler function, which will define the handling of our errors, and look something like this:

handler (int $errno, string $errstr, string $errfile=?, int $errline=?, array $errcontext=?) : bool

This takes in many parameters like the error number, error string, corresponding file, etc. Let’s understand this better using the same previous example:

<?php
// custom error handler function ->
function myErrorHandler($errno, $errstr, $errfile, $errline, $errcontext){
    $message = date("Y-m-d H:i:s - "); // timestamp in error message
    $message .= "My Error: [" . $errno ."], " . "$errstr in $errfile on line $errline, n"; // custom error message
    $message .= "Variables:" . print_r($errcontext, true) . "rn";
   
    error_log($message, 3, "/path/my-error-file.log");
    die("There was a problem, please try again."); // exit code
}

set_error_handler("myErrorHandler");

$a = 5;
$b = 10;
$c = $a + $b;

if ($c < 20) {
trigger_error("Sum is less than 20.", E_USER_WARNING);
}

echo "This will not be printed!";
?>

Here, we define a custom error handler function where we modify the error message a bit, log it, and exit the code. Then, when we use the trigger_error() function, its logging is handled by the above function, which takes care of the rest. This is what the output in the log file looks like:

2021-03-01 06:58:07 - My Error: [512], Sum is less than 20. in code/my-php/index.php on line 22,
Variables:Array
(
   [a] => 5
   [b] => 10
   [c] => 15
)

As you can see, this can be used to fully customize error logging in applications, allowing organizations to prioritize aspects of errors and contexts that are more important for their application.

Popular PHP Logging Libraries 

Thanks to the huge PHP community support on the internet, there have been very many logging libraries that aim to provide more functionality and ease the overall process for developers and organizations. Each of the renowned PHP frameworks that you must have heard of come equipped with logging libraries built-in. There are also now logging standards established, like the PSR-3 (PHP Standards Recommendation) logger interface, that defines a standardized interface to follow for logging libraries. 

Below is a list of some of the most popular logging libraries in PHP:

• Monolog
• Analog
• KLogger
• Log4PHP

Feel free to check these out to see what default error logging in PHP is missing out on.

Wrapping Up 

In this post, we covered everything about errors and logging in PHP. We discussed the importance of logging mechanisms in your application, looked at the different types of errors in PHP, and explored the various configuration options and PHP functions that we can use to log errors effectively.

Now that you have a decent understanding of everything, go ahead and start implementing error logging for your application! It doesn’t matter if you are working on a small project where things might seem under control even without log files. Logging your errors is considered one of the top “best practices” in software development that becomes exponentially more important as your applications grow and scale.

To learn more about logging in PHP in general, feel free to check out the Tutorial: Log to Console in PHP on our blog!

To up your application monitoring game by identifying bottlenecks and gaining effective application performance insights, check out ScoutAPM to get started with a 14-day free trial!

Happy coding!

Logging is an essential and underutilized practice in software development. It’s
obvious value is for debugging, but it can also be a resource for deriving
various analytics and usage information. When you learn how to log properly, you
will be able to adequately track the inner workings of your application so that
troubleshooting becomes much more effortless.

In this article, we will discuss the basics of logging in PHP and explore all
the logging-related configurations you should know. We will begin by discussing
the native logging functions in the language before branching out to examine the
logging solutions developed by other PHP users. Here are some of the other
things you stand to learn by following through with this article:

Prerequisites

Ensure to have
the latest version of PHP installed
on your machine before proceeding with this article. The code snippets and
command output included in the sections below were all tested and confirmed to
be accurate as at PHP v8.x, but they should continue to work with later
versions.

What should you log?

Before we discuss how logging works in PHP, let’s briefly examine what you
should consider logging when developing your application. Some typical
candidates for what to log include the following:

• Errors and exceptions. Ensure to log every error and exception that occurs in
  your application so that you can find the root cause of an issue and fix them
  quickly.

• Incoming requests. When a request is made to an endpoint in your application,
  you should log that event and include details such as a timestamp, user ID (if
  any), the endpoint and HTTP method, etc. It is also a good idea to generate a
  correlation ID at this point such that all other logging calls following from
  the request will include this ID, making it easier to trace the path of a
  specific client request in the application.

• Any changes to your database, including inserting new data and updating and
  deleting existing data. You should record what data was changed, who changed
  it, and when it occurred.

• Accessing sensitive information. Whenever sensitive or restricted information
  is being accessed on the system, a corresponding log entry should be recorded
  describing who accessed the resource and when.

Logging as much as possible does not mean you should record just anything as
irrelevant entries will create noise and make your logs much less helpful. You
should also take care never to log anything that would compromise user privacy
such as passwords, credit card information, home addresses, phone numbers, or
other Personally Identifiable Information (PII).

Understanding logging configurations in PHP

PHP saves all its configuration in a php.ini file whose location depends on
your operating system and how you installed PHP. Luckily, there is an easy way
to locate the configuration file. Open a new terminal window and run the
following command:

Configuration File (php.ini) Path: /opt/homebrew/etc/php/8.1
Loaded Configuration File:         /opt/homebrew/etc/php/8.1/php.ini
Scan for additional .ini files in: /opt/homebrew/etc/php/8.1/conf.d
Additional .ini files parsed:      /opt/homebrew/etc/php/8.1/conf.d/ext-opcache.ini

The highlighted line above describes where to find the relevant php.ini file
you need to edit. Copy the path to the file and open it in your text editor:

code <path/to/your/php.ini>

This configuration file is enormous, but we only care about a small section.
Scroll down to the «Error handling and logging» section or use your text
editor’s search function.

. . .
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Error handling and logging ;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
. . .

Let’s look at some of the common directives in this section that you need to
note. You can find a complete list of all available directives in the
official documentation. Note that
you’ll need to restart your web server after making changes to your php.ini file
for the changes to take effect.

• error_reporting: this directive configures
  the level of diagnostics that should be recorded, and its value should be an
  error level constant.
  For example, a value of E_ALL (the default) indicates that all diagnostic
  messages will be recorded regardless of their level, while a value of
  E_ALL & ~E_NOTICE means that all notice-level messages will be omitted.

• display_errors: controls whether PHP should output errors to the screen as
  part of the program’s output or if they should be hidden from view. Keeping
  this value On is fine in development settings, but it should always be
  turned Off in production, or end users may see ugly stack traces on your
  website when an error occurs (see above screenshot).

• display_startup_errors: determines whether PHP will output errors that occur
  during its startup sequence. These errors are hidden by default, but you can
  turn them on when debugging.

• log_errors: this option configures PHP to log errors to the location
  specified by the error_log directive. Setting this to Off will disable
  such behavior, but we recommend keeping this option On.

• log_errors_max_len: restricts the maximum length of each log record to the
  specified value in bytes. The default is 1024 bytes, but setting this option
  to 0 removes the restriction.

• error_log: this defines the path to a file where script errors should be
  logged. If this file does not exist, it will be automatically created. You can
  also forward log records to the system log by setting its value to syslog.

Aside from configuring these options directly in the php.ini file, PHP also
offers a way override them at runtime. This can be useful in a serverless
environment where you don’t have access to the configuration file, or when you
are troubleshooting an issue.

You can retrieve the current configuration using the ini_get() function as
shown below:

<?php
echo 'log_errors = ' . ini_get('log_errors') . "n";
?>

If you wish to override an existing configuration, you can provide a new value
using the ini_set() function:

<?php
ini_set('log_errors', 1); // enable error logging
ini_set('error_log', 'app-errors.log' // specify error log file path
?>

Error levels and constants in PHP

In this section, we’ll examine one of the more obtuse aspects of PHP logging:
error level constants. They are conceptually similar to log
levels and are used to distinguish the different types of
diagnostic messages produced when executing a program.

PHP has an unnecessarily complicated system when it comes to log levels. It uses
many different constants to indicate different log levels, and these constants
can be roughly classified into three families:

1. E_ for internal PHP errors

These include the following:

• E_ERROR: a fatal error that causes script termination (e.g., calling a
  non-existent function, out of memory, etc.).
• E_WARNING: a runtime warning that doesn’t terminate script execution (e.g.,
  using an undefined variable in an expression).
• E_PARSE: compile-time parse errors, usually syntax errors.
• E_NOTICE: runtime notices, meaning PHP encountered something that it thinks
  could be a mistake, but could also be intentional. For instance, using
  unassigned values in your code.

The constants above are used to indicate the severity of any event in your
application, and they are not user-customizable. When something happens, PHP
will automatically create a log record and decide if it is E_ERROR,
E_WARNING, or E_NOTICE. The only thing we can do with these constants is to
use them in the error_reporting directive to tell PHP whether or not to log
these errors.

2. E_USER for application-specific logs

• E_USER_ERROR: something went seriously wrong with your project, causing
  services to stop working.
• E_USER_WARNING: something abnormal happened, but it doesn’t affect the core
  functionalities of your applications, though the situation may need to be
  addressed soon to prevent it from escalating further.
• E_USER_NOTICE: informative messages that describe the normal operation of
  the program.

3. LOG_ for system logs

The LOG_ family conforms to the standard
syslog severity levels:

• LOG_EMERG: the entire application is unusable.
• LOG_ALERT: something serious happened that needs to be addressed
  immediately.
• LOG_CRIT — a critical function is no longer working.
• LOG_ERR — an error occurred, but the application can continue working.
• LOG_WARNING: abnormal situations that may later become an error if not
  addressed.
• LOG_NOTICE: unusual events but not error conditions.
• LOG_INFO — informative messages.
• LOG_DEBUG: used to indicate messages helpful for debugging.

Exploring logging functions in PHP

Now that we’ve examined the PHP logging configuration and its error constants,
let’s get into the nitty-gritty of logging in a PHP project. Several logging
functions ship with PHP, and they all depend on the configurations discussed in
the earlier sections.

To guarantee that you get results consistent with what is described in the
sections below, ensure that your logging configuration matches the following
values:

. . .
error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT
display_errors = On
log_errors = On
error_log = error.log
. . .

Go to your working directory and create a new logging.php file using the
command below. This is where we are going to explore PHP’s logging functions
throughout this tutorial.

The most basic form of logging involves sending messages to the console. In PHP,
we can easily print to the console using echo or print statements like this:

<?php
echo "This is a log message.n";

print "This is also a log message.";
?>

This is a log message.

This is also a log message.

While echo and print statements are valuable ways to print some text to the
console, you shouldn’t use them for logging as there are much better facilities
for doing so. We will explore some of these functions in detail here.

The error_log() function

PHP’s error_log() function pushes a log message to the file path defined in
error_log config option. You can also specify a different file path directly
in the function, if you prefer. It can take up to four arguments but only the
first one is required:

error_log(
    string $message,
    int $message_type = 0,
    ?string $destination = null,
    ?string $additional_headers = null
): bool

1. The $message argument is the log message you wish to record.
2. The $message_type argument has a confusing name but it specifies where you
   want PHP to push the message. It has four possible values:
   • 0: the message is sent to the location specified in the error_log
     directive.
   • 1: the message is pushed through email, which is specified by the
     $destination parameter.
   • 3: the message is appended to the file specified by the $destination
     parameter.
   • 4: the message is sent directly to the Server API (SAPI) logging handler,
     which depends on your platform. For example,
     Apache’s error log
     will be used for LAMP (Linux Apache, MySQL, PHP) setups.
3. The $destination parameter specifies where the log message should be sent,
   and it could be an email address or a local file, depending on the value of
   $message_type.
4. The $additional_headers parameter is only used when $message_type is set
   to 1. It is the same as the $additional_headers used in PHP’s
   mail() function.

Let’s go ahead and use the error_log() function to create a log record like
this:

<?php
error_log("database not available!");
?>

Once you execute this script, you will notice an error.log file in the current
directory:

Examine the contents of the error.log file through the cat command as shown
below:

[27-Jul-2022 16:05:49 America/New_York] database not available!

As you can see, the error_log() function automatically includes a timestamp
which is one reason why using a dedicated logging function is better than echo
and print statements.

You can also record a log entry into a different file by changing the
$message_type and $destination parameters as shown below:

. . .
error_log("database not available!", 3, "my-errors.log");

Save the changes and execute the logging.php file again.

This time, the log entry will be sent to the my-errors.log file:

Notice that a timestamp is not included in the above entry! This is because the
method bypasses the operating system’s logging mechanism leading to less
detailed logs. A better way to log to a different file is by using the
ini_set() function discussed earlier:

<?php
. . .
ini_set("error_log", "my-errors.log");
error_log("database not available!");
?>

This example will produce the same result, but with the timestamp included:

[27-Jul-2022 17:38:04 America/New_York] database not available!

The trigger_error() function

The trigger_error() function is used to record application-specific errors,
warnings and notices. It takes two parameters: the first one is the log message,
and the second one defines its error level (one of E_USER_ERROR,
E_USER_WARNING, E_USER_NOTICE, or E_USER_DEPRECATED):

<?php
trigger_error("A user requested a resource.", E_USER_NOTICE);
trigger_error("The image failed to load!", E_USER_WARNING);
trigger_error("User requested a profile that doesn't exist!", E_USER_ERROR);
?>

When you execute the script above, you will observe the following console
output:

Notice:  A user requested a resource. in /home/eric/test/logging.php on line 2
Warning:  The image failed to load! in /home/eric/test/logging.php on line 3
Fatal error:  User requested a profile that doesn't exist! in /home/eric/test/logging.php on line 4

The above logs are also recorded to the error.log file in a slightly different
format:

[8-Jul-2022 22:11:43 America/New_York] PHP Notice:  A user requested a service. in /home/eric/test/logging.php on line 3
[8-Jul-2022 22:11:43 America/New_York] PHP Warning:  The image failed to load! in /home/eric/test/logging.php on line 4
[8-Jul-2022 22:11:43 America/New_York] PHP Fatal error:  User requested a profile that doesn't exist! in /home/eric/test/logging.php on line 5

Each log entry specifies the corresponding log level and the location of the log
message. If you don’t use a user-assigned error level constant (prefixed with
E_USER_), an error will be thrown.

<?php
trigger_error("A user requested a service.", E_ERROR);
?>

Fatal error: Uncaught ValueError: trigger_error(): Argument #2 ($error_level) must be one of E_USER_ERROR, E_USER_WARNING, E_USER_NOTICE, or E_USER_DEPRECATED in /home/ayo/dev/betterstack/betterstack-community/demo/logging-php/logging.php:2
Stack trace:
#0 /home/ayo/dev/betterstack/betterstack-community/demo/logging-php/logging.php(2): trigger_error()
#1 {main}
  thrown in /home/ayo/dev/betterstack/betterstack-community/demo/logging-php/logging.php on line 2

Logging to the system log

A third way to log messages in PHP is using the syslog() function. It sends
the log message to the default system log like this:

syslog(LOG_ERR, "Custom error message");

The first argument to syslog() is the appropriate log level constant, and the
second is the log message to be recorded. Notice that when specifying the log
level, the third group of constants (those prefixed with LOG_) are utilized.
These constants are unique to the syslog() function, and they are all listed
in its documentation.

Here are a few ways to view your system log:

• On Linux, use one of the following commands to access the system log
  (depending on the specific OS):

tail -f /var/log/messages

• On macOS, run tail -f /var/log/system.log in your terminal.
• On Windows, use the
  Windows Event Viewer.

Here’s some sample output from the system log on a Linux-based OS after
executing the previous code snippet:

Jul 27 20:58:28 fedora php[485047]: Custom error message

You can customize the output above through the openlog() function. It opens a
connection to the system logger and takes up to three arguments: a string prefix
to be added to each message, the logging options, and the logging facility.
After calling openlog(), you should call closelog() to close the connection.

openlog("MyAppPrefix", LOG_PID | LOG_PERROR,LOG_USER);
syslog(LOG_ERR, "Custom error message");
closelog();

Here’s the output after executing the script above:

Jul 28 09:20:04 fedora MyAppPrefix[596277]: Custom error message

You can learn more about system logs on
Linux by reading our
detailed tutorial on the subject.

Why you should use a logging framework

Using PHP’s built-in logging functions is an easy way to get started with
logging in simple projects, but they are insufficient for creating a robust
logging strategy in serious applications due to their lack of features and
flexibility, such as customizing the formatting of your logs, or determining how
they are recorded. They also cannot capture a wide variety of data types since
everything fed into them must be a string, which means you have to do extra work
to capture contextual data in a log entry.

These limitations are why third-party logging frameworks
are prevalent in the PHP ecosystem. Here are some of the most popular logging
libraries for PHP that are worth exploring for production-grade applications:

• Monolog: Monolog is the most popular PHP
  logging framework out there. It has dozens of handlers that can send your log
  records to files, emails, databases, Slack, etc. It is also packed with
  multiple formatters that allow you to customize your logs however you want.
• Analog: Analog is a minimal logging
  library. It also has several handlers that can send your logs to different
  destinations. However, it does not have optional features such as formatters
  and processors.
• KLogger: Unlike Analog, KLogger goes in
  a different direction. It can only push your logs to a file, but it has many
  different formatters that you can use to customize the timestamp, file name,
  file extension, context information, etc.

In the next section, we will briefly examine how to implement logging using the
Monolog library as it’s the most popular and satisfactorily meets all our
criteria for a good logging framework.

Getting started with Monolog

To use Monolog in your PHP application, you need to install the library through
PHP Composer:

composer require monolog/monolog

. . .
Package operations: 2 installs, 0 updates, 0 removals
  - Installing psr/log (3.0.0): Extracting archive
  - Installing monolog/monolog (3.1.0): Extracting archive
11 package suggestions were added by new dependencies, use `composer suggest` to see details.
Generating autoload files
1 package you are using is looking for funding.
Use the `composer fund` command to find out more!

This command will install Monolog into the vendor directory, and you can
import the package into your project like this:

<?php

require __DIR__."/vendor/autoload.php"; // This tells PHP where to find the autoload file so that PHP can load the installed packages

use MonologLogger; // The Logger instance
use MonologHandlerStreamHandler; // The StreamHandler sends log messages to a file on your disk
use MonologLevel; // Log levels
?>

The three classes we imported into the file above represent Monolog’s most
important concepts. First, logging in Monolog is channel-based, and the Logger
instance is used to initialize a new log channel which provides a mechanism for
grouping different logs. For example, you can have an errors channel that
records errors, a performance channel that logs performance-related messages,
and so on. You can organize this system however you like depending on what kind
of application you are building.

Each log channel can be assigned multiple handlers, and they are responsible for
sending log messages to various destinations. For example, the StreamHandler
above can push your messages to the console or a local file.

Finally, each handler needs to have a minimum log level, which defines the
minimum level a message must have to be logged by the handler. Monolog provides
a more standard way of dealing with log levels than PHP’s error level constants.
There are eight different levels available in Monolog, and they are modeled
after the
Syslog severity levels
discussed earlier:

• EMERGENCY
• ALERT
• CRITICAL
• ERROR
• WARNING
• NOTICE
• INFO
• DEBUG

Logging in PHP with Monolog

Let’s look at an example of how to log messages to the console with Monolog:

<?php
. . .
// New Logger instance. Create a new channel called "my_logger".
$logger = new Logger("my_logger");

// Create a new handler. In this case, it is the StreamHandler, which will send the log messages to the console.
$stream_handler = new StreamHandler("php://stdout", Level::Debug);

// Push the handler to the log channel
$logger->pushHandler($stream_handler);

// Log the message
$logger->debug("This is a debug message.");
$logger->info("This is an info message.");
$logger->error("This is an error message.");
$logger->critical("This is a critical message.");
?>

Execute the logging.php file, and observe the following output:

[2022-07-11T03:32:57.111007+02:00] my_logger.DEBUG: This is a debug message. [] []
[2022-07-11T03:32:57.111750+02:00] my_logger.INFO: This is an info message. [] []
[2022-07-11T03:32:57.111941+02:00] my_logger.ERROR: This is an error message. [] []
[2022-07-11T03:32:57.112127+02:00] my_logger.CRITICAL: This is a critical message. [] []

In this example, a new log channel called my_logger was initialized using the
Logger instance, and then a StreamHandler() instance was assigned to it.
This handler was setup to log debug-level messages or higher to the standard
output (represented by php://stdout).

Lastly, several log messages are recorded by using the debug(), info(),
error(), and critical() methods which give the message the corresponding log
level that is observed in the output. Notice that a timestamp is also included
with each entry.

Instead of logging to the terminal console, we can also push the log record to a
local file using the StreamHandler(). All we need to do is change the
destination parameter like this:

<?php
. . .

$logger = new Logger("my_logger");

$stream_handler = new StreamHandler(__DIR__ . "/log/debug.log", Level::Debug);

$logger->pushHandler($stream_handler);

$logger->debug("This is a debug message.");
?>

This causes log messages using the $logger channel to be sent to a
/log/debug.log file. You can examine its contents with the following command:

[2022-07-10T01:53:24.848775+02:00] my_logger.DEBUG: This is a debug message. [] []

There are many other handlers other than the StreamHandler demonstrated above,
so ensure to read our detailed guide on
Monolog to learn more about them and how to
create a custom handler.

Formatting your logs

From the examples above, you will observe that all the log records follow a
predefined format. They all start with a timestamp, followed by the log level,
message, context and extra information. This format might not fit your needs
when creating a logging system, so Monolog provides several formatters that you
can use to customize the log records.

One of the useful formatters to look at is the LineFormatter. It takes a log
record as input, and subsequently outputs a formatted string of the record.
Let’s take a look at an example:

. . .
use MonologLevel;
use MonologLogger;
use MonologHandlerStreamHandler;
use MonologFormatterLineFormatter;

$logger = new Logger("my_logger");

$stream_handler = new StreamHandler("php://stdout", Level::Debug);
$output = "%level_name% | %datetime% > %message% | %context% %extra%n";
$stream_handler->setFormatter(new LineFormatter($output));

$logger->pushHandler($stream_handler);

$logger->debug("This file has been executed.");
?>

In this case, we are making Monolog return a log record that starts with the log
level, then the date, message, and context information.

DEBUG | 2022-07-10T21:33:51.345896+02:00 > This file has been executed. | [] []

Besides rearranging the different segments, it is also possible for us to
customize the timestamp output, since the default format isn’t very human
readable.

<?php
. . .
$dateFormat = "Y-n-j, g:i a";
$output = "%level_name% | %datetime% > %message% | %context% %extra%n";
$stream_handler->setFormatter(new LineFormatter($output, $dateFormat));
. . .
?>

DEBUG | 2022-7-10, 10:24 pm > This file has been executed. | [] []

In a production environment, your application will probably generate tons of
logs, and in this case, it is best to use a structured logging
format
that is better suited to parsing by automated logging tools. Using Monolog’s
JsonFormatter, you are able to log in JSON format, making it easier for
machines to read.

<?php

require __DIR__ . "/vendor/autoload.php";

use MonologLevel;
use MonologLogger;
use MonologHandlerStreamHandler;
use MonologFormatterJsonFormatter;

$logger = new Logger("daily");

$stream_handler = new StreamHandler("php://stdout", Level::Debug);
$logger->pushHandler($stream_handler);
$stream_handler->setFormatter(new JsonFormatter());

$logger->debug("This is a debug message.");

{"message":"This is a debug message.","context":{},"level":100,"level_name":"DEBUG","channel":"daily","datetime":"2022-07-29T21:43:30.910327+02:00","extra":{}}

Notice that the log message, the log level, the timestamp, and so on have all
been turned into JSON data.

You can learn more about formatters in Monolog and their available options by
reading their
documentation.

Final thoughts

We covered a lot of ground in this article, beginning with PHP’s native logging
functions and their quirks and features before briefly discussing logging
frameworks and why you need one. We also introduced Monolog, a logging library
for PHP application and demonstrated some of its basic features that help you
create a more useful logging system. There’s a lot more about Monolog that can’t
be covered here so we recommend diving into our detailed guide to logging with
Monolog to get a full picture of what you
can do with it.

Thanks for reading, and happy logging!

Next article

→

Instructions

To log PHP errors you will want to edit your server/domain’s php.ini file. If you require a refresher on how to locate/edit the php.ini file of your server, feel free to check out our additional article:

How can I edit the php.ini file? How can I edit the php.ini file?

Once in your php.ini file, input the following:

; log PHP errors to a file 
log_errors = on
error_reporting = 32767
error_log = /path/to/file

Be sure to change /path/to/file to the file path where you want the logs to be saved.

Notes:

• In the above code, the integer 32767 is used to denote the «E_ALL» level of error reporting in legacy PHP versions. Depending on the specific version of PHP you are running on that domain, the integer values may correspond differently to the error verbosity levels. 32767, however, should continue to function as «E_ALL» in newer versions of PHP.
• Visit http://www.php.net/manual/en/errorfunc.constants.php for information on the different levels of error reporting available and their corresponding integer codes.
• It is best to keep the log in a directory which is NOT web-accessible; some PHP errors may expose vulnerabilities or sensitive information that could be useful to a visitor with malicious intent.
• Depending on the level of verbosity you have selected for your PHP error logging and the frequency of errors/warnings generated, the PHP error logging file could grow very large very quickly. Be sure to keep a close eye on the size of this file and to only have the error logging enabled if you are actively debugging potential site coding issues.

Using the Errors to Troubleshoot Code

You can access the log file wherever you configured it to be written. In the example above, the file can be accessed at /path/to/file. Each error will each be reported on a new line and each line will be timestamped. Here is an example error line:

[09-Dec-2012 18:58:57] PHP Fatal error: Call to undefined function eccho() in /path/to/example.com/html/samplefile.php on line 2

From the above error sample, it is easy to see that the problem is that the «eccho» function does not exist. Since we know that «echo» is a function in PHP, it would be a safe bet that there was just a typo in the PHP code on line 2 of the «samplefile.php» file.

Additional Links

• PHP Error Handling and Logging (Manual)
• Where are the access_log and error_log files for my server?

Instructions

For Managed WordPress servers, PHP error logging can be enabled via the .user.ini file. Instructions on this process can be found in the article below:

• Where are the access_log and error_log files for my server?