How to get useful error messages in PHP?
I find programming in PHP quite frustrating. Quite often I will try and run the script and just get a blank screen back. No error message, just 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?.
So, is there a way to get PHP to produce useful error message like Java does?
Can anyone recommend good PHP debugging tips, tools and techniques?
php debugging error-handling
add a comment |
I find programming in PHP quite frustrating. Quite often I will try and run the script and just get a blank screen back. No error message, just 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?.
So, is there a way to get PHP to produce useful error message like Java does?
Can anyone recommend good PHP debugging tips, tools and techniques?
php debugging error-handling
coding.smashingmagazine.com/2011/11/30/…
– Alex
Jul 15 '12 at 14:54
1
Also see stackoverflow.com/q/1475297/632951
– Pacerier
Oct 14 '14 at 9:37
3
@JuannStrauss, That's understating it. And when you finally see the errors, it saysT_PAAMAYIM_NEKUDOTAYIM
. Or maybe "must be an instance of integer, integer given".
– Pacerier
Apr 3 '15 at 20:02
Tutorial on this: code2real.blogspot.com/2015/06/…
– Pupil
Sep 9 '15 at 7:21
add a comment |
I find programming in PHP quite frustrating. Quite often I will try and run the script and just get a blank screen back. No error message, just 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?.
So, is there a way to get PHP to produce useful error message like Java does?
Can anyone recommend good PHP debugging tips, tools and techniques?
php debugging error-handling
I find programming in PHP quite frustrating. Quite often I will try and run the script and just get a blank screen back. No error message, just 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?.
So, is there a way to get PHP to produce useful error message like Java does?
Can anyone recommend good PHP debugging tips, tools and techniques?
php debugging error-handling
php debugging error-handling
edited Mar 22 '17 at 16:12
Taryn♦
190k47291354
190k47291354
asked May 10 '09 at 9:48
CandidasaCandidasa
3,74792530
3,74792530
coding.smashingmagazine.com/2011/11/30/…
– Alex
Jul 15 '12 at 14:54
1
Also see stackoverflow.com/q/1475297/632951
– Pacerier
Oct 14 '14 at 9:37
3
@JuannStrauss, That's understating it. And when you finally see the errors, it saysT_PAAMAYIM_NEKUDOTAYIM
. Or maybe "must be an instance of integer, integer given".
– Pacerier
Apr 3 '15 at 20:02
Tutorial on this: code2real.blogspot.com/2015/06/…
– Pupil
Sep 9 '15 at 7:21
add a comment |
coding.smashingmagazine.com/2011/11/30/…
– Alex
Jul 15 '12 at 14:54
1
Also see stackoverflow.com/q/1475297/632951
– Pacerier
Oct 14 '14 at 9:37
3
@JuannStrauss, That's understating it. And when you finally see the errors, it saysT_PAAMAYIM_NEKUDOTAYIM
. Or maybe "must be an instance of integer, integer given".
– Pacerier
Apr 3 '15 at 20:02
Tutorial on this: code2real.blogspot.com/2015/06/…
– Pupil
Sep 9 '15 at 7:21
coding.smashingmagazine.com/2011/11/30/…
– Alex
Jul 15 '12 at 14:54
coding.smashingmagazine.com/2011/11/30/…
– Alex
Jul 15 '12 at 14:54
1
1
Also see stackoverflow.com/q/1475297/632951
– Pacerier
Oct 14 '14 at 9:37
Also see stackoverflow.com/q/1475297/632951
– Pacerier
Oct 14 '14 at 9:37
3
3
@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".– Pacerier
Apr 3 '15 at 20:02
@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".– Pacerier
Apr 3 '15 at 20:02
Tutorial on this: code2real.blogspot.com/2015/06/…
– Pupil
Sep 9 '15 at 7:21
Tutorial on this: code2real.blogspot.com/2015/06/…
– Pupil
Sep 9 '15 at 7:21
add a comment |
29 Answers
29
active
oldest
votes
For syntax errors, you need to enable error display in the php.ini. By default these are 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. If you can't modify the php.ini, you can also add the following lines to an .htaccess file:
php_flag display_errors on
php_value error_reporting 2039
You may want to consider using the value of E_ALL (as mentioned by Gumbo) for your version of PHP for error_reporting
to get all of the errors. more info
3 other items: (1) You can check the error log file as it will have all of the errors (unless logging has been disabled). (2) Adding the following 2 lines will help you debug errors that are not syntax errors:
error_reporting(-1);
ini_set('display_errors', 'On');
(3) Another option is to use an editor that checks for errors when you type, such as PhpEd. PhpEd also comes 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.)
Cartman's link is also very good: http://www.ibm.com/developerworks/library/os-debug/
3
Did you read my entire answer? I specifically say this won't work for syntax errors, whereas you don't mention that. Putting your code in would make no difference.
– Darryl Hein
May 10 '09 at 10:04
1
That's right. I should have thought of mentioning it.
– Tomalak
May 10 '09 at 10:10
22
2039 is the value ofE_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 docs.php.net/manual/en/errorfunc.constants.php
– Gumbo
May 10 '09 at 17:59
11
so why not error_reporting(-1) ?
– ts.
Dec 29 '10 at 14:12
1
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
|
show 5 more comments
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
26
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 4 '11 at 19:49
6
Run phpinfo() to find the correct php.ini file. Look for the Loaded Configuration File line.
– borrible
Jul 5 '11 at 8:01
39
I come here at least once a day copying this..I should probably just memorize it.
– Subie
Jan 22 '14 at 19: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
1
This answer will fail on php7 when strict typing is enabled, because the second parameter ofini_set
is a string.
– PeeHaa
Sep 4 '15 at 18:16
|
show 3 more comments
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.
2
This doesn't work for syntax errors as Candidasa mentioned.
– Darryl Hein
May 10 '09 at 9:56
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
worked for ipage host. thanks
– shady sherif
Apr 17 '18 at 15:38
add a comment |
PHP Configuration
2 entries in php.ini dictate the output of errors:
display_errors
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.
add a comment |
There is a really useful extension called "xdebug" that will make your reports much nicer as well.
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
+1 I use eclipse with xdebug for full step over/step into debugging. Makes PHP development sane!
– Wayne
May 10 '09 at 10:26
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
See also "Whoops" error handler
– Jonathan
May 9 '18 at 18:24
add a comment |
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 ConstantsDocs
error_reporting()
Docs
display_errors
Docs
add a comment |
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.
1
This is what i looking for ! :), Why no one give it upvote ? Debuging a website is only neeeded by webmaster and not client. So run it locally is the best for security.
– Michael Antonio
Jan 26 '14 at 1:05
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
add a comment |
On the top of the page choose a parameter
error_reporting(E_ERROR | E_WARNING | E_PARSE);
add a comment |
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
add a comment |
I recommend Nette Tracy for better visualization of errors and exceptions in PHP:
1
This does not answer the question...
– AStopher
Jun 17 '16 at 19:34
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 5 '16 at 12:25
add a comment |
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.
Xdebug can be enable from php.ini
– jewelhuq
Jan 5 '16 at 12:32
add a comment |
error_reporting(E_ALL | E_STRICT);
And turn on display errors in php.ini
add a comment |
ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);
add a comment |
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');
This doesn't work for syntax errors as Candidasa mentioned.
– Darryl Hein
May 10 '09 at 9:58
Yes, but that is already covered in all other answers.
– soulmerge
May 10 '09 at 9:59
add a comment |
Try this PHP error reporting reference tool. It's a very good visual reference and helped me understand the complex error reporting mechanism.
Awesome ..... also something equivalent here too w3schools.com/php/func_error_reporting.asp
– MarcoZen
Oct 30 '13 at 4:53
add a comment |
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.
add a comment |
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;
}
add a comment |
FirePHP can be useful as well.
add a comment |
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.
add a comment |
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"
add a comment |
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.
As with Tomalak's answer, this doesn't work for syntax errors.
– Darryl Hein
May 10 '09 at 17:58
add a comment |
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
add a comment |
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.
add a comment |
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...
- Always see database related errors, and
- 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);
add a comment |
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¶m=val').done(function(data) { /* ... */
add a comment |
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.
add a comment |
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
add a comment |
Use Kint. It is combination of debugging commands on steroids.
https://kint-php.github.io/kint/
It is very similar to Nette Tracy
404 not found...
– Yousha Aleayoub
Aug 5 '18 at 20:38
yep it's been a while, link updated now. @YoushaAleayoub
– siniradam
Aug 6 '18 at 23:12
add a comment |
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);
}
?>
Hate to be that guy, but this is a bad example. Local File Inclusion
– Darren
Jun 27 '14 at 7:57
1
You are right - this mechanism should not be used for production, it's simply a tool to catch these things while developing/debugging/testing.
– MBaas
Jul 2 '14 at 7:36
add a comment |
protected by Samuel Liew♦ Oct 5 '15 at 9:00
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
29 Answers
29
active
oldest
votes
29 Answers
29
active
oldest
votes
active
oldest
votes
active
oldest
votes
For syntax errors, you need to enable error display in the php.ini. By default these are 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. If you can't modify the php.ini, you can also add the following lines to an .htaccess file:
php_flag display_errors on
php_value error_reporting 2039
You may want to consider using the value of E_ALL (as mentioned by Gumbo) for your version of PHP for error_reporting
to get all of the errors. more info
3 other items: (1) You can check the error log file as it will have all of the errors (unless logging has been disabled). (2) Adding the following 2 lines will help you debug errors that are not syntax errors:
error_reporting(-1);
ini_set('display_errors', 'On');
(3) Another option is to use an editor that checks for errors when you type, such as PhpEd. PhpEd also comes 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.)
Cartman's link is also very good: http://www.ibm.com/developerworks/library/os-debug/
3
Did you read my entire answer? I specifically say this won't work for syntax errors, whereas you don't mention that. Putting your code in would make no difference.
– Darryl Hein
May 10 '09 at 10:04
1
That's right. I should have thought of mentioning it.
– Tomalak
May 10 '09 at 10:10
22
2039 is the value ofE_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 docs.php.net/manual/en/errorfunc.constants.php
– Gumbo
May 10 '09 at 17:59
11
so why not error_reporting(-1) ?
– ts.
Dec 29 '10 at 14:12
1
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
|
show 5 more comments
For syntax errors, you need to enable error display in the php.ini. By default these are 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. If you can't modify the php.ini, you can also add the following lines to an .htaccess file:
php_flag display_errors on
php_value error_reporting 2039
You may want to consider using the value of E_ALL (as mentioned by Gumbo) for your version of PHP for error_reporting
to get all of the errors. more info
3 other items: (1) You can check the error log file as it will have all of the errors (unless logging has been disabled). (2) Adding the following 2 lines will help you debug errors that are not syntax errors:
error_reporting(-1);
ini_set('display_errors', 'On');
(3) Another option is to use an editor that checks for errors when you type, such as PhpEd. PhpEd also comes 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.)
Cartman's link is also very good: http://www.ibm.com/developerworks/library/os-debug/
3
Did you read my entire answer? I specifically say this won't work for syntax errors, whereas you don't mention that. Putting your code in would make no difference.
– Darryl Hein
May 10 '09 at 10:04
1
That's right. I should have thought of mentioning it.
– Tomalak
May 10 '09 at 10:10
22
2039 is the value ofE_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 docs.php.net/manual/en/errorfunc.constants.php
– Gumbo
May 10 '09 at 17:59
11
so why not error_reporting(-1) ?
– ts.
Dec 29 '10 at 14:12
1
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
|
show 5 more comments
For syntax errors, you need to enable error display in the php.ini. By default these are 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. If you can't modify the php.ini, you can also add the following lines to an .htaccess file:
php_flag display_errors on
php_value error_reporting 2039
You may want to consider using the value of E_ALL (as mentioned by Gumbo) for your version of PHP for error_reporting
to get all of the errors. more info
3 other items: (1) You can check the error log file as it will have all of the errors (unless logging has been disabled). (2) Adding the following 2 lines will help you debug errors that are not syntax errors:
error_reporting(-1);
ini_set('display_errors', 'On');
(3) Another option is to use an editor that checks for errors when you type, such as PhpEd. PhpEd also comes 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.)
Cartman's link is also very good: http://www.ibm.com/developerworks/library/os-debug/
For syntax errors, you need to enable error display in the php.ini. By default these are 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. If you can't modify the php.ini, you can also add the following lines to an .htaccess file:
php_flag display_errors on
php_value error_reporting 2039
You may want to consider using the value of E_ALL (as mentioned by Gumbo) for your version of PHP for error_reporting
to get all of the errors. more info
3 other items: (1) You can check the error log file as it will have all of the errors (unless logging has been disabled). (2) Adding the following 2 lines will help you debug errors that are not syntax errors:
error_reporting(-1);
ini_set('display_errors', 'On');
(3) Another option is to use an editor that checks for errors when you type, such as PhpEd. PhpEd also comes 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.)
Cartman's link is also very good: http://www.ibm.com/developerworks/library/os-debug/
edited Oct 10 '15 at 12:27
Sumurai8
13.4k83263
13.4k83263
answered May 10 '09 at 9:52
Darryl HeinDarryl Hein
68.8k83187245
68.8k83187245
3
Did you read my entire answer? I specifically say this won't work for syntax errors, whereas you don't mention that. Putting your code in would make no difference.
– Darryl Hein
May 10 '09 at 10:04
1
That's right. I should have thought of mentioning it.
– Tomalak
May 10 '09 at 10:10
22
2039 is the value ofE_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 docs.php.net/manual/en/errorfunc.constants.php
– Gumbo
May 10 '09 at 17:59
11
so why not error_reporting(-1) ?
– ts.
Dec 29 '10 at 14:12
1
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
|
show 5 more comments
3
Did you read my entire answer? I specifically say this won't work for syntax errors, whereas you don't mention that. Putting your code in would make no difference.
– Darryl Hein
May 10 '09 at 10:04
1
That's right. I should have thought of mentioning it.
– Tomalak
May 10 '09 at 10:10
22
2039 is the value ofE_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 docs.php.net/manual/en/errorfunc.constants.php
– Gumbo
May 10 '09 at 17:59
11
so why not error_reporting(-1) ?
– ts.
Dec 29 '10 at 14:12
1
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
3
3
Did you read my entire answer? I specifically say this won't work for syntax errors, whereas you don't mention that. Putting your code in would make no difference.
– Darryl Hein
May 10 '09 at 10:04
Did you read my entire answer? I specifically say this won't work for syntax errors, whereas you don't mention that. Putting your code in would make no difference.
– Darryl Hein
May 10 '09 at 10:04
1
1
That's right. I should have thought of mentioning it.
– Tomalak
May 10 '09 at 10:10
That's right. I should have thought of mentioning it.
– Tomalak
May 10 '09 at 10:10
22
22
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 docs.php.net/manual/en/errorfunc.constants.php– Gumbo
May 10 '09 at 17:59
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 docs.php.net/manual/en/errorfunc.constants.php– Gumbo
May 10 '09 at 17:59
11
11
so why not error_reporting(-1) ?
– ts.
Dec 29 '10 at 14:12
so why not error_reporting(-1) ?
– ts.
Dec 29 '10 at 14:12
1
1
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
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
|
show 5 more comments
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
26
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 4 '11 at 19:49
6
Run phpinfo() to find the correct php.ini file. Look for the Loaded Configuration File line.
– borrible
Jul 5 '11 at 8:01
39
I come here at least once a day copying this..I should probably just memorize it.
– Subie
Jan 22 '14 at 19: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
1
This answer will fail on php7 when strict typing is enabled, because the second parameter ofini_set
is a string.
– PeeHaa
Sep 4 '15 at 18:16
|
show 3 more comments
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
26
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 4 '11 at 19:49
6
Run phpinfo() to find the correct php.ini file. Look for the Loaded Configuration File line.
– borrible
Jul 5 '11 at 8:01
39
I come here at least once a day copying this..I should probably just memorize it.
– Subie
Jan 22 '14 at 19: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
1
This answer will fail on php7 when strict typing is enabled, because the second parameter ofini_set
is a string.
– PeeHaa
Sep 4 '15 at 18:16
|
show 3 more comments
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
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
edited May 9 '16 at 22:25
janykste
562318
562318
answered Jul 4 '11 at 19:46
EljakimEljakim
6,13421114
6,13421114
26
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 4 '11 at 19:49
6
Run phpinfo() to find the correct php.ini file. Look for the Loaded Configuration File line.
– borrible
Jul 5 '11 at 8:01
39
I come here at least once a day copying this..I should probably just memorize it.
– Subie
Jan 22 '14 at 19: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
1
This answer will fail on php7 when strict typing is enabled, because the second parameter ofini_set
is a string.
– PeeHaa
Sep 4 '15 at 18:16
|
show 3 more comments
26
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 4 '11 at 19:49
6
Run phpinfo() to find the correct php.ini file. Look for the Loaded Configuration File line.
– borrible
Jul 5 '11 at 8:01
39
I come here at least once a day copying this..I should probably just memorize it.
– Subie
Jan 22 '14 at 19: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
1
This answer will fail on php7 when strict typing is enabled, because the second parameter ofini_set
is a string.
– PeeHaa
Sep 4 '15 at 18:16
26
26
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 4 '11 at 19:49
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 4 '11 at 19:49
6
6
Run phpinfo() to find the correct php.ini file. Look for the Loaded Configuration File line.
– borrible
Jul 5 '11 at 8:01
Run phpinfo() to find the correct php.ini file. Look for the Loaded Configuration File line.
– borrible
Jul 5 '11 at 8:01
39
39
I come here at least once a day copying this..I should probably just memorize it.
– Subie
Jan 22 '14 at 19:01
I come here at least once a day copying this..I should probably just memorize it.
– Subie
Jan 22 '14 at 19:01
1
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
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
1
1
This answer will fail on php7 when strict typing is enabled, because the second parameter of
ini_set
is a string.– PeeHaa
Sep 4 '15 at 18:16
This answer will fail on php7 when strict typing is enabled, because the second parameter of
ini_set
is a string.– PeeHaa
Sep 4 '15 at 18:16
|
show 3 more comments
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.
2
This doesn't work for syntax errors as Candidasa mentioned.
– Darryl Hein
May 10 '09 at 9:56
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
worked for ipage host. thanks
– shady sherif
Apr 17 '18 at 15:38
add a comment |
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.
2
This doesn't work for syntax errors as Candidasa mentioned.
– Darryl Hein
May 10 '09 at 9:56
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
worked for ipage host. thanks
– shady sherif
Apr 17 '18 at 15:38
add a comment |
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.
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.
answered May 10 '09 at 9:54
TomalakTomalak
258k51429547
258k51429547
2
This doesn't work for syntax errors as Candidasa mentioned.
– Darryl Hein
May 10 '09 at 9:56
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
worked for ipage host. thanks
– shady sherif
Apr 17 '18 at 15:38
add a comment |
2
This doesn't work for syntax errors as Candidasa mentioned.
– Darryl Hein
May 10 '09 at 9:56
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
worked for ipage host. thanks
– shady sherif
Apr 17 '18 at 15:38
2
2
This doesn't work for syntax errors as Candidasa mentioned.
– Darryl Hein
May 10 '09 at 9:56
This doesn't work for syntax errors as Candidasa mentioned.
– Darryl Hein
May 10 '09 at 9:56
2
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
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
worked for ipage host. thanks
– shady sherif
Apr 17 '18 at 15:38
worked for ipage host. thanks
– shady sherif
Apr 17 '18 at 15:38
add a comment |
PHP Configuration
2 entries in php.ini dictate the output of errors:
display_errors
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.
add a comment |
PHP Configuration
2 entries in php.ini dictate the output of errors:
display_errors
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.
add a comment |
PHP Configuration
2 entries in php.ini dictate the output of errors:
display_errors
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.
PHP Configuration
2 entries in php.ini dictate the output of errors:
display_errors
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.
edited May 23 '17 at 11:33
Community♦
11
11
answered Feb 2 '14 at 20:47
Madara Uchiha♦Madara Uchiha
116k43210261
116k43210261
add a comment |
add a comment |
There is a really useful extension called "xdebug" that will make your reports much nicer as well.
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
+1 I use eclipse with xdebug for full step over/step into debugging. Makes PHP development sane!
– Wayne
May 10 '09 at 10:26
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
See also "Whoops" error handler
– Jonathan
May 9 '18 at 18:24
add a comment |
There is a really useful extension called "xdebug" that will make your reports much nicer as well.
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
+1 I use eclipse with xdebug for full step over/step into debugging. Makes PHP development sane!
– Wayne
May 10 '09 at 10:26
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
See also "Whoops" error handler
– Jonathan
May 9 '18 at 18:24
add a comment |
There is a really useful extension called "xdebug" that will make your reports much nicer as well.
There is a really useful extension called "xdebug" that will make your reports much nicer as well.
answered May 10 '09 at 9:59
gnarfgnarf
90.6k19116155
90.6k19116155
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
+1 I use eclipse with xdebug for full step over/step into debugging. Makes PHP development sane!
– Wayne
May 10 '09 at 10:26
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
See also "Whoops" error handler
– Jonathan
May 9 '18 at 18:24
add a comment |
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
+1 I use eclipse with xdebug for full step over/step into debugging. Makes PHP development sane!
– Wayne
May 10 '09 at 10:26
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
See also "Whoops" error handler
– Jonathan
May 9 '18 at 18:24
2
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
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
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
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
1
+1 I use eclipse with xdebug for full step over/step into debugging. Makes PHP development sane!
– Wayne
May 10 '09 at 10:26
+1 I use eclipse with xdebug for full step over/step into debugging. Makes PHP development sane!
– Wayne
May 10 '09 at 10:26
1
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
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
See also "Whoops" error handler
– Jonathan
May 9 '18 at 18:24
See also "Whoops" error handler
– Jonathan
May 9 '18 at 18:24
add a comment |
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 ConstantsDocs
error_reporting()
Docs
display_errors
Docs
add a comment |
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 ConstantsDocs
error_reporting()
Docs
display_errors
Docs
add a comment |
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 ConstantsDocs
error_reporting()
Docs
display_errors
Docs
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 ConstantsDocs
error_reporting()
Docs
display_errors
Docs
edited Jan 24 '13 at 15:18
answered Jan 24 '13 at 15:06
hakrehakre
159k32298609
159k32298609
add a comment |
add a comment |
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.
1
This is what i looking for ! :), Why no one give it upvote ? Debuging a website is only neeeded by webmaster and not client. So run it locally is the best for security.
– Michael Antonio
Jan 26 '14 at 1:05
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
add a comment |
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.
1
This is what i looking for ! :), Why no one give it upvote ? Debuging a website is only neeeded by webmaster and not client. So run it locally is the best for security.
– Michael Antonio
Jan 26 '14 at 1:05
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
add a comment |
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.
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.
answered Jul 4 '11 at 19:49
Rich BradshawRich Bradshaw
51.8k39157231
51.8k39157231
1
This is what i looking for ! :), Why no one give it upvote ? Debuging a website is only neeeded by webmaster and not client. So run it locally is the best for security.
– Michael Antonio
Jan 26 '14 at 1:05
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
add a comment |
1
This is what i looking for ! :), Why no one give it upvote ? Debuging a website is only neeeded by webmaster and not client. So run it locally is the best for security.
– Michael Antonio
Jan 26 '14 at 1:05
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
1
1
This is what i looking for ! :), Why no one give it upvote ? Debuging a website is only neeeded by webmaster and not client. So run it locally is the best for security.
– Michael Antonio
Jan 26 '14 at 1:05
This is what i looking for ! :), Why no one give it upvote ? Debuging a website is only neeeded by webmaster and not client. So run it locally is the best for security.
– Michael Antonio
Jan 26 '14 at 1:05
2
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
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
add a comment |
On the top of the page choose a parameter
error_reporting(E_ERROR | E_WARNING | E_PARSE);
add a comment |
On the top of the page choose a parameter
error_reporting(E_ERROR | E_WARNING | E_PARSE);
add a comment |
On the top of the page choose a parameter
error_reporting(E_ERROR | E_WARNING | E_PARSE);
On the top of the page choose a parameter
error_reporting(E_ERROR | E_WARNING | E_PARSE);
answered May 6 '13 at 14:14
KldKld
5,04132444
5,04132444
add a comment |
add a comment |
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
add a comment |
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
add a comment |
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
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
edited Jul 16 '16 at 7:46
sjas
10.8k95970
10.8k95970
answered Jul 4 '11 at 19:54
RamRam
681732
681732
add a comment |
add a comment |
I recommend Nette Tracy for better visualization of errors and exceptions in PHP:
1
This does not answer the question...
– AStopher
Jun 17 '16 at 19:34
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 5 '16 at 12:25
add a comment |
I recommend Nette Tracy for better visualization of errors and exceptions in PHP:
1
This does not answer the question...
– AStopher
Jun 17 '16 at 19:34
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 5 '16 at 12:25
add a comment |
I recommend Nette Tracy for better visualization of errors and exceptions in PHP:
I recommend Nette Tracy for better visualization of errors and exceptions in PHP:
edited May 9 '16 at 23:41
janykste
562318
562318
answered Jul 15 '15 at 22:38
Ondřej ŠotekOndřej Šotek
9271722
9271722
1
This does not answer the question...
– AStopher
Jun 17 '16 at 19:34
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 5 '16 at 12:25
add a comment |
1
This does not answer the question...
– AStopher
Jun 17 '16 at 19:34
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 5 '16 at 12:25
1
1
This does not answer the question...
– AStopher
Jun 17 '16 at 19:34
This does not answer the question...
– AStopher
Jun 17 '16 at 19:34
3
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 5 '16 at 12:25
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 5 '16 at 12:25
add a comment |
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.
Xdebug can be enable from php.ini
– jewelhuq
Jan 5 '16 at 12:32
add a comment |
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.
Xdebug can be enable from php.ini
– jewelhuq
Jan 5 '16 at 12:32
add a comment |
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);
ini_set('display_errors', 1);
ini_set('html_errors', 1);
In addition, you can get more detailed information with xdebug.
edited May 9 '16 at 22:26
janykste
562318
562318
answered Aug 19 '14 at 15:36
Yan.ZeroYan.Zero
334310
334310
Xdebug can be enable from php.ini
– jewelhuq
Jan 5 '16 at 12:32
add a comment |
Xdebug can be enable from php.ini
– jewelhuq
Jan 5 '16 at 12:32
Xdebug can be enable from php.ini
– jewelhuq
Jan 5 '16 at 12:32
Xdebug can be enable from php.ini
– jewelhuq
Jan 5 '16 at 12:32
add a comment |
error_reporting(E_ALL | E_STRICT);
And turn on display errors in php.ini
add a comment |
error_reporting(E_ALL | E_STRICT);
And turn on display errors in php.ini
add a comment |
error_reporting(E_ALL | E_STRICT);
And turn on display errors in php.ini
error_reporting(E_ALL | E_STRICT);
And turn on display errors in php.ini
answered May 10 '09 at 9:54
Ólafur WaageÓlafur Waage
57.9k16130183
57.9k16130183
add a comment |
add a comment |
ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);
add a comment |
ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);
add a comment |
ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);
ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);
answered Dec 4 '17 at 20:54
Abuzer FirdousiAbuzer Firdousi
1,0981819
1,0981819
add a comment |
add a comment |
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');
This doesn't work for syntax errors as Candidasa mentioned.
– Darryl Hein
May 10 '09 at 9:58
Yes, but that is already covered in all other answers.
– soulmerge
May 10 '09 at 9:59
add a comment |
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');
This doesn't work for syntax errors as Candidasa mentioned.
– Darryl Hein
May 10 '09 at 9:58
Yes, but that is already covered in all other answers.
– soulmerge
May 10 '09 at 9:59
add a comment |
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');
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');
answered May 10 '09 at 9:54
soulmergesoulmerge
60.8k15103142
60.8k15103142
This doesn't work for syntax errors as Candidasa mentioned.
– Darryl Hein
May 10 '09 at 9:58
Yes, but that is already covered in all other answers.
– soulmerge
May 10 '09 at 9:59
add a comment |
This doesn't work for syntax errors as Candidasa mentioned.
– Darryl Hein
May 10 '09 at 9:58
Yes, but that is already covered in all other answers.
– soulmerge
May 10 '09 at 9:59
This doesn't work for syntax errors as Candidasa mentioned.
– Darryl Hein
May 10 '09 at 9:58
This doesn't work for syntax errors as Candidasa mentioned.
– Darryl Hein
May 10 '09 at 9:58
Yes, but that is already covered in all other answers.
– soulmerge
May 10 '09 at 9:59
Yes, but that is already covered in all other answers.
– soulmerge
May 10 '09 at 9:59
add a comment |
Try this PHP error reporting reference tool. It's a very good visual reference and helped me understand the complex error reporting mechanism.
Awesome ..... also something equivalent here too w3schools.com/php/func_error_reporting.asp
– MarcoZen
Oct 30 '13 at 4:53
add a comment |
Try this PHP error reporting reference tool. It's a very good visual reference and helped me understand the complex error reporting mechanism.
Awesome ..... also something equivalent here too w3schools.com/php/func_error_reporting.asp
– MarcoZen
Oct 30 '13 at 4:53
add a comment |
Try this PHP error reporting reference tool. It's a very good visual reference and helped me understand the complex error reporting mechanism.
Try this PHP error reporting reference tool. It's a very good visual reference and helped me understand the complex error reporting mechanism.
answered Nov 25 '12 at 13:30
Rodney McIntoshRodney McIntosh
6911
6911
Awesome ..... also something equivalent here too w3schools.com/php/func_error_reporting.asp
– MarcoZen
Oct 30 '13 at 4:53
add a comment |
Awesome ..... also something equivalent here too w3schools.com/php/func_error_reporting.asp
– MarcoZen
Oct 30 '13 at 4:53
Awesome ..... also something equivalent here too w3schools.com/php/func_error_reporting.asp
– MarcoZen
Oct 30 '13 at 4:53
Awesome ..... also something equivalent here too w3schools.com/php/func_error_reporting.asp
– MarcoZen
Oct 30 '13 at 4:53
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered Jun 18 '14 at 1:03
user1681048user1681048
6613
6613
add a comment |
add a comment |
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;
}
add a comment |
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;
}
add a comment |
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;
}
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;
}
edited Mar 24 '16 at 14:57
Brad Larson♦
161k40364542
161k40364542
answered Jun 10 '14 at 13:37
Code SynthesisCode Synthesis
36538
36538
add a comment |
add a comment |
FirePHP can be useful as well.
add a comment |
FirePHP can be useful as well.
add a comment |
FirePHP can be useful as well.
FirePHP can be useful as well.
answered May 10 '09 at 10:21
Rich BradshawRich Bradshaw
51.8k39157231
51.8k39157231
add a comment |
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
edited Nov 10 '14 at 11:43
Unihedron
9,277104662
9,277104662
answered Nov 10 '14 at 11:23
Ashutosh JhaAshutosh Jha
101213
101213
add a comment |
add a comment |
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"
add a comment |
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"
add a comment |
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"
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"
edited May 10 '09 at 10:04
answered May 10 '09 at 9:58
Ayman HouriehAyman Hourieh
88.3k15129111
88.3k15129111
add a comment |
add a comment |
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.
As with Tomalak's answer, this doesn't work for syntax errors.
– Darryl Hein
May 10 '09 at 17:58
add a comment |
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.
As with Tomalak's answer, this doesn't work for syntax errors.
– Darryl Hein
May 10 '09 at 17:58
add a comment |
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.
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.
answered May 10 '09 at 12:09
Daniel SorichettiDaniel Sorichetti
1,39911731
1,39911731
As with Tomalak's answer, this doesn't work for syntax errors.
– Darryl Hein
May 10 '09 at 17:58
add a comment |
As with Tomalak's answer, this doesn't work for syntax errors.
– Darryl Hein
May 10 '09 at 17:58
As with Tomalak's answer, this doesn't work for syntax errors.
– Darryl Hein
May 10 '09 at 17:58
As with Tomalak's answer, this doesn't work for syntax errors.
– Darryl Hein
May 10 '09 at 17:58
add a comment |
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
add a comment |
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
add a comment |
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
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
answered May 10 '09 at 18:16
jmucchiellojmucchiello
14.4k53458
14.4k53458
add a comment |
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
edited May 9 '16 at 22:45
janykste
562318
562318
answered Feb 1 '14 at 6:24
user3176739
add a comment |
add a comment |
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...
- Always see database related errors, and
- 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);
add a comment |
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...
- Always see database related errors, and
- 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);
add a comment |
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...
- Always see database related errors, and
- 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);
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...
- Always see database related errors, and
- 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);
answered Sep 14 '18 at 3:31
PhilPhil
97.4k11140160
97.4k11140160
add a comment |
add a comment |
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¶m=val').done(function(data) { /* ... */
add a comment |
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¶m=val').done(function(data) { /* ... */
add a comment |
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¶m=val').done(function(data) { /* ... */
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¶m=val').done(function(data) { /* ... */
answered Jun 15 '13 at 11:55
kriskris
4,66733864
4,66733864
add a comment |
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered Oct 1 '14 at 19:48
PHPCoderPHPCoder
1
1
add a comment |
add a comment |
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
add a comment |
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
add a comment |
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
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
answered Mar 7 '15 at 18:16
Vladimir RamikVladimir Ramik
1,7741822
1,7741822
add a comment |
add a comment |
Use Kint. It is combination of debugging commands on steroids.
https://kint-php.github.io/kint/
It is very similar to Nette Tracy
404 not found...
– Yousha Aleayoub
Aug 5 '18 at 20:38
yep it's been a while, link updated now. @YoushaAleayoub
– siniradam
Aug 6 '18 at 23:12
add a comment |
Use Kint. It is combination of debugging commands on steroids.
https://kint-php.github.io/kint/
It is very similar to Nette Tracy
404 not found...
– Yousha Aleayoub
Aug 5 '18 at 20:38
yep it's been a while, link updated now. @YoushaAleayoub
– siniradam
Aug 6 '18 at 23:12
add a comment |
Use Kint. It is combination of debugging commands on steroids.
https://kint-php.github.io/kint/
It is very similar to Nette Tracy
Use Kint. It is combination of debugging commands on steroids.
https://kint-php.github.io/kint/
It is very similar to Nette Tracy
edited Aug 6 '18 at 23:11
answered Jun 29 '16 at 14:59
siniradamsiniradam
1,2561527
1,2561527
404 not found...
– Yousha Aleayoub
Aug 5 '18 at 20:38
yep it's been a while, link updated now. @YoushaAleayoub
– siniradam
Aug 6 '18 at 23:12
add a comment |
404 not found...
– Yousha Aleayoub
Aug 5 '18 at 20:38
yep it's been a while, link updated now. @YoushaAleayoub
– siniradam
Aug 6 '18 at 23:12
404 not found...
– Yousha Aleayoub
Aug 5 '18 at 20:38
404 not found...
– Yousha Aleayoub
Aug 5 '18 at 20:38
yep it's been a while, link updated now. @YoushaAleayoub
– siniradam
Aug 6 '18 at 23:12
yep it's been a while, link updated now. @YoushaAleayoub
– siniradam
Aug 6 '18 at 23:12
add a comment |
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);
}
?>
Hate to be that guy, but this is a bad example. Local File Inclusion
– Darren
Jun 27 '14 at 7:57
1
You are right - this mechanism should not be used for production, it's simply a tool to catch these things while developing/debugging/testing.
– MBaas
Jul 2 '14 at 7:36
add a comment |
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);
}
?>
Hate to be that guy, but this is a bad example. Local File Inclusion
– Darren
Jun 27 '14 at 7:57
1
You are right - this mechanism should not be used for production, it's simply a tool to catch these things while developing/debugging/testing.
– MBaas
Jul 2 '14 at 7:36
add a comment |
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);
}
?>
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);
}
?>
answered Jul 9 '13 at 18:05
MBaasMBaas
4,04032946
4,04032946
Hate to be that guy, but this is a bad example. Local File Inclusion
– Darren
Jun 27 '14 at 7:57
1
You are right - this mechanism should not be used for production, it's simply a tool to catch these things while developing/debugging/testing.
– MBaas
Jul 2 '14 at 7:36
add a comment |
Hate to be that guy, but this is a bad example. Local File Inclusion
– Darren
Jun 27 '14 at 7:57
1
You are right - this mechanism should not be used for production, it's simply a tool to catch these things while developing/debugging/testing.
– MBaas
Jul 2 '14 at 7:36
Hate to be that guy, but this is a bad example. Local File Inclusion
– Darren
Jun 27 '14 at 7:57
Hate to be that guy, but this is a bad example. Local File Inclusion
– Darren
Jun 27 '14 at 7:57
1
1
You are right - this mechanism should not be used for production, it's simply a tool to catch these things while developing/debugging/testing.
– MBaas
Jul 2 '14 at 7:36
You are right - this mechanism should not be used for production, it's simply a tool to catch these things while developing/debugging/testing.
– MBaas
Jul 2 '14 at 7:36
add a comment |
protected by Samuel Liew♦ Oct 5 '15 at 9:00
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
coding.smashingmagazine.com/2011/11/30/…
– Alex
Jul 15 '12 at 14:54
1
Also see stackoverflow.com/q/1475297/632951
– Pacerier
Oct 14 '14 at 9:37
3
@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".– Pacerier
Apr 3 '15 at 20:02
Tutorial on this: code2real.blogspot.com/2015/06/…
– Pupil
Sep 9 '15 at 7:21