This is my error setting
ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL|E_PARSE);
Now I write this test code:
helloooooo;
And It shows me:
Use of undefined constant helloooooo ...
So far so good.
Now I remove the semicolon from end of my so-called code:
helloooooo
Shows nothing. It shows a white page.
In my experience whenever I see a white page there is a syntax error so I look for a typo.
The question is why doesn't PHP help in this case?
Someone said :
Syntax checking is done before executing any code. So it can't execute
the ini_set() functions if there's a syntax error.
How about PHP interpreter applies settings first then executes the rest of code?
JavaScript interpreter can detect the same error in runtime.
Just try this:
<script>
helloooooo
</script>
Now go to Firefox => Tools=> WebDeveloper => WebConsole
ReferenceError: helloooooo is not defined
PHP's default error reporting mechanism (might) suppress error output. If you're trying to turn it on at runtime using the error_reporting function, then PHP will first have to successfully parse the file, then execute it to set that new desired error reporting level. That fails when there are syntax errors, because then PHP can't successfully parse and execute the file to change the error reporting level. The syntax error is getting suppressed because… well… it couldn't change the error reporting level yet.
Javascript doesn't have that, it outputs any and all errors it encounters.
The reason PHP likes to suppress errors is because its running on the server, and internal server debug details shouldn't be shown on public web pages. In Javascript that is moot, since it's running in the browser anyway, and the errors are reported to the console, which regular users don't see. Moreover, PHP does log all errors to a log file, so the same way you go looking for errors in Javascript, you could explicitly go looking for them in PHP's log file as well.
I have a CodeIgniter PHP app running on a Heroku Cedar instance.
We are running a PHP app and we need to log errors, but NOT print them to the screen. No matter what I do, the errors are printing to the screen, which is not safe for production.
Here is the PHP code which works on my local environment and everywhere else (besides Heroku):
error_reporting(E_ALL); #we care about all errors
ini_set('display_errors',0); #but DONT print to screen
I have seen this document which suggested I try adding a custom CodeIgniter logging class, which did not work.
I also added a phpinfo() to the app to check if somehow my settings were being overridden downstream, but it shows that display_errors is set to "Off".
So why am I STILL seeing errors printed on the screen?
It turns out that CodeIgniter 2.x has some completely asinine error handling in which they use a custom error handler to ignore the developers configurations. Apparently this is fixed in v3.
I was able to fix it by just commenting out the custom error handling, which for me was located in in CodeIgniter.php, line 72...
//set_error_handler('_exception_handler');
Or the best solution of all: don't use CodeIgniter in the first place.
I want to log some messages from my php application in the apache error logs. But I would like this to happen only in the non-production environments.
I found that php has error_log to log messages to the error log file but how do I control it to only log if my application is running in the non-prod environments.
Also, I found that there is trigger_error which takes a error type parameter. And the error_reporting setting in php.ini can then decide which error types are actually logged. So, while in dev, I have error_reporting set to E_ALL , it is more restricted in production. So, now I can use trigger_log and always log at E_USER_NOTICE. This would mean that my message is only shown in the dev log files but not in the production log files.
However, trigger_error also produces a stack trace with every log which is a bit unnecessary for me. How can I disable this stack trace.
Also, am I doing things the right way. How do people generally handle this problem.
Edit:
I am not trying to suppress error messages. I am trying to provide more debug messages in dev. Things like "Request came with following parameters", "step 1 done", etc. This is really not required in production.
If you want just custom messages sent into error log manually, log_error() is the function you are looking for.
Firstly, suppressing error handling is not a good idea - errors have a huge impact on your application performance - and suppressing error reporting does not eliminate the slowdown.
There is no 'trigger_log' in PHP.
The build in error handling in PHP does not generate a stack trace - you must have a custom error handler installed. You need to find it and amend the code if you want to change it's behaviour.
Using 'trigger_error' to record debug events is a very bad idea.
I'm having some problems getting zf2 to log errors or report them under some circumstances.
Some errors will be reported to screen and the error.log but others are not and just result in a blank screen. There doesn't appear to be any reasoning behind what does get displayed and what doesn't.
I have error reporting enabled in my php ini set to E_ALL and I have added
'display_not_found_reason' => true,
'display_exceptions' => true,
to my module config, and I have also tried setting the error reporting values directly in the index.php
At the moment im trying to use doctrine and just getting a blank screen...
https://packagist.org/packages/webino/nette-debug
Link listed above is one of the most useful debug tools I've found so far for zf2. It picks up 99.9% of the errors and the configuration allows you to log it to a specific log file in your directory. However there is that .1% that it doesn't catch and that generally does go through to the syslog so you should be able to find out more details there. Just make sure you initialize the nette debug module as the first module in the stack.
Hope this helps you, I got really sick and tired of those issues too up to the point where where I found nette.
I am having an issue when I have a php application that is returning an internal server error (500) however nothing is showing up in the error log.
Now I know there are error with what I am trying to run, I know I have missing some files and what not but something should show in the apache error log (otherwise how are I supposed to know exactly what I am missing).
I created a test script is errors it in under the same vhost configuration and those error show up fine so everything seems configured right as far as php/apache. Are there certain php errors that does show up in the error log (php is configure to display any type of notice, warning, , error, fatal error, etc...)?
This is running on ubunut 10.04 with the standard apache and php from the ubuntu repo with apt-get.
Scan your source files to find #.
From php documentation site
Currently the "#" error-control operator prefix will even disable
error reporting for critical errors that will terminate script
execution. Among other things, this means that if you use "#" to
suppress errors from a certain function and either it isn't available
or has been mistyped, the script will die right there with no
indication as to why.
Copy and paste the following into a new .htaccess file and place it on your website's root folder :
php_flag display_errors on
php_flag display_startup_errors on
Errors will be shown directly in your page.
That's the best way to debug quickly but don't use it for long time because it could be a security breach.
If you still have 500 error and no logs you can try to execute from command line:
php -f file.php
it will not work exactly like in a browser (from server) but if there is syntax error in your code, you will see error message in console.
Maybe something turns off error output. (I understand that you are trying to say that other scripts properly output their errors to the errorlog?)
You could start debugging the script by determining where it exits the script (start by adding a echo 1; exit; to the first line of the script and checking whether the browser outputs 1 and then move that line down).
In the past, I had no error logs in two cases:
The user under which Apache was running had no permissions to modify php_error_log file.
Error 500 occurred because of bad configuration of .htaccess, for example wrong rewrite module settings. In this situation errors are logged to Apache error_log file.
For Symfony projects, be sure to check files in the project'es app/logs
More details available on this post :
How to debug 500 Error in Symfony 2
Btw, other frameworks or CMS share this kind of behaviour.
Here is another reason why errors might not be visible:
I had the same issue. In my case, I had copied the source from a production environment. Hence the ENVIRONMENT variable defined in index.php was set to 'production'. This caused error_reporting to be set to 0 (no logging). Just set it to 'development' and you should start seeing error messages in apache log.
Turned out the 500 was due to a semi colon missing in database config :-)
Another case which happened to me, is I did a CURL to some of my pages, and got internal server error and nothing was in the apache logs, even when I enabled all error reporting.
My problem was that in the CURL I set
curl_setopt($CR, CURLOPT_FAILONERROR, true);
Which then didn't show me my error, though there was one, this happened because the error was on a framework level and not a PHP one, so it didn't appear in the logs.
You need to enable the PHP error log.
This is due to some random glitch in the web server when you have a php error, it throws a 500 internal error (i have the same issue).
If you look in the PHP error log, you should find your solution.
see here in the doc of how to enable it in the php.ini
Be sure your file permissions are correct. If apache doesn't have permission to read the file then it can't write to the log.
What happened for me when this was an issue, was that the site had used too much memory, so I'm guessing that it couldn't write to an error log or displayed the error. For clarity, it was a Wordpress site that did this. Upping the memory limit on the server showed the site again.
SOLVED
I struggled with this and later on, I realized that I was working on PHP 5.6, so I upgraded to PHP 7.0, then I released there were comments placed by git for conflicting codes. I found something like this in my code <<<<<<<< But solved it.