644

Quite often I will try and run a PHP script and just get a blank screen back. No error message; just an empty screen. The cause might have been a simple syntax error (wrong bracket, missing semicolon), or a failed function call, or something else entirely.

It is very difficult to figure out what went wrong. I end up commenting out code, entering "echo" statements everywhere, etc. trying to narrow down the problem. But there surely must be a better way, right?

Is there a way to get PHP to produce a useful error message, like Java does?

TylerH
  • 20,799
  • 66
  • 75
  • 101
Candidasa
  • 8,580
  • 10
  • 30
  • 31
  • 1
    http://coding.smashingmagazine.com/2011/11/30/a-guide-to-php-error-messages-for-designers/ – Alex Jul 15 '12 at 14:54
  • 5
    @JuannStrauss, That's understating it. And when you **finally** see the errors, it says `T_PAAMAYIM_NEKUDOTAYIM`. Or maybe ["must be an instance of integer, integer given"](http://stackoverflow.com/questions/4103480/really-php-argument-1-passed-to-my-function-must-be-an-instance-of-string-s). – Pacerier Apr 03 '15 at 20:02
  • 2
    Tutorial on this: http://code2real.blogspot.com/2015/06/php-generate-log-messages-and-save-to.html – Pupil Sep 09 '15 at 07:21
  • If you have a parse error none of these will work on many web hosts, and you might not have access to the error logs. You will need to install php on your local machine (XAMPP on Windows etc) and do a command line synax check `php.exe -l ` – Matthew Lock Aug 17 '21 at 10:32

41 Answers41

528

By default, displaying errors is turned off because you don't want a "customer" seeing the error messages.

Check this page in the PHP documentation for information on the 2 directives: error_reporting and display_errors. display_errors is probably the one you want to change.

So you have 3 options:

(1) You can check the error log file as it will have all of the errors (unless logging has been disabled). To enable error logging make sure that log_errors configuration directive is set to On. Logs are also helpful when error is happened not in PHP but emitted by web-server.

(2) You can add the following 2 lines that will help you debug errors that are not syntax errors happened in the same file:

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

Note that on a live server the latter should be set to Off (but only the latter, because you still need to learn about all errors happened, from the log file).

However, for syntax errors happened in the same file, the above commands won't work and you need to enable them in the php.ini. If you can't modify the php.ini, you may also try to add the following lines to an .htaccess file, though it's seldom supported nowadays:

php_flag  display_errors        on
php_value error_reporting       -1

(3) Another option is to use an editor that checks for errors when you type, such as PhpEd, VSCode or PHPStorm. They all come with a debugger which can provide more detailed information. (The PhpEd debugger is very similar to xdebug and integrates directly into the editor so you use 1 program to do everything.)

Your Common Sense
  • 156,878
  • 40
  • 214
  • 345
Darryl Hein
  • 142,451
  • 95
  • 218
  • 261
  • 30
    2039 is the value of `E_ERROR | E_WARNING | E_PARSE | E_CORE_ERROR | E_CORE_WARNING | E_COMPILE_ERROR | E_COMPILE_WARNING | E_USER_ERROR | E_USER_WARNING | E_USER_NOTICE`. See http://docs.php.net/manual/en/errorfunc.constants.php – Gumbo May 10 '09 at 17:59
  • I like the option of .htaccess file. It helps me debug in an area that is not part of the public website. Thanks a lot for this tip! – jacekn Jun 15 '13 at 01:39
  • 2
    I would add that logging errors to file (and looking them up there) is the best solution. Don't rely on displaying errors on-page - they can ruin it, you can forget to turn error reporting for production site and this will cause you trouble in future – Ivan Yarych Mar 26 '16 at 20:44
468

The following enables all errors:

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

Also see the following links

Janyk
  • 571
  • 3
  • 18
