Unable to turn off notice errors in php 5.3.2

PHP error-handling

[knkk]

Hi everyone,

I recently migrated to PHP 5.3.2, and realized that I am unable to turn off notice errors in my site now. I went to php.ini, and in these lines:

; Common Values:
;  E_ALL & ~E_NOTICE (Show all errors, except for notices and coding standards warnings.)
;  E_ALL & ~E_NOTICE | E_STRICT (Show all errors, except for notices)
;  E_COMPILE_ERROR|E_RECOVERABLE_ERROR|E_ERROR|E_CORE_ERROR (Show only errors)
;  E_ALL | E_STRICT (Show all errors, warnings and notices including coding standards.)
; Default Value: E_ALL & ~E_NOTICE
; Development Value: E_ALL | E_STRICT
; Production Value: E_ALL & ~E_DEPRECATED
; http://php.net/error-reporting
error_reporting = E_ALL & ~E_NOTICE

...I've tried setting everything (and I restart apache each time), but I am unable to get rid of notices.

The only way I'm able to get rid of notice errors is by setting :

display_errors = Off

That is, of course, not something I can do since I need to see errors to fix them, and I would like to see errors on the webpage that I am coding rather than log them somewhere.

Can someone help? Is this a bug in PHP 5.3.2 or something I am doing wrong?

Thank you very much for your time!

P. S. Also, would anyone know how I can get PHP 5.3.2 to support the .php3 extension?

[jatar_k]

have you tried the error_reporting function? might make a difference though it isn't really a long term solution unless you have something included on every page

[php.net...]

have you checked for multiple php.ini files? most often the case

>> how I can get PHP 5.3.2 to support the .php3 extension?

not a php thing, you need to set that up in your apache conf, you can probably search through it and look for the .php extension as it may already be in there and add .php3 to the list. Or search up 'parsing html as php' and do the same type of thing except with .php3 instead of .html

[knkk]

Okay, I figured what was going wrong. I set error_reporting in my code, which was overwriting the php.ini error_reporting.

Now the reason that that same stuff was working until I upgraded to PHP 5.3.2 was this - in my code, I set the error_reporting command:

error_reporting(6143);

I should've set it as:

error_reporting(E_ALL ^ E_NOTICE);

I'm guessing the meaning of 6143 is different in PHP 5.3.2 compared to in 4.1 (or whatever my earlier version was).

As for the php3 extension, it was to be set in the /etc/httpd/conf.d/php.conf file:

AddHandler php5-script .php .php3
AddType text/html .php

Thank you, jatar_k, for your suggestions!

[Matthew1980]

Hi all,

Surely having the error_reporting() on is a good thing? At least from there you can refine your code and make it perform better? Obviously though if this is from a release perspective I can see the point, but from a developers point of view it would be a good thing...

Personally I have not seen error reporting being set from "raw data", I'll assume as that's a binary instruction, an please correct me if I am wrong, but doesn't E_ALL cover everything, including E_NOTICE?

Cheers,
MRb

[mack]

E_NOTICE can be quite frustrating. Even an unused variable can trigger an error message.

Mack.

[TheMadScientist]

please correct me if I am wrong, but doesn't E_ALL cover everything, including E_NOTICE?

Nope...

// Report all errors except E_NOTICE
// This is the default value set in php.ini
error_reporting(E_ALL ^ E_NOTICE);

PHP Error Reporting [php.net]

[Matthew1980]

Hi there TheMadScientist,

I must have misread it originally a while back ;-) I have mine set to error_reporting(E_ALL | E_STRICT) so the ^ (carat I think as its called) means except? That's something I hadn't known. For me I would prefer to know everything that could be interpreted as an error, that's why I set it to strict, as I think this makes for better coding :)

Cheers,
MRb

[TheMadScientist]

Oh, yeah, good thinking...

Sorry, I thought it did too, then I went and checked and mis-read it.
Good Catch!

Yes, I've called it a carat for years, but it's also a circumflex... [en.wikipedia.org...] (unless of course I'm mis-reading again... LOL) Sorry. Late night last night so I'm NOT writing any regular expressions today, thankfully! LOL. Maybe super technically a ^ is a carat by itself, and a circumflex when it's over another character or something? IDK.

[coopster]

I'm guessing the meaning of 6143 is different in PHP 5.3.2 compared to in 4.1 (or whatever my earlier version was).

Yes, the bitmask can and does often change between release levels as the type of errors and error reporting changes. Since E_ALL includes everything except level E_STRICT, it has to change in order to accommodate new error types:

[php.net...]

Add up each number in the left hand column on that page except for E_STRICT and you will find that is the number for E_ALL, currently 30719 for PHP 5.3. You need to take the far right column into account for your release version.

Best practice is to set it at the configuration level, in php.ini if you can because then you may use the constant rather than the bitmask integer. It just makes it easier for you, no more worrying about adding up numbers for your servers release level. Then there is only one place of concern and less confusion as you have now experienced.

For what it's worth, I leave my development servers at

error_reporting = E_ALL | E_STRICT 
display_errors = On 
display_startup_errors = On 
log_errors = On

and production servers are

error_reporting = E_ALL 
display_errors = Off 
display_startup_errors = Off 
log_errors = On

Even after I promote code to a production server I still want to know if there was an error. I just log it instead of displaying it.