Confusion regarding the elvis operator in PHP [duplicate] - php

I have a development version of PHP on Apache. I moved it to production and got this weird notices in my website. I don't have it on development version. How to enable these notices on my development version of website to fix them?

If you have access to your php.ini, then Björn answer is the way to go.
However, if you don't, or if you want to change a particular script / project error level, do this at the beginning of your code:
ini_set('display_errors', 1);
// Enable error reporting for NOTICES
error_reporting(E_NOTICE);
You can see which levels are available for error_reporting here: http://us2.php.net/manual/en/function.error-reporting.php.
It's always a good practice not to show any errors on production environments, but logging any weird behaviors and sending by mail to the administrator. NOTICES should only be enabled on development environments.

Change your php.ini file, the line that says error_reporting, to E_ALL.
I.e:
error_reporting = E_ALL

Seb is right, though you really should use constant for error_reporting().
error_reporting(E_NOTICE);
You can use bitwise operations to pick exactly the messages you want to display. For example:
// notices and warnings
error_reporting(E_NOTICE | E_WARNING);
// everything except errors
error_reporting(E_ALL ^ E_ERROR);

Related

MongoDB Codeigniter

I managed to run MongoDB on Codeigniter using Alex Bilbie` library. The operations go well (connection, queries etc. ) but sometimes I get these PHP notices:
Message: Mongo::__construct() [mongo.--construct]: localhost:27017: pool get (0x4bfab20)
Filename: libraries/Mongo_db.php
Line Number: 1274
A PHP Error was encountered
Severity: Notice
Message: Mongo::__construct() [mongo.--construct]: localhost:27017: found in pool (0x4bfab20)
Filename: libraries/Mongo_db.php
Is there a way to get rid of these? or maybe hide them..as they don't seem to mess up my pages in another way than splashing into the user's screen.
EDIT
On a few pages though, I use the JQgrid and when the errors show up they mess up my HTTP response and render some messy data.
The specific notice messages here have been removed in the MongoDB PHP driver 1.2.11 or later (see PHP-431). Upgrading your MongoDB driver to the latest should remove the excessive notice logging.
General notes on proper settings for Code Igniter logging in production still apply...
The E_NOTICE level of error reporting is intended to warn you about possible bugs or typos. It is typically only used as a development setting rather than for production messages.
The default error_reporting setting in PHP4 and PHP5 is actually set to ignore these:
E_ALL & ~E_NOTICE
The Code Igniter index.php has an application environment setting which normally shows all errors for development and suppresses error reporting for testing and production. You should set this appropriately:
define('ENVIRONMENT', 'production');
If you actually want to capture these messages for a production environment you should update the production settings in your index.php so that instead of error_reporting(0) you have:
error_reporting() set to appropriate level of detail
display_errors off
log_errors on
error_log path set
For example, in index.php you could have:
case 'production':
error_reporting(E_ALL);
ini_set('display_errors','Off');
ini_set('log_errors','On');
ini_set('error_log','/var/log/php5.log');
break;
That way the messages/notices will still be saved to the error_log if you want to review them, but they will not be shown to the end user.
Off the top of my head, there are a few things you could do. This is not an answer regarding a fix to the MongoDB error you are receveing, but rather regarding some methods in which you could hide the errors.
a) Use the '#' operator to ignore any error outputs from the method being called in which outputs the errors you are receiving. This would result in you renaming the method call to the following #method_outputting_mongodb_error($foo,$bar);.
b) Turn off error reporting in CodeIgniter. This is not the best method as all other errors will not be outputted.
There is a good link here re: how you can turn off error reporting: http://phpdog.blogspot.fr/2012/02/codeigniter-error-reporting-handling.html
As #Stennie mentions this has been fixed in later versions of the driver: https://jira.mongodb.org/browse/PHP-431
Try and upgrade.
Also this only existed on the Windows driver and only start happening after v1.2.1. I know that because the guy who made that JIRA also tried 1.2.1 on my advice and he didn't get those E_NOTICEs. I remember having the conversation that actually triggered that JIRA now :).
Unlike others I don't think you should "hide" these errors with E_ALL & ~E_NOTICE. No one is quite decided on hiding E_NOTICE however the general concensus is that it is not the best thing. Of course you would not want your logs to be filled with all this debug info about the MongoDB extension, instead the MongoDB extension should be silent (as you think it should).
Another reason I would not hide E_NOTICE is because of the php.ini of later versions of PHP:
; error_reporting
; Default Value: E_ALL & ~E_NOTICE
; Development Value: E_ALL | E_STRICT
; Production Value: E_ALL & ~E_DEPRECATED
By default PHP will actually install for Production Value (as it does for me) as such the default for PHP error reporting is:
E_ALL & ~E_DEPRECATED
This is the value I have for error_reporting on both my AWS and my local Ubuntu server 12.04 and I have not changed the values since installing as such the default value I gain from installing PHP from both repo and source is:
error_reporting = E_ALL & ~E_DEPRECATED
So the recommended default setup for production for later PHP versions (and probably future ones) actually shows E_NOTICE, which is useful but not if the logs are being filled with stuff from the Mongo extension.
Edit: Downvoter care to explain? I have basically given the same answer as #Stennie, why the downvote?
I have edited my answer to actually take the conversation in the comments on this answer and #Stennie's answer into consideration so the answer makes more sense now.

Is there a way that I enforce that PHP reports error if I use an uninitialized/undefined variable?

I made a huge mistake by mixing result with results and it took me around 4 hours to finally find the bug.
So here is the question, in PHP, is it possible that I can enforce PHP to report errors if I use an undefined/uninitialized variable.
thank you
Set error reporting to E_ALL and ensure that display_errors in php.ini is on.
php.ini
display_errors = On
PHP code
// If you cannot access the php.ini file
// you can do this within your PHP code instead
#ini_set('display_errors' '1');
error_reporting(E_ALL);
The default setting you have right now probably excludes notices, the kind of errors PHP raises on uninitialized variables, which could be something like this:
error_reporting(E_ALL & ~E_NOTICE);
In a development environment I prefer using error_reporting(-1). Which reports all PHP errors.
yes, use error_reporting() and set it to E_ALL, like this:
error_reporting(E_ALL);
Set error reporting to report all errors. Either in php.ini or at runtime using error_reporting(E_ALL)
it already does report an error. something like this:
"Notice: Undefined variable: a in C:\wamp\www\testcenter\index.PHP on line 40"
maybe you didn't go specific enough. but you should try error_reporting(-1); as as if enforces the php to show some recomendations. a piece from the php manual about E_STRICT errors:
Enable to have PHP suggest changes to your code which will ensure the best interoperability and forward compatibility of your code.
just remember that error_reporting(-1); shows more errors than error_reporting(E_ALL); because E_STRICT errors are not included in the E_ALL constraint.

Suppressing errors beyond setting ERROR_REPORTING ( display_errors perhaps? )

Let's say I'm basically inheriting a live site that has a lot of errors in production, I'm basically doing a recode of this entire site which might take a month or so.
There are some cases in which this site was reliant upon external xml file feeds which are no longer there, but the code wasn't properly setup to supply a nice clean error message ( there are various similar circumstances ) - the client is requesting that at least these error messages go away even if for example the content from the xml file isn't published so we wouldn't be seeing php errors and a blank region on the page ( so the rest of the page can look "fine" ).
At one point I have heard of someone using set_error_handler to nullify some cases where it isn't extreme and I had the idea of setting it up to store error messages in a file/log or email them ( and try to not have duplicate error messages ) basically so end users don't have to see those ugly things.
I'm looking for tips from anyone who's actually done this, so thanks in advance.
On your production server, you should have the following ini settings:
ini_set('error_reporting', E_ALL | E_STRICT);
ini_set('log_errors', true);
ini_set('error_log', '/tmp/php_errors.log'); // or whatever file is appropriate
ini_set('display_errors', false);
By turning off display_errors, your users will never see another error message, but you will be able to see error messages by looking in the log file.
When the re-code is finished, there should be no more errors going into the log file (because you've fixed them all).
Edit: Some developers set error_reporting to E_ALL ^ E_NOTICE as a way of hiding errors. This is bad practice because it hides messages about possible programming errors. You should only use E_ALL ^ E_NOTICE when there are so many Notices coming from legacy code that you are unable to fix them all.
When in development, it is good to use
error_reporting(E_ALL);
ini_set('display_errors', 'On');
So you can see errors immediatly : it helps correcting them.
When on the production server, you don't want error displayed, so :
ini_set('display_errors', 'Off');
error_reporting can remain activated : if display_errors is Off, errors won't be displayed anyway -- but you can still have them logged to a file.
BTW, those can be set in the php.ini file, of course :
error_reporting
display_errors
On the production machine, you might want to use log_errors and error_log, so errors are logged to a file (which means you will be able to know what errors occured -- can be useful, sometimes) ; of course, don't forget to check that file from time to time ;-).
As a sidenote, if you just have a couple functions/methods you don't want to display errors, you could envisage using the # operator to just mask the errors those might trigger...
... But I strongly advise against it (except in very specific cases) : it make debugging lots harder : errors triggered there are never displayed, not even on your development machine !
In my opinion, it is way better to just disable display_errors on the production machine ; it also means no error will be displayed at all, which is better for users!

PHP 5 disable strict standards error

I need to setup my PHP script at the top to disable error reporting for strict standards.
Can anybody help ?
Do you want to disable error reporting, or just prevent the user from seeing it? It’s usually a good idea to log errors, even on a production site.
# in your PHP code:
ini_set('display_errors', '0'); # don't show any errors...
error_reporting(E_ALL | E_STRICT); # ...but do log them
They will be logged to your standard system log, or use the error_log directive to specify exactly where you want errors to go.
For no errors.
error_reporting(0);
or for just not strict
error_reporting(E_ALL ^ E_STRICT);
and if you ever want to display all errors again, use
error_reporting(-1);
All above solutions are correct. But, when we are talking about a normal PHP application, they have to included in every page, that it requires. A way to solve this, is through .htaccess at root folder.
Just to hide the errors. [Put one of the followling lines in the file]
php_flag display_errors off
Or
php_value display_errors 0
Next, to set the error reporting
php_value error_reporting 30719
If you are wondering how the value 30719 came, E_ALL (32767), E_STRICT (2048) are actually constant that hold numeric value and (32767 - 2048 = 30719)
The default value of error_reporting flag is E_ALL & ~E_NOTICE if not set in php.ini.
But in some installation (particularly installations targeting development environments) has E_ALL | E_STRICT set as value of this flag (this is the recommended value during development). In some cases, specially when you'll want to run some open source projects, that was developed prior to PHP 5.3 era and not yet updated with best practices defined by PHP 5.3, in your development environment, you'll probably run into getting some messages like you are getting. The best way to cope up on this situation, is to set only E_ALL as the value of error_reporting flag, either in php.ini or in code (probably in a front-controller like index.php in web-root as follows:
if(defined('E_STRICT')){
error_reporting(E_ALL);
}
In php.ini set :
error_reporting = E_ALL & ~E_NOTICE & ~E_STRICT
WordPress
If you work in the wordpress environment, Wordpress sets the error level in file wp-includes/load.php in function wp_debug_mode(). So you have to change the level AFTER this function has been called ( in a file not checked into git so that's development only ), or either modify directly the error_reporting() call
I didn't see an answer that's clean and suitable for production-ready software, so here it goes:
/*
* Get current error_reporting value,
* so that we don't lose preferences set in php.ini and .htaccess
* and accidently reenable message types disabled in those.
*
* If you want to disable e.g. E_STRICT on a global level,
* use php.ini (or .htaccess for folder-level)
*/
$old_error_reporting = error_reporting();
/*
* Disable E_STRICT on top of current error_reporting.
*
* Note: do NOT use ^ for disabling error message types,
* as ^ will re-ENABLE the message type if it happens to be disabled already!
*/
error_reporting($old_error_reporting & ~E_STRICT);
// code that should not emit E_STRICT messages goes here
/*
* Optional, depending on if/what code comes after.
* Restore old settings.
*/
error_reporting($old_error_reporting);

How to enable notices on my development server

I have a development version of PHP on Apache. I moved it to production and got this weird notices in my website. I don't have it on development version. How to enable these notices on my development version of website to fix them?
If you have access to your php.ini, then Björn answer is the way to go.
However, if you don't, or if you want to change a particular script / project error level, do this at the beginning of your code:
ini_set('display_errors', 1);
// Enable error reporting for NOTICES
error_reporting(E_NOTICE);
You can see which levels are available for error_reporting here: http://us2.php.net/manual/en/function.error-reporting.php.
It's always a good practice not to show any errors on production environments, but logging any weird behaviors and sending by mail to the administrator. NOTICES should only be enabled on development environments.
Change your php.ini file, the line that says error_reporting, to E_ALL.
I.e:
error_reporting = E_ALL
Seb is right, though you really should use constant for error_reporting().
error_reporting(E_NOTICE);
You can use bitwise operations to pick exactly the messages you want to display. For example:
// notices and warnings
error_reporting(E_NOTICE | E_WARNING);
// everything except errors
error_reporting(E_ALL ^ E_ERROR);

Categories