Eljakim
  • 6,877
  • 2
  • 16
  • 16
  • 29
    Best to make these changes at the .ini file level. Turning on error reporting from within a script is useless, as it won't help with syntax errors or other fatal errors that kill the compile phase. The script gets killed long before it begins executing and reaches the reporting overrides. – Marc B Jul 04 '11 at 19:49
  • You are correct indeed. I did not notice that the move is to your own server. – Eljakim Jul 04 '11 at 19:51
  • Try to find the file php.ini that is used. On my ubuntu machine it is stored in /etc/php5/apache2/php.ini – Eljakim Jul 04 '11 at 19:52
  • 6
    Run phpinfo() to find the correct php.ini file. Look for the *Loaded Configuration File* line. – borrible Jul 05 '11 at 08:01
  • 1
    If you are looking for errors that occur during the compile phase, check your apache logs often located at /var/log/apache2/error.log – csi Feb 21 '14 at 22:08
  • 2
    This answer will fail on php7 when strict typing is enabled, because the second parameter of `ini_set` is a string. – PeeHaa Sep 04 '15 at 18:16
178

The following code should display all errors:

<?php

// ----------------------------------------------------------------------------------------------------
// - Display Errors
// ----------------------------------------------------------------------------------------------------
ini_set('display_errors', 'On');
ini_set('html_errors', 0);

// ----------------------------------------------------------------------------------------------------
// - Error Reporting
// ----------------------------------------------------------------------------------------------------
error_reporting(-1);

// ----------------------------------------------------------------------------------------------------
// - Shutdown Handler
// ----------------------------------------------------------------------------------------------------
function ShutdownHandler()
{
    if(@is_array($error = @error_get_last()))
    {
        return(@call_user_func_array('ErrorHandler', $error));
    };

    return(TRUE);
};

register_shutdown_function('ShutdownHandler');

// ----------------------------------------------------------------------------------------------------
// - Error Handler
// ----------------------------------------------------------------------------------------------------
function ErrorHandler($type, $message, $file, $line)
{
    $_ERRORS = Array(
        0x0001 => 'E_ERROR',
        0x0002 => 'E_WARNING',
        0x0004 => 'E_PARSE',
        0x0008 => 'E_NOTICE',
        0x0010 => 'E_CORE_ERROR',
        0x0020 => 'E_CORE_WARNING',
        0x0040 => 'E_COMPILE_ERROR',
        0x0080 => 'E_COMPILE_WARNING',
        0x0100 => 'E_USER_ERROR',
        0x0200 => 'E_USER_WARNING',
        0x0400 => 'E_USER_NOTICE',
        0x0800 => 'E_STRICT',
        0x1000 => 'E_RECOVERABLE_ERROR',
        0x2000 => 'E_DEPRECATED',
        0x4000 => 'E_USER_DEPRECATED'
    );

    if(!@is_string($name = @array_search($type, @array_flip($_ERRORS))))
    {
        $name = 'E_UNKNOWN';
    };

    return(print(@sprintf("%s Error in file \xBB%s\xAB at line %d: %s\n", $name, @basename($file), $line, $message)));
};

$old_error_handler = set_error_handler("ErrorHandler");

// other php code

?>

The only way to generate a blank page with this code is when you have a error in the shutdown handler. I copied and pasted this from my own cms without testing it, but I am sure it works.

m4dm4x1337
  • 1,847
  • 2
  • 11
  • 3
  • 4
    I get a blank page from that code. What do you mean by "you have a error in the shutdown handler" and what should I do to solve the problem? – Paolo M Sep 24 '14 at 23:08
  • @PaoloM, He is saying an error in the function `ShutdownHandler` above. Basically this is a stopgap hack in place of proper error handling. – Pacerier Oct 14 '14 at 09:33
  • Thanks, was useful, but how can I disable `E_NOTICE` errors in this function? – MajAfy Apr 04 '15 at 08:45
  • This is the right solution, but be careful with information discosure when error occurs... (prefer logging instead of echoing to users) – Sam Jason Braddock Aug 29 '16 at 14:13
  • 1
    I am using this when the Symfony can't catch correctly fatal errors. – COil Sep 22 '16 at 10:19
  • nothing in apache logs, wordpress in debug mode, htaccess with debug setted. you save me, the only way to get the error! I don't know why E_COMPILE_ERROR Error in file »functions.php« at line 7: Cannot redeclare shift_to_day_after() – jedi Jan 18 '17 at 16:01
  • This answer is amazing. Probably for those of you who commented on showing to screen that you could call `error_log` in here instead of return? Also, in my case, I had to replace the `@basename($file)` with `$file`, since there were a lot of files in the codebase with the same file name. (Not my code base.) – Evan Donovan May 29 '19 at 19:43
  • This script could also make use of `set_exception_handler()` (capturing such incidents) and `debug_backtrace()` (for the log). – AmigoJack Aug 04 '20 at 00:32
  • This is good solution for functions with `@` character in first them. – Nabi K.A.Z. Mar 31 '21 at 06:39
