Bdtjtk

The following enables all errors:

ini_set('display_startup_errors', 1);

ini_set('display_errors', 1);

error_reporting(-1);

Also see the following links

• http://php.net/manual/en/errorfunc.configuration.php#ini.display-errors


• http://php.net/manual/en/errorfunc.configuration.php#ini.display-startup-errors


• http://php.net/manual/en/function.error-reporting.php

You can include the following lines in the file you want to debug:

error_reporting(E_ALL);

ini_set('display_errors', '1');

This overrides the default settings in php.ini, which just make PHP report the errors to the log.

PHP Configuration

2 entries in php.ini dictate the output of errors:

1. display_errors


2. error_reporting

In production, display_errors is usually set to Off (Which is a good thing, because error display in production sites is generally not desirable!).

However, in development, it should be set to On, so that errors get displayed. Check!

error_reporting (as of PHP 5.3) is set by default to E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED (meaning, everything is shown except for notices, strict standards and deprecation notices). When in doubt, set it to E_ALL to display all the errors. Check!

Whoa whoa! No check! I can't change my php.ini!

That's a shame. Usually shared hosts do not allow the alteration of their php.ini file, and so, that option is sadly unavailable. But fear not! We have other options!

Runtime configuration

In the desired script, we can alter the php.ini entries in runtime! Meaning, it'll run when the script runs! Sweet!

error_reporting(E_ALL);

ini_set("display_errors", "On");

These two lines will do the same effect as altering the php.ini entries as above! Awesome!

I still get a blank page/500 error!

That means that the script hadn't even run! That usually happens when you have a syntax error!

With syntax errors, the script doesn't even get to runtime. It fails at compile time, meaning that it'll use the values in php.ini, which if you hadn't changed, may not allow the display of errors.

Error logs

In addition, PHP by default logs errors. In shared hosting, it may be in a dedicated folder or on the same folder as the offending script.

If you have access to php.ini, you can find it under the error_log entry.

There is a really useful extension called "xdebug" that will make your reports much nicer as well.

For quick, hands-on troubleshooting I normally suggest here on SO:

error_reporting(~0); ini_set('display_errors', 1);

to be put at the beginning of the script that is under trouble-shooting. This is not perfect, the perfect variant is that you also enable that in the php.ini and that you log the errors in PHP to catch syntax and startup errors.

The settings outlined here display all errors, notices and warnings, including strict ones, regardless which PHP version.

Next things to consider:

• Install Xdebug and enable remote-debugging with your IDE.

See as well:

• Error Reporting (PHP The Right Way.)


• Predefined Constants^Docs
  


• 
  error_reporting()^Docs
  


• 
  display_errors^Docs
  

If you are super cool, you might try:

$test_server = $_SERVER['SERVER_NAME'] == "127.0.0.1" || $_SERVER['SERVER_NAME'] == "localhost" || substr($_SERVER['SERVER_NAME'],0,3) == "192";



ini_set('display_errors',$test_server);

error_reporting(E_ALL|E_STRICT);

This will only display errors when you are running locally. It also gives you the test_server variable to use in other places where appropriate.

Any errors that happen before the script runs won't be caught, but for 99% of errors that I make, that's not an issue.

On the top of the page choose a parameter

error_reporting(E_ERROR | E_WARNING | E_PARSE);

To persist this and make it confortale, you can edit your php.ini file. It is usually stored in /etc/php.ini or /etc/php/php.ini, but more local php.ini's may overwrite it, depending on your hosting provider's setup guidelines. Check a phpinfo() file for Loaded Configuration File at the top, to be sure which one gets loaded last.

Search for display_errors in that file. There should be only 3 instances, of which 2 are commented.

Change the uncommented line to:

display_errors = stdout

I recommend Nette Tracy for better visualization of errors and exceptions in PHP:

error_reporting(E_ALL | E_STRICT);

ini_set('display_errors', 1);

ini_set('html_errors', 1);

In addition, you can get more detailed information with xdebug.

error_reporting(E_ALL | E_STRICT);

And turn on display errors in php.ini

ini_set('display_errors', 1);

ini_set('display_startup_errors', 1);

error_reporting(E_ALL);

You can register your own error handler in PHP. Dumping all errors to a file might help you in these obscure cases, for example. Note that your function will get called, no matter what your current error_reporting is set to. Very basic example:

function dump_error_to_file($errno, $errstr) {

    file_put_contents('/tmp/php-errors', date('Y-m-d H:i:s - ') . $errstr, FILE_APPEND);

}

set_error_handler('dump_error_to_file');

Try this PHP error reporting reference tool. It's a very good visual reference and helped me understand the complex error reporting mechanism.

You might also want to try PHPStorm as your code editor. It will find many PHP and other syntax errors right as you are typing in the editor.

The two key lines you need to get useful errors out of PHP are:

ini_set('display_errors',1);

 error_reporting(E_ALL);

As pointed out by other contributors, these are switched off by default for security reasons. As a useful tip - when you're setting up your site it's handy to do a switch for your different environments so that these errors are ON by default in your local and development environments. This can be achieved with the following code (ideally in your index.php or config file so this is active from the start):

switch($_SERVER['SERVER_NAME'])

