Member Avatar for 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

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, how can I get PHP 5.3.2 to support the .php3 extension?

  • 2 Contributors
  • 5 Replies
  • 187 Views
  • 2 Days Discussion Span
  • Latest Post Latest Post by knkk

Dani AI

Generated

A short expert addendum tied to the thread: the behavior you saw is exactly the classic “php.ini change looks ignored” scenario — an in‑script call to change error reporting will win over the php.ini default, and Apache/.htaccess or a custom error handler can also affect what actually gets shown. Run a small diagnostic page (for example, a phpinfo() dump or reading the current ini value at runtime) to confirm which php.ini file is loaded and what the runtime error level is. (php.net)

Avoid hard-coded integer masks for error reporting. The error-level symbols are bit flags, and PHP has added and re-arranged some of those flags across releases; an integer that meant one thing in an older release can map to a different set of flags in a newer release. Use the named constants at runtime (the manual explicitly recommends them) and treat numeric literals as brittle. The PHP core also documents the numeric values used for each level so you can decode masks if needed. (php.net)

Practical checklist (use these to triage the problem you saw in this thread): search the codebase for any runtime calls that set error reporting or display settings; check for php directives in per-directory configs or virtual hosts; inspect any custom error handler that may short-circuit the usual reporting flow; confirm the SAPI (module vs CGI) and restart the web server after config changes. For older deployments that need non-standard extensions (legacy .php3 files), map that extension to the PHP handler in the webserver’s PHP configuration and restart. (php.net)

This ties back to what reported and to ’s suggestion: in-script settings and server-level mappings are the usual culprits. Best practice is to keep display of errors disabled in production, set a clear logging policy, and use the named constants so future PHP upgrades don’t change what you expect. (php.net)

Recommended Answers

All 5 Replies

Member Avatar for sourcez

You've definately got the right php.ini? Some hosts have them lying all over the place for different domains, depends on the setup.

php3 settings are in php.ini too, aren't they?

Do you have any settings coded into .htaccess? Maybe that's messing with the setup?

Member Avatar for knkk

Thanks, sourcez. Yes, it is the right php.ini - the errors stop coming when I do display_errors = Off. And no, nothing in .htaccess, since the code was working fine until I upgraded PHP :(

Member Avatar for sourcez

I'm guessing with you here, how about trying it with htaccess then? Just to see whether that works (I know it wouldn't be ideal but is a start)

php_flag display_errors off
Member Avatar for sourcez

Oh and have you tried:

error_reporting = E_ALL & ~E_NOTICE & ~E_WARNING
Member Avatar for 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, sourcez, for your suggestions!

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.