63

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.

Tomalak
  • 332,285
  • 67
  • 532
  • 628
  • 2
    That's true. In this case the values must be set in the ini directly -- for a pure development environment this may be preferable anyway. – Tomalak May 10 '09 at 10:00
61

Errors and warnings usually appear in ....\logs\php_error.log or ....\logs\apache_error.log depending on your php.ini settings.

Also useful errors are often directed to the browser, but as they are not valid html they are not displayed.

So "tail -f" your log files and when you get a blank screen use IEs "view" -> "source" menu options to view the raw output.

Jens
  • 67,715
  • 15
  • 98
  • 113
James Anderson
  • 27,109
  • 7
  • 50
  • 78
  • 13
    Sadly, view page source displays nothing too. – Matthew Scharley Sep 25 '09 at 04:40
  • 2
    Parse errors should be visible in the Apache's error log, regardless of what setting you have anywhere else. If you don't have control over the server then getting the apache error log might be difficult, but I suggest you talk with your provider and there are ways to expose the error log to you. Other then that, I can only suggest what other have - vet your code for parsing errors in your local development server before you deploy to production. Also, a validating IDE such as Eclipse's PDT might be of great help. – Guss Sep 25 '09 at 06:51
  • 5
    Coming back to this, I recently had a stack overflow issue that wasn't generating any errors, even in the logs and didn't manifest itself as such till I installed xdebug into the server. Gah. – Matthew Scharley May 30 '11 at 23:44
  • If you cannot modify php.ini, create a .htaccess file with `php_flag display_errors 1` in it. – Tom Jan 16 '19 at 10:58
58

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.

mario
  • 144,265
  • 20
  • 237
  • 291
Madara's Ghost
  • 172,118
  • 50
  • 264
  • 308
  • For the runtime configuration, you may be able to put those lines into a separate file & `include` the php file with the error. – JustinCB Dec 08 '20 at 22:03
32

I'm always using this syntax at the very top of the php script.

ini_set('error_reporting', E_ALL);
ini_set('display_errors', 'On');  //On or Off
FDisk
  • 8,493
  • 2
  • 47
  • 52
30

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

gnarf
  • 105,192
  • 25
  • 127
  • 161
  • 2
    Indeed, this is a *very* useful debugging tool—makes error messages much more verbose, with full stack traces and variable dumps and everything. – hbw May 10 '09 at 10:06
  • 2
    Yes. And then use something like the VimDebugger plugin to step through your code and find out where it goes wrong. – Sander Marechal May 10 '09 at 10:20
  • 1
    NetBeans with xdebug here. It's so awesome. I'm new to PHP (usually ASP.NET) and had been issuing echo statements before. – Some Canuck May 10 '09 at 12:10
27

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:

hakre
  • 193,403
  • 52
  • 435
  • 836
27

It is possible to register an hook to make the last error or warning visible.

function shutdown(){
  var_dump(error_get_last());
}

register_shutdown_function('shutdown');

adding this code to the beginning of you index.php will help you debug the problems.

Eduardo Oliveira
  • 676
  • 8
  • 25
17

On the top of the page choose a parameter

error_reporting(E_ERROR | E_WARNING | E_PARSE);
Kld
  • 6,970
  • 3
  • 37
  • 50
17

This is a problem of loaded vs. runtime configuration

