I've got a dev environment and a live environment running on the same host, using nginx with fastcgi. In php.ini, display_errors is set to off, so that the errors aren't displayed on the production site.
Now, on the dev environment, I need to be able to see those errors. So I'd do ini_set('display_errors', 'On');, however, if it's a parse error, that won't be executed and the error won't be shown.
So my question is, is there any way I can safely set display_errors to on in my php.ini file, and then maybe use the virtual host file in nginx to make sure that the errors aren't shown on the production site?
If you are using fastcgi you could configure it to run php with different php.ini files. I'm not familiar with nginx and fastcgi config, so can't provide you any hint on that. See php manual to learn how PHP could be run.
I think you might want to run it like php -d display_errors=On for dev environment
I believe you can set the error reporting level directly in your script using error_report. I don't have any of my code on hand to check for certain, but I know you can change it without touching php.ini.
Related
for my local machine i'm using the following setting in my php.ini
error_reporting = E_ALL & ~E_NOTICE & ~E_DEPRECATED
it allows omitting single quotes for fetching data from a recordset like $rs[url].
i've also used this setting on my webserver, but it simply ignores the syntax above and won't fetch any data. what could be wrong?
Are you sure you modified the right php.ini?
I ask that because sometimes, php.ini is located on various path, one for the php cli, the other for apache (and probably the case for other web server).
You should add more details about what server do you use (windows, linux), and which webserver are you using (apache, nginx, etc).
You should also be searching "php.ini" in your file system, maybe there is more than one file and you modified the wrong one, resulting in the problem you have.
Finally, and as mentionned in the comments, you shouldn't remove the deprecated errors and the notice in development environment, and have a "no error" code because an update is quite easy to make, and any deprecated function now, could result in a non working code after a quick apt-get update (for debian users).
Of course in production, you should hide all errors, but show a nice 404 or 500 page to your users and log the error for later investigation. :)
I am using Xdebug & Zend Framework 2
In my development environment I have mine set to:
error_reporting = E_ALL & ~E_USER_DEPRECATED & ~E_STRICT
I have found this to be my favoured setting when using ZF2.
If you're using PHP-FPM & NGINX The php.ini file is normally in found /etc/php5/fpm/.
Alternatively if you're using Apache with the PHP module, your php.ini file is normally in /etc/php5/
That error reporting level works for me as it I have found Zend Framework can throw some notices that are not relevant.
I can't see any PHP errors. I have tried every trick I can find to turn error reporting on, but nothing works.
display_errors is on and error_logging is on, but when I view any page with an error, I get a blank page.
/var/log/php.log does not exist.
if I set a local logfile, Nothing gets created.
The file I have been testing with is
<?php
ini_set('display_errors',1);
error_reporting(E_ALL|E_STRICT);
ini_set('error_log','script_errors.log');
ini_set('log_errors','On');
$a=
phpinfo();
?>
any other ideas?
You probably need to set it in .htaccess, httpd.conf or php.ini (depending on your server or hosting company). You most likely have a parse error, which means your script never gets to the point where it can turn on the error reporting.
Have you tried editing the actual ini file as opposed to trying to change it at runtime? You can also try using ini_get('display_errors'); to see if your change took effect. If neither of those work I would say your installation is either faulty or very restricted.
Run phpinfo() as the first thing in the script, before you try any of the ini_set options. If your host has those ini functions disabled/restricted, you'll most likely not ever get to phpinfo.
Does the userID the webserver's running under have write permissions in the directory you're running this script from? It could be failing to open your test log file and kill the script that way.
Once you get some phpinfo() output, you'll be able to see if/where PHP is logging errors. It could be going into the server's general error_log, or some other location entirely.
i solved this problem by my hosing website
cpanel-> php config ->display error on
I was a Windows user and used Wamp. Every time a PHP code failed, the browser would display something like this: error in line number xx.
I followed the installation of this tutorial and everything worked.
Now when code fail PHP just display a blank page.
Any sugestions?
(I'm using Ubuntu 10.04).
I know this is a old post, but I had the same problem and found out that after error_reporting, there is a option of display_errors, change it to On.
Old question, as Gurnarok noted, but still, here's the answer.
The standard LAMP server installation on Ubuntu does this. I simply call it "production" mode, i.e. your pages don't display errors (to your users) when your site goes live. I rather like that it does this, but I was confused at first, as well.
Instead of editing my php.ini file to go into "development" mode, I simply place this at the top of my PHP files (or, PHP file, in my case, since I usually pass everything through index.php):
ini_set('display_errors', true);
error_reporting(E_ALL ^ E_NOTICE);
So, the reason why error_reporting by itself isn't doing the trick, is most likely because display_errors isn't set to true in your php.ini file. The code above should take care of that.
I prefer to exclude the PHP "Notice" notification, such as notifications about non-existent array keys (the most common Notice, in my case), but you're perfectly welcome to simply change this to error_reporting(E_ALL);
Of course, you can set these variables in the php.ini file, I simply prefer it this way, so that when the site goes live, I simply remove those two lines from index.php and I'm in no danger of errors showing up to my users.
Find php.ini under /etc/php5/apache2/ and set the value of error_reporting to E_ALL. Like:
error_reporting = E_ALL
Or alternatively check error.log if your virtual host is providing one.
Thanks Phil your answer got me thinking and I finally managed to fix an issue thats been bugging me for weeks where my PHP install wasn't displaying errors in the HTML page at all (except sometimes a notice message but never any syntax errors etc). Even though I had all other error settings set to "on" and log_errors set to on and a filename for the log only notices were getting logged to the log file but never any syntax errors. Not very useful on a development server :)
Thought I would post my findings here in the hope that this info can help someone else with the same issue as Google wasn't very helpful with fixing the issue.
In older versions of PHP before PHP 5 I used to always have my error reporting setting in PHP ini set to "E_ALL & E_NOTICE" on my development servers. In later versions of PHP (well with my Ubuntu Oneric install anyways) using this setting seems to cause no output to be displayed at all in the HTML page regardless of the other php.ini settings (like display_errors = on, etc). Setting the values on the fly in a PHP page didnt help either as it seems the php.ini value overrides the per file setting.
I changed the error_reporting value to "E_ALL" only and now it displays syntax errors. The setting recommended in php.ini for a development server (E_ALL | E_STRICT) doesnt work for me either so thanks a lot. +1 to you :)
I am running the latest version of MAMP on Snow Leopard.
My php.ini file has been configured to display errors. display_errors = on. The phpinfo(); page displays the status of error reporting, it is on. I have restarted my web server several times.
I've searched through Google, and I cannot find any similar problem. Everyone just says to do exactly what I have done, but it is not working. The pages will just remain blank, (with no reporting), if I intentionally place errors.
Any thoughts as to what the problem may be?
For any future posters who run into this issue...
I was having the same issue and found that I was making changes to the wrong php.ini files. Run phpinfo and find the path to the active php.ini file to make sure you're editing the correct one.
On my installation of mamp there were multiple instances of the /conf directory with php.ini files. The php.ini files I needed were located in the /bin/php/php[version#]/conf directory and not the MAMP/conf directory.
Exact path to the php.ini file I needed to edit:
Applications/MAMP/bin/php/php5.4.10/conf/php.ini
Change display_errors = Off to display_errors = On
In addition to the display_errors directive, which has to be set to On, you might have to configure error_reporting.
For instance, you can use this in your php.ini file :
error_reporting = E_ALL
Another should, useful to test, might be to place this kind of portion of PHP code at the beginning of your script :
error_reporting(E_ALL);
ini_set('display_errors', 'On');
This is useful when you don't have access to php.ini and/or just want to test quickly, without having to restart the webserver.
As a sidenote, when it comes to displaying errors, the Xdebug extension is really great : when it's installed/enabled/configured, instead of just having an error message, you'll get the full stack-trace, which is much more useful ;-)
I recently experienced the same problem - in my case I had downloaded a client's Wordpress site from their live server that turned out to have been tampered with by malicious script insertion that was overriding the error reporting in order to escape detection.
A little late to help the OP(!), but perhaps of use to future searchers.
There might have a .htaccess file in a directory that overrides the display_errors setting set in php.ini. From your post I assume you didn't explicitly add this but a few frameworks do this by default so might be added that way. Look for a line like this in your .htaccess file:
php_value display_errors 0
and change the value to 1.
If you have several php sdks with several versions, first make it sure you are editing correct php.ini file. If you were right add this two lines at the beginning of the code.
error_reporting(E_ALL);
ini_set('display_errors', 'On'); // or ini_set('display_errors', 1);
Here's a twist to the same answer. I had the same issues, just copied and pasted the ini path from the php info page and still same problems...
turns out I made a syntax mistake when I edited my 'error_reporting' block in the php.ini.
I had E_NOTICE rather than ~E_NOTICE.
:(
So mistakes can happen in the php.ini if you were editing it and totally forgot you edited something.
I've narrowed my problem down somewhat.
When I run "error_log('hey');" from the command line it dumps to STDOUT. But if I run the same code from my web interface (Apache) it puts the error in the error log.
I've checked both ini files, the one Apache is using, and the one in /private/etc (I'm on a Mac running MAMP). Both error_log variables point to the exact same place.
And when I run
echo ini_get('error_log');
The value is the same on the command line as it is in the browser.
What ini setting is misconfigured here? This is quite annoying, as more than just error logging is broken. It's affecting my include paths as well :/
What are you trying to accomplish? Within apache, stderr goes into the error_log... the error_log() function documentation states that by default it logs to the server's error log. If you want to log to a different destination, use the message_type and destination parameters.
You probably need to edit the following config file:
/Applications/MAMP/conf/php5/php.ini
MAMP uses it's own Apache server, which by default runs on port 8080. You probably want to turn off the Apache server in the System Preferences -> Sharing.
Also, try running a PHP file containing:
<?php phpinfo(); ?>
This will tell you which php.ini is actually being read by Apache.
Will
A reason for error_log displaying in the console, and not in the log file might be because of a problem with permissions -- I don't really know MacOS, but as it's UNIX-based, I'm guessing that :
The log file used by Apache belongs to a specific user
When running the script from the console, you are not that user, and you don't have write-access to the log file
If it can't log to the log file, I suppose that error_log is writting to the standard output for error (stderr), which is generally the console.
This comment on the manual's page seems to indicate this might be the cause of your problems (quoting) :
it seems that PHP logs to stderr if it
can't write to the log file. Command
line PHP falls back to stderr because
the log file is (usually) only
writable by the webserver.
Also, make sure the log_errors and display_errors are properly configured in the php.ini file used in CLI :
log_errors boolean
Tells whether script error messages
should be logged to the server's error
log or error_log. This option is thus
server-specific.
And :
display_errors string
This determines whether errors should
be printed to the screen as part of
the output or if they should be hidden
from the user.
Value "stderr" sends the errors to
stderr instead of stdout.
The relevant ini setting here is display_errors.
From the command line a value of On will dump the errors to STDOUT; stderr will divert them to STDERR and Off will suppress them. For Apache only On and Off make any sense.
The odds are that the ini file for Apache has display_errors = Off whilst the one in /private/etc has display_errors = On.
The error_log directive tells PHP where to log errors to, but it also requires log_errors to be set to On, otherwise it has no effect. (Again, chances are the ini file in /private/etc has log_errors = Off.)