{

    // local

    case 'yourdomain.dev':

    // dev

    case 'dev.yourdomain.com':

        ini_set('display_errors',1);

        error_reporting(E_ALL);

    break;

    //live

    case 'yourdomain.com':

        //...

    break;

}

FirePHP can be useful as well.

if you are a ubuntu user then goto your terminal and run this command

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

where it will display recent 50 errors.
There is a error file error.log for apache2 which logs all the errors.

You can enable full error reporting (including notices and strict messages). Some people find this too verbose, but it's worth a try. Set error_reporting to E_ALL | E_STRICT in your php.ini.

error_reporting = E_ALL | E_STRICT

E_STRICT will notify you about deprecated functions and give you recommendations about the best methods to do certain tasks.

If you don't want notices, but you find other message types helpful, try excluding notices:

error_reporting = (E_ALL | E_STRICT) & ~E_NOTICE

Also make sure that display_errors is enabled in php.ini. If your PHP version is older than 5.2.4, set it to On:

display_errors = "On"

If your version is 5.2.4 or newer, use:

display_errors = "stderr"

To turn on full error reporting, add this to your script:

error_reporting(E_ALL);

This causes even minimal warnings to show up. And, just in case:

ini_set('display_errors', '1');

Will force the display of errors. This should be turned off in production servers, but not when you're developing.

Aside from error_reporting and the display_errors ini setting, you can get SYNTAX errors from your web server's log files. When I'm developing PHP I load my development system's web server logs into my editor. Whenever I test a page and get a blank screen, the log file goes stale and my editor asks if I want to reload it. When I do, I jump to the bottom and there is the syntax error. For example:

[Sun Apr 19 19:09:11 2009] [error] [client 127.0.0.1] PHP Parse error:  syntax error, unexpected T_ENCAPSED_AND_WHITESPACE, expecting T_STRING or T_VARIABLE or T_NUM_STRING in D:\webroot\test\test.php on line 9

The “ERRORS” are the most useful things for the developers to know their mistakes and resolved them to make the system working perfect.

PHP provides some of better ways to know the developers why and where their piece of code is getting the errors, so by knowing those errors developers can make their code better in many ways.

Best ways to write following two lines on the top of script to get all errors messages:

error_reporting(E_ALL);

ini_set("display_errors", 1);

Another way to use debugger tools like xdebug in your IDE.

In addition to all the wonderful answers here, I'd like to throw in a special mention for the MySQLi and PDO libraries.

In order to...

1. Always see database related errors, and


2. Avoid checking the return types for methods to see if something went wrong

The best option is to configure the libraries to throw exceptions.

MySQLi

Add this near the top of your script

mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);

This is best placed before you use new mysqli() or mysqli_connect().

PDO

Set the PDO::ATTR_ERRMODE attribute to PDO::ERRMODE_EXCEPTION on your connection instance. You can either do this in the constructor

$pdo = new PDO('driver:host=localhost;...', 'username', 'password', [

    PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION

]);

or after creation

$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

Turning on error reporting is the correct solution, however it does not seem to take effect in the program that turns it on, but only in subsequently included programs.

Thus, I always create a file/program (which I usually call "genwrap.php") which has essentially the same code as the popular solution here (ie. turn on error reporting) and it also then includes the page I actually want to call.

There are 2 steps to implement this debugging;

One - create genwrap.php and put this code in it:

<?php

error_reporting(-1);

ini_set('display_errors', 'On');



include($_REQUEST['page']);

?>

Two - change the link to the program/page you want to debug to go via genwrap.php,

Eg: change:

$.ajax('dir/pgm.php?param=val').done(function(data) { /* ... */

to

$.ajax('dir/genwrap.php?page=pgm.php&param=val').done(function(data) { /* ... */

http://todell.com/debug can be useful as well. You can see your object values or thrown debug errors behind the scene even in production mode.

In addition to the very many excellent answers above you could also implement the following two functions in your projects. They will catch every non-syntax error before application/script exit.
Inside the functions you can do a backtrace and log or render a pleasant 'Site is under maintenance' message to the public.

Fatal Errors:

register_shutdown_function

http://php.net/manual/en/function.register-shutdown-function.php

Errors:

set_error_handler

http://php.net/manual/en/function.set-error-handler.php

Backtracing:

debug_backtrace

http://php.net/manual/en/function.debug-backtrace.php

Use Kint. It is combination of debugging commands on steroids.
https://kint-php.github.io/kint/
It is very similar to Nette Tracy

My usual problem are "little, stupid" parser errors which unfortunately do not show up.

However, when a .PHP-File includes a file that has parser-errors, they are shown!
So I had the idea of writing a little "executor-script" that is launched with the name of the buggy file as argument, i.e. example.com/sx.php?sc=buggy.php

It had already saved me from a lot of headache, maybe it will be helpful to someone else, too :)

sx.php

$sc = $_GET["sc"];

if ((!isset($_GET["sc"]) && empty($_GET["sc"]))) {

    echo "Please select file to execute using ?sc= (you may omit the .PHP-extension)";

} else {

    $sc = $_GET["sc"];

    if (false==stripos('.php',$sc)) $sc.='.php';  // adjust this if your preferred extension is php5!

    require($sc);

}

?>