It's important to recognize that a syntax error or parse error happens during the compile or parsing step, which means that PHP will bail before it's even had a chance to execute any of your code. So if you are modifying PHP's display_errors configuration during runtime, (this includes anything from using ini_set in your code to using .htaccess, which is a runtime configuration file) then only the default loaded configuration settings are in play.

How to always avoid WSOD in development

To avoid a WSOD you want to make sure that your loaded configuration file has display_errors on and error_reporting set to -1 (this is the equivalent E_ALL because it ensures all bits are turned on regardless of which version of PHP you're running). Don't hardcode the constant value of E_ALL, because that value is subject to change between different versions of PHP.

Loaded configuration is either your loaded php.ini file or your apache.conf or httpd.conf or virtualhost file. Those files are only read once during the startup stage (when you first start apache httpd or php-fpm, for example) and only overridden by runtime configuration changes. Making sure that display_errors = 1 and error_reporting = -1 in your loaded configuration file ensures that you will never see a WSOD regardless of syntax or parse error that occur before a runtime change like ini_set('display_errors', 1); or error_reporting(E_ALL); can take place.

How to find your (php.ini) loaded configuration files

To locate your loaded configuration file(s) just create a new PHP file with only the following code...

<?php
phpinfo();

Then point your browser there and look at Loaded Configuration File and Additional .ini files parsed, which are usually at the top of your phpinfo() and will include the absolute path to all your loaded configuration files.

If you see (none) instead of the file, that means you don't have a php.ini in Configuration File (php.ini) Path. So you can download the stock php.ini bundled with PHP from here and copy that to your configuration file path as php.ini then make sure your php user has sufficient permissions to read from that file. You'll need to restart httpd or php-fpm to load it in. Remember, this is the development php.ini file that comes bundled with the PHP source. So please don't use it in production!


Just don't do this in production

This really is the best way to avoid a WSOD in development. Anyone suggesting that you put ini_set('display_errors', 1); or error_reporting(E_ALL); at the top of your PHP script or using .htaccess like you did here, is not going to help you avoid a WSOD when a syntax or parse error occurs (like in your case here) if your loaded configuration file has display_errors turned off.

Many people (and stock installations of PHP) will use a production-ini file that has display_errors turned off by default, which typically results in this same frustration you've experienced here. Because PHP already has it turned off when it starts up, then encounters a syntax or parse error, and bails with nothing to output. You expect that your ini_set('display_errors',1); at the top of your PHP script should have avoided that, but it won't matter if PHP can't parse your code because it will never have reached the runtime.

Community
  • 1
  • 1
Sherif
  • 11,786
  • 3
  • 32
  • 57
17

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.

Rich Bradshaw
  • 71,795
  • 44
  • 182
  • 241
  • 2
    If you're differentiating between local and production environments, you should simply enable or disable errors globally (in your php.ini) and not in code that can also be production code. If you need to debug a production website in its production environment and only want you to be able to view the errors, use `$_SERVER['REMOTE_HOST']` to check whether the client is, well, you. – Jaap Haagmans Jun 23 '14 at 11:50
16

I don't know if it will help, but here is a piece of my standard config file for php projects. I tend not to depend too much on the apache configs even on my own server.

I never have the disappearing error problem, so perhaps something here will give you an idea.

Edited to show APPLICATON_LIVE

/*
APPLICATION_LIVE will be used in process to tell if we are in a development or production environment.  It's generally set as early as possible (often the first code to run), before any config, url routing, etc.
*/

if ( preg_match( "%^(www.)?livedomain.com$%", $_SERVER["HTTP_HOST"]) ) {
    define('APPLICATION_LIVE', true);
} elseif ( preg_match( "%^(www.)?devdomain.net$%", $_SERVER["HTTP_HOST"]) ) {
    define('APPLICATION_LIVE', false);
} else {
    die("INVALID HOST REQUEST (".$_SERVER["HTTP_HOST"].")");
    // Log or take other appropriate action.
}


/*
--------------------------------------------------------------------
DEFAULT ERROR HANDLING
--------------------------------------------------------------------
Default error logging.  Some of these may be changed later based on APPLICATION_LIVE.
*/
error_reporting(E_ALL & ~E_STRICT);
ini_set ( "display_errors", "0");
ini_set ( "display_startup_errors", "0");
ini_set ( "log_errors", 1);
ini_set ( "log_errors_max_len", 0);
ini_set ( "error_log", APPLICATION_ROOT."logs/php_error_log.txt");
ini_set ( "display_errors", "0");
ini_set ( "display_startup_errors", "0");

if ( ! APPLICATION_LIVE ) {
    // A few changes to error handling for development.
    // We will want errors to be visible during development.
    ini_set ( "display_errors", "1");
    ini_set ( "display_startup_errors", "1");
    ini_set ( "html_errors", "1");
    ini_set ( "docref_root", "http://www.php.net/");
    ini_set ( "error_prepend_string", "<div style='color:red; font-family:verdana; border:1px solid red; padding:5px;'>");
    ini_set ( "error_append_string", "</div>");
}
peterh
  • 11,875
  • 18
  • 85
  • 108
Eli
  • 97,462
  • 20
  • 76
  • 81
  • @Eli, This has a runtime overhead though, **per page request**. – Pacerier Oct 14 '14 at 09:35
  • up 1 for the concept that overlook debug settings however server is configured, good while you are deploying or maintaining (under development) – justnajm Jul 20 '17 at 10:04
16
ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);
Abuzer Firdousi
  • 1,552
  • 1
  • 10
  • 25
