I'd like to see any PHP errors that are occuring, ie the "Expected ; on line 5 of myfile.php" sort of thing. Unfortunately, I cannot seem to figure out how to see this information.
I've set E_ALL, display_errors ON, friendly error messages are turned off, IIS is set to pass-through on errors, what am I missing?
Syntax errors used to show up as stated above on any page; they no longer do. We moved the server to a localhost for development, and I guess didn't mimic exactly the server config. Now I'm stumped.
Tried on IE and Chrome, neither of which show the errors.
Errors are logged in PHP's log file, but I'd still like them to be displayed on the page; at least for now.
UPDATE:
Just tried adding ini_set('display_errors', 'on'); directly into the requested page, and it now works.. but why? Why does it need to be set locally? My PHP.ini file has this declared already.
To answer the first part of the question; to see the errors when using ajax: You can use the developer tools of your browser to see the exact response from the server.
In FireBug for Firefox for example, you go to the Net tab and there you see all ajax request popping up as they happen. Opening one of these requests will give you an overview with more tabs like Response and HTML.
Try using:
error_reporting (-1);
E_ALL isn't really "all" for php < 5.4.
Also, make sure 'display_errors' is set.
ini_set( 'display_errors', 1 );
Well, looks like this is half my own stupidity, half the cloudiness of automatic installations.
Turns out there were TWO php.ini files, and that IIS used the one located within the iis express directory on the main drive, instead of the regular PHP directory.
So to anybody else having this problem, I'm providing the full list of crap you have to wade through to get the errors as you would like:
1) Turn off the IIS default error pages
2) Disable 'friendly error messages'
3) Ensure you are using the CORRECT php.ini file, and change the parameters as needed. Specifically error_reporting and display_errors.
All of this is necessary before seeing all of the error messages you need right in the browser.
Related
When I try to install Jetpack on my Wordpress website I get the following error:
Error Details: The Jetpack server could not communicate with your
site’s XML-RPC URL. Please check to make sure example.com/xmlrpc.php
is working properly. It should show ‘XML‑RPC server accepts POST
requests only.’ on a line by itself when viewed in a browser and
should not have any blank lines or extra output anywhere.
When I goto the URL I see this:
XML‑RPC server accepts POST requests only.
Which is expected. It feels like I have tried everything I have googled and everything here:
https://jetpack.com/support/getting-started-with-jetpack/what-do-these-error-messages-mean/blank-lines-xmlrpc/
I have tried uninstalling all plugins and still does not work :(
What am I doing wrong?
Please help!
Looking at the link, they specifically mention whitespace or output that could be causing issues, and ask you to check there isn't any before the opening PHP tags etc.
The reason they talk about this is because if there has been any output at all, then PHP will no longer be able to send any HTTP headers!
If your files look ok, then I guess (guarantee even?) that your display_errors is turned on. Depending on the level of error_reporting in your ini file, any little notice or warning will create output, and therefore stop any further HTTP headers from being set.
For the best error logging experience (and hopefully to also fix your error), set error_reporting to -1, turn display_errors off, and set a custom error_log. Then in the terminal, type tail -f /path/to/error_log. Your notices, warnings and errors will now scroll past in real time, without distorting your web page's display.
I have an Apache2 web server with PHP 5.5 installed.
My default PHP settings is display_error = 0 (I don't need globally displayed errors) but I need it on in specific PHP files.
I tried with:
error_reporting(E_ALL);
ini_set("display_errors", 1);
and it's not working.
Can someone tell me how can I make it show errors in specific PHP files?
i am try to force some error writing some no syntax logic and not showing error...
To show parse errors in PHP you have to put this on your php.ini
display_errors = on
My advice is to avoid displaying errors on production servers but log them all. So you can later inspect and fix bugs from yoursite-error.log file.
You should be concerned if your applications has warnings, errors etc. IMHO it is a bad idea to focus your attention only on few files instead of them all.
Although display_errors may be set at runtime (with ini_set()), it won't have any effect if the script has fatal errors. This is because the desired runtime action does not get executed.
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.
This is a very strange issue. In my code I have a redirect that works perfectly on my local server.
header("location:/sign-up-success");
When I push to production, it just doesn't redirect. Is there a setting that I am missing?
I have even tried:
header("Location: https://www.myurl.com/sign-up-success");
It appears to just skip over the redirect. Any ideas?
possible reason: you have sent some output to the browser before the call of header()
solution : write ob_start() at the top of the page
Best practice : alwyas write exit() after header()..
Reference
Take a look at value of error_reporting on production server. If it is set to too low level, there will be nothing in the log, as errors of lower level than error_reporting are just silently ignored. Same applies to using # - it sets error_reporting to 0, so if anything bad happens (e.g., if function is not even defined), you won't see anything in the log.
From what you wrote about enabling output buffering, it seems that you have some output before header() (this is why enabling output buffering helps) and that your error_reporting is set to 0 (this is why warning about "Cannot modify header information" was not being reported/logged).
On a side note... To get the most of error reporting:
set error_reporting to E_ALL | E_STRICT (in both dev and production environments)
enable error logging (critical for production environment, though it won't hurt to have it enabled in dev environment as well)
set display_error to true in dev environment, false in production environment (critical!!! user does not have to see any PHP warnings/notices/errors)
additionally, you might want to set_error_handler() to output or log more information than default error handler does (e.g., you might want to store debug_backtrace(), when error occurs)
It appears to just skip over the redirect.
You need to have a look at exactly what the script is returning in headers / content. There are lots of tools available for this - HTTP fiddler, iehttpheaders for MSIE, for Firefox there's tamperdata, liveheaders, web developer toolbar and many more. Or sniff the network traffic (though decoding ssl can be a PITA)
Thank you for all the responses. It appears the answer to this question was given by #netcoder in the comments. The answer is found below:
In the php.ini file on my local machine I had "output_buffering = 4096" and on the production server it was set at "output_buffering = off". Turning it on fixed the header issue and some other problems as well.
For those with other headers problems, please review the other responses as they will be helpful if you have error reporting turned off. (I had run into that before, that's why I knew that wasn't the problem but that can certainly be a headache for people working with redirects and not knowing what the problem is).
Thank you all.
I would like to log PHP errors on a CakePHP site that has debug = 0. However, even if I turn on the error log, like this:
error_reporting = E_ALL & ~E_NOTICE & ~E_DEPRECATED
log_errors = On
it doesn't log errors.
The problem is that even for a parse error that should cause the CakePHP environment to not load completely (I think), it still blocks the error from being logged. If I set debug to 3, it logs to the file without issue.
I am using CakePHP 1.2. I know this is apparently made easier in 1.3, but I'm not ready to upgrade.
Another way to keep track of and log errors would be to use the Referee plugin as it provides a way to arbitrarily log and catch all (including fatal) errors that occur during exection.
define('LOG_ERROR', 2); in core.php
PHP should log errors to its own logfile, regardless of what CakePhp is doing.
Look in /etc/php.ini file (or wherever yours lives) and search for error_log. This will show you where the PHP log resides on your system.
There is a bug in CakePHP 1.2-1.3 where PHP errors/warnings are suppressed in view code when debugging is disabled.
In the file cake/libs/view/view.php on line #664 it reads
#include ($___viewFn);
But the # directive suppresses errors for the entire view handler. Instead it should be:
include ($___viewFn);
Which allows PHP errors/warnings to be generated in view code and subsequently get logged. Once I changed this and had the right logging settings in core.php I was finally able to get complete logs in production.
Sometime the reason could be very different. For example the framework you are using may have its own internal caching module which keeps the value in buffer while you keep on trying. Check whether duplicate copies are getting generated or not. Typically those files would be named as filename.ext.r123 and so on.