I'm developing a JSON integrated web application, which is really irritating to debug on client-side when I'm getting some (some intended) PHP error's on the serverside of the (through ajax) page request. For debugging purposes I would like to disable all my debugging of PHP and DB related errors for only this specific page / view / controller.
I've already tried placing the following in the top of my controller, which should be working according to some articles I found on the interwebs:
function index() {
ini_set('display_errors', 0);
$this->config->set_item('log_threshold', 0);
Though, this still gives me the darn errors.
I know it sounds silly that I would require the errors to be disabled, but... just trust me on this one.
Have you changed ENVIRONMENT constant to 'production' in index.php?
It will turn off all errors
In production environments, it is typically desirable to disable PHP's
error reporting by setting the internal error_reporting flag to a
value of 0. This disables native PHP errors from being rendered as
output, which may potentially contain sensitive information.
Setting CodeIgniter's ENVIRONMENT constant in index.php to a value of
'production' will turn off these errors. In development mode, it is
recommended that a value of 'development' is used. More information
about differentiating between environments can be found on the
Handling Environments page.
If it won't help - try to update CodeIgniter.
By the way, this
$this->config->set_item('log_threshold', 0);
is just file logging.
If you need to turn off only on one page try this one
ini_set('display_errors', 'Off');
error_reporting(0);
define('MP_DB_DEBUG', false);
Related
I am using the WordPress REST API and in my main plugin file I set:
ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);
I'm getting some weird behavior. For instance in a function/endpoint I have something like:
function test($request){
$request['id'] <- this works fine here
but if I add another function like this I get a silent error
$validID = check_id($request['id']);
}
So when I do this my return from the endpoint is blank and I get this error:
has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
Now if I set error_reporting to:
error_reporting(E_ERROR | E_WARNING | E_PARSE);
My endpoint works just fine. Not sure what is happening here. I don't get any php error logs and this makes it extremely difficult to troubleshoot. So should I just NOT use E_ALL?
I also tested the endpoint by leaving out a semi colon. I get the same result except now I get an empty response for both error_reporting(E_ALL) and error_reporting(E_ERROR | E_WARNING | E_PARSE). I'd love to get some kind of log/return to tell me whats wrong.
Unfortunately a lot of WordPress code out there is written without WP_DEBUG enabled, which means without E_ALL level. As result it tends to be full of notices and deprecation issues developers don't see and don't bother to correct.
So raising error reporting can often trigger issues entirely unrelated to your own code.
Since your immediate problem is lack of obvious error message/log, you should experiment with WP_DEBUG_DISPLAY and WP_DEBUG_LOG configuration to see if that helps.
Generally it's preferable to use constants to control WP's error handling centrally. When extensions start to mess with this it's... well, a mess. :)
Another thing you could try is a dedicated error handler. I made and use a wps plugin that wraps whoops handler for WP context. For API errors it tries to override the output and return a meaningful trace for what happened.
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.
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've seen a few methods for hiding php errors using php.ini or by adding php_flag display_errors off to .htaccess, but I'm wondering if there's a way to make it so only I can see php errors (useful for debugging obviously), but anyone else will be redirected to some boilerplate error page. I have a few scripts on my site that use my forum to authenticate me as an admin and kick everyone else out, so maybe it's possible using the same method?
If this isn't possible, I guess I'll go with the .htaccess method since I don't have access to php.ini. Is adding php_flag display_errors off to .htaccess a good way to go for this?
Thanks!
While displaying errors on screen is great for development (as you see them right away), they should not be enabled for production servers because you may accidentally expose sensitive information (e.g., database passwords) to unauthorized users.
The useful INI options are:
ini_set('error_reporting', E_ALL & ~E_NOTICE);
ini_set('error_log', '/path/to/my/php.log');
ini_set('log_errors', 'On'); // log to file (yes)
ini_set('display_errors', 'Off'); // log to screen (no)
With that, all errors will be logged to the specified file. No errors will be seen on the screen.
Make sure the web server user is able to write to that file. You may have to create it and chmod / chown it accordingly before running your script.
On private development servers, you could disable the log file and display directly to screen. When developing, I would also get in the habit of displaying E_NOTICE errors as well. (Just use E_ALL as the value.) And if your scripts are well written, you can then continue to log them while in production too. An E_NOTICE is good for catching typos in variable names or array indices.
Note that all of those options can also be set in the php.ini or .htaccess files. But if you use .htaccess you cannot use the E_* constants; instead, you must hardcode the integer representation. (i.e., In a .htaccess file, you use whatever the results of <?php echo E_ALL ?> show as the value, or whatever you wish to log.)
In fact, I would recommend setting them in the php.ini if at all possible. Otherwise, if there's a script parsing error (or the ini_set gets skipped for some reason), you may not get the errors logging properly, etc.
On a Linux box you can always do a tail -f /path/to/my/php.log from a shell to monitor the log in realtime.
Although I agree with konforce, this is possible by setting the error reporting at runtime with the error_reporting() function. If you insist on doing that, put it in the same block of code that you mentioned for determining you are the admin, so that you don't have the decision made in different places.
Since your code already knows you are an admin you can use a logic like this:
if($_SESSION['isadmin']==1){
ini_set('display_errors', 1);
ini_set('log_errors', 1);
}
The admins will see errors but the other users will not see the errors.
You can check against the users IP, and if it matches yours, you can show errors.
Something like this:
if($_SERVER['REMOTE_ADDR'] == 'your.ip.address'){
error_reporting(E_ALL);
} else {
error_reporting(0);
}
If you don't know you external IP, just google "what is my ip" or similar.
Base case scenario is obviously having a dev-server.
if you have a users system, set the codes so it recognize you when you log in, and show errors. So, it will only show errors when it's you who is logged in.
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.