16

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
sjas
  • 18,644
  • 14
  • 87
  • 92
Ram
  • 1,161
  • 1
  • 11
  • 34
15
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.

Janyk
  • 571
  • 3
  • 18
Yan.Zero
  • 449
  • 4
  • 12
15

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

Nette Tracy screenshot

Janyk
  • 571
  • 3
  • 18
Ondřej Šotek
  • 1,793
  • 1
  • 15
  • 24
  • 3
    Tracy takes care about proper setting of all display errors and error reporting options to provide output in such situations as described in original post... So this tool is especially helpful for addressing asker "Can anyone recommend good PHP debugging tips, tools and techniques?". – Jan Drábek Jul 05 '16 at 12:25
10
error_reporting(E_ALL | E_STRICT);

And turn on display errors in php.ini

Ólafur Waage
  • 68,817
  • 22
  • 142
  • 198
9

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');
soulmerge
  • 73,842
  • 19
  • 118
  • 155
8

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;
}
Brad Larson
  • 170,088
  • 45
  • 397
  • 571
Code Synthesis
  • 485
  • 4
  • 10
6

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.

user1681048
  • 71
  • 1
  • 4
6

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.

Unihedron
  • 10,902
  • 13
  • 62
  • 72
Ashutosh Jha
  • 150
  • 4
  • 18
6

open your php.ini, make sure it's set to:

display_errors = On

restart your server.

Otiel
  • 18,404
  • 16
  • 78
  • 126
user577803
  • 61
  • 1
  • 1
5

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.

Janyk
  • 571
  • 3
  • 18
5

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);
Phil
  • 157,677
  • 23
  • 242
  • 245
5

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.

Daniel Sorichetti
  • 1,921
  • 1
  • 20
  • 34
4

This answer is brought to you by the department of redundancy department.

  1. ini_set() / php.ini / .htaccess / .user.ini

    The settings display_errors and error_reporting have been covered sufficiently now. But just to recap when to use which option:

    • ini_set() and error_reporting() apply for runtime errors only.
    • php.ini should primarily be edited for development setups. (Webserver and CLI version often have different php.ini's)
    • .htaccess flags only work for dated setups (Find a new hoster! Well managed servers are cheaper.)
    • .user.ini are partial php.ini's for modern setups (FCGI/FPM)

    And as crude alternative for runtime errors you can often use:

    set_error_handler("var_dump");   // ignores error_reporting and `@` suppression
    
  2. error_get_last()

    Can be used to retrieve the last runtime notice/warning/error, when error_display is disabled.

  3. $php_errormsg

    Is a superlocal variable, which also contains the last PHP runtime message.

  4. isset() begone!

    I know this will displease a lot of folks, but isset and empty should not be used by newcomers. You can add the notice suppression after you verified your code is working. But never before.

    A lot of the "something doesn't work" questions we get lately are the result of typos like:

    if(isset($_POST['sumbit']))
    #                  ↑↑
    

    You won't get any useful notices if your code is littered with isset/empty/array_keys_exists. It's sometimes more sensible to use @, so notices and warnings go to the logs at least.

  5. assert_options(ASSERT_ACTIVE|ASSERT_WARNING);

    To get warnings for assert() sections. (Pretty uncommon, but more proficient code might contain some.)

    PHP7 requires zend.assertions=1 in the php.ini as well.

  6. declare(strict_types=1);

    Bending PHP into a strictly typed language is not going to fix a whole lot of logic errors, but it's definitely an option for debugging purposes.

  7. PDO / MySQLi

    And @Phil already mentioned PDO/MySQLi error reporting options. Similar options exist for other database APIs of course.

  8. json_last_error() + json_last_error_msg

    For JSON parsing.

  9. preg_last_error()

    For regexen.

  10. CURLOPT_VERBOSE

    To debug curl requests, you need CURLOPT_VERBOSE at the very least.

  11. shell/exec()

    Likewise will shell command execution not yield errors on its own. You always need 2>&1 and peek at the $errno.

mario
  • 144,265
  • 20
  • 237
  • 291
4

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"
Ayman Hourieh
  • 132,184
  • 23
  • 144
  • 116
4

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
jmucchiello
  • 18,754
  • 7
  • 41
  • 61
3

For those who use nginx and have a white screen even for file with <?php echo 123;. In my case I didn't have this required option for PHP in nginx config file:

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

This option wasn't in fastcgi_params file, so PHP didn't work and there wasn't any errors in logs.

AVKurov
  • 156
  • 1
  • 2
  • 6
  • I had the same problem and its due to Nginx default configuration file missing that line . – Salem Aug 13 '19 at 20:32
2

Try setting your error reporting level in your actual php files. Or, as others have suggested, check your server settings--it could be something in php.ini, or some restriction as regards your host. Don't just rely on .htaccess. Also, when troubleshooting, print_r any variables you might think fishy.

Lewis LaCook
  • 104
  • 1
  • 5
  • I don't have access to php.ini. And when these errors pop up, it's a syntax error, so print_r doesn't help. – Matthew Scharley Sep 25 '09 at 04:36
  • 3
    If you don't have access to php.ini, you should not be developing on that server. Use shared hosting for production, your local machine for development. – carl Sep 25 '09 at 04:46
  • And when errors happen in production? We'd all like to believe that doesn't happen, but it does. – Matthew Scharley Sep 25 '09 at 04:48
  • 2
    If you have a parse error in production, something is wrong with your development model. :) If you have a different error, you don't want that error displayed to the user anyways + you should have a proper error handling mechanism. – carl Sep 25 '09 at 04:53
  • Mmm, a parse error in production would be interesting. And I don't disagree on any particular point, other than that I need to use the production server in this particular case because I have people testing it from outside my local LAN and I'd rather not expose my test server to the intertubes. – Matthew Scharley Sep 25 '09 at 05:05
  • 2
    I would suggest you download the apache XAMP or WAMPserver and set up a development environments on your PC. If your workstation environment is as constrained as your server environment you could use http://portableapps.com/apps/development/xampp which doesnt requires any admin rights or special priviledges to install and run. – James Anderson Sep 25 '09 at 05:06
  • I do have a local dev server. See my comment above, *I have people testing it from outside my local LAN and I'd rather not expose my test server to the intertubes.* – Matthew Scharley Sep 25 '09 at 05:17
2

Are you sure PHP is actually picking up the 'display_errors' setting from .htaccess? Check the output of the phpinfo() function to make sure.

Also, you should check to make sure that you haven't used '@', it could be silencing your errors if you have used '@include ...' or '@some_function(...)', somewhere up the stack trace.

too much php
  • 88,666
  • 34
  • 128
  • 138
  • It is. `display_errors` is off in the serverwide config, but it displays lesser errors like parameter number mismatches, etc. I havn't used the `@` operator at all in this project, and generally tend to avoid it for just that reason. – Matthew Scharley Sep 25 '09 at 04:47
  • You should also check that display_errors is not being changed by a PHP script somewhere. – too much php Sep 25 '09 at 04:56
  • I've build this framework from the ground up, so no, it's not (unless something in the core changes it for some reason...) – Matthew Scharley Sep 25 '09 at 05:18
  • If you call an undefined function (to generate a fatal error), do you see that error message? – too much php Sep 25 '09 at 06:11
2

PHP Error Handling

Sometimes your application will not run as it supposed to do, resulting in an error. There are a number of reasons that may cause errors, for example:

The Web server might run out of disk space A user might have entered an invalid value in a form field The file or database record that you were trying to access may not exist The application might not have permission to write to a file on the disk A service that the application needs to access might be temporarily unavailable These types of errors are known as run-time errors, because they occur at the time the script runs. They are distinct from syntax errors that need to be fixed before the script will run.

A professional application must have the capabilities to handle such run-time error gracefully. Usually this means informing the user about the problem more clearly and precisely.

Understanding Error Levels

Usually, when there's a problem that prevents a script from running properly, the PHP engine triggers an error. Each error is represented by an integer value and an associated constant. The following table list some of the common error levels:

enter image description here

The PHP engine triggers an error whenever it encounters a problem with your script, but you can also trigger errors yourself to generate more user friendly error messages. This way you can make your application more sofisticated. The following section describes some of common methods used for handling errors in PHP:

Basic Error Handling Using the die() Function

<?php // Try to open a non-existent file
     $file = fopen("sample.txt", "r");
?>

If the file does not exist you might get an error like this: Warning: fopen(sample.txt) [function.fopen]: failed to open stream: No such file or directory in C:\wamp\www\project\test.php on line 2

If we follow some simple steps we can prevent the users from getting such error message:

<?php
if(file_exists("sample.txt")){
    $file = fopen("sample.txt", "r");
} else{
    die("Error: The file you are trying to access doesn't exist.");
}
?>

Now if you run the above script you will get the error message like this: Error: The file you are trying to access doesn't exist.

As you can see by implementing a simple check whether the file exist or not before trying to access it, we can generate an error message that is more meaningful to the user.

The die() function used above simply display the custom error message and terminate the current script if 'sample.txt' file is not found.

Creating a Custom Error Handler

You can create your own error handler function to deal with the run-time error generated by PHP engine. The custom error handler provides you greater flexibility and better control over the errors, it can inspect the error and decide what to do with the error, it might display a message to the user, log the error in a file or database or send by e-mail, attempt to fix the problem and carry on, exit the execution of the script or ignore the error altogether.

The custom error handler function must be able to handle at least two parameters (errno and errstr), however it can optionally accept an additional three parameters (errfile, errline, and errcontext), as described below:

enter image description here

Here's an example of a simple custom error handling function. This handler, customError() is triggered whenever an error occurred, no matter how trivial. It then outputs the details of the error to the browser and stops the execution of the script.

<?php
// Error handler function
function customError($errno, $errstr){
    echo "<b>Error:</b> [$errno] $errstr";
}
?>

You need to tell the PHP to use your custom error handler function — just call the built-in set_error_handler() function, passing in the name of the function.

<?php
// Error handler function
function customError($errno, $errstr){
    echo "<b>Error:</b> [$errno] $errstr";
}
 
// Set error handler
set_error_handler("customError");
 
// Trigger error
echo($test);
?>

Error Logging

Log Error Messages in a Text File

You can also logs details of the error to the log file, like this:

<?php
function calcDivision($dividend, $divisor){
    if($divisor == 0){
        trigger_error("calcDivision(): The divisor cannot be zero", E_USER_WARNING);
        return false;
    } else{
        return($dividend / $divisor);
    }
}
function customError($errno, $errstr, $errfile, $errline, $errcontext){
    $message = date("Y-m-d H:i:s - ");
    $message .= "Error: [" . $errno ."], " . "$errstr in $errfile on line $errline, ";
    $message .= "Variables:" . print_r($errcontext, true) . "\r\n";
    
    error_log($message, 3, "logs/app_errors.log");
    die("There was a problem, please try again.");
}
set_error_handler("customError");
echo calcDivision(10, 0);
echo "This will never be printed.";
?>

Trigger an Error

Although the PHP engine triggers an error whenever it encounters a problem with your script, however you can also trigger errors yourself. This can help to make your application more robust, because it can flag potential problems before they turn into serious errors.

To trigger an error from within your script, call the trigger_error() function, passing in the error message that you want to generate:

trigger_error("There was a problem.");

Consider the following function that calculates division of the two numbers.

<?php
function calcDivision($dividend, $divisor){
    return($dividend / $divisor);
}
 
// Calling the function
echo calcDivision(10, 0);
?>

If a value of zero (0) is passed as the $divisor parameter, the error generated by the PHP engine will look something like this: Warning: Division by zero in C:\wamp\www\project\test.php on line 3

This message doesn't look very informative. Consider the following example that uses the trigger_error() function to generate the error.

<?php
function calcDivision($dividend, $divisor){
    if($divisor == 0){
        trigger_error("The divisor cannot be zero", E_USER_WARNING);
        return false;
    } else{
        return($dividend / $divisor);
    }
}
 
// Calling the function
echo calcDivision(10, 0);
?>

Now the script generates this error message: Warning: The divisor cannot be zero in C:\wamp\www\project\error.php on line 4

As you can see the error message generated by the second example explains the problem more clearly as compared to the previous one.

Reference: https://www.tutorialrepublic.com/php-tutorial/php-error-handling.php

Yogi Ghorecha
  • 1,584
  • 1
  • 19
  • 26
  • You have copied your answer from https://www.tutorialrepublic.com/php-tutorial/php-error-handling.php without attribution. Do not present the work of others as your own. – skomisa Oct 01 '22 at 05:42
1

using @inexistent_function_call(); in your code will cause the intepreter to quietly die and abort the script parsing. You should check for invalid functions and try not to use the error-supressing operator(the @ char )

Quamis
  • 10,924
  • 12
  • 50
  • 66
1

You can also run the file in the Terminal (command line) like so: php -f filename.php.

This runs your code and gives you the same output in case of any errors that you'd see in the error.log. It mentions the error and the line number.

Aamnah
  • 559
  • 6
  • 9
0

Some applications do handle these instructions themselves, by calling something like this:

error_reporting(E_ALL & ~E_DEPRECATED); or error_reporting(0);

And thus overriding your .htaccess settings.

Denegen
  • 17
  • 1
0

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) { /* ... */
kris
  • 11,868
  • 9
  • 88
  • 110
0

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

Vladimir Ramik
  • 1,920
  • 2
  • 13
  • 23
0

I fixed my entire 500 problem like this:

A. Check php.ini parameters

  1. php.ini >> error_reporting = E_ALL | E_STRICT
  2. php.ini >> display_errors = On
  3. php.ini >> display_startup_errors = Off

B. Update IIS manager parameters

  1. IIS Manager >> Error Pages >> 500 >> Edit feature settings >> detailed errors

in this step, you get 500 errors like this and with no html loading.

enter image description here

  1. IIS Manager >> FastCGI Settings >> php-cgi.exe >> standard error mode >> IgnoreAndReurn200

in this step, you can see html page including php errors like this. enter image description here

AND DONE :)

Saghachi
  • 851
  • 11
  • 19
-1

If the error is in PHP code, you can use error_reporting() function within your code to set to the report all.

However, this does not handle the situation when PHP crashes. Information about that is only available in server logs. Maybe you don't have access to those, but many hosting providers I've worked with have some way to let you access it. For example, the approach I like best is that it creates the error_log file in the current directory where .php resides. Try searching there or contact your hosting provider about this.

Milan Babuškov
  • 59,775
  • 49
  • 126
  • 179