syntax error detection

[ginerjm]

It seems like lately my scripts don't show up the simple little syntax errors like they used to do. Probably because my host upgraded the php version (now at 5.6.35).

 

This line (with errors set at E_ALL & E_NOTICE btw):

$start_time = str_replace($sch_items, $repl_items, $row['start_time'];

does not show up as an error any longer. This kind of thing has been going on for several months and I just discovered this specific issue as a culprit. Many times I write some new code and naturally make a few typos and then have to SEARCH LONG AND HARD to find the little errors that I have made.

 

For those still reading, the problem above is the missing ) at the end of the statement. Why don't I get an error message?

Edited April 27, 2018 by ginerjm

[taquitosensei]

If you're on a shared host there may be a php.ini in your webroot that you can edit to turn on errors. When they upgraded it may have replaced the existing php.ini.

[Barand]

Use phpinfo() and check "Loaded Configuration File" setting to make sure you are actually using the ini file that you think you are. The error settings will be found in the "Core" section of the output.

[requinix]

If the setting is literally "E_ALL & E_NOTICE" then that only enables notices. It should be "E_ALL | E_NOTICE"... except E_ALL includes E_NOTICE so really just "E_ALL" is fine.

[ginerjm]

My typography mis-directed you - the settings include both options and probably don't need to.

 

As for php.ini - I add an error settings module that includes my desired settings into every script I write. There is also an switch check in that module to allow my scripts to turn on full error checking or not which I use when necessary. In the cases that concern this question that switch is turned on for development and the values is 32767 (I checked)

[kicken]

Setting the error reporting values in your script is less than ideal. If, for example, your script had a parse error then PHP would bail before ever setting your error settings as the script is never executed. If your application works like many frameworks these days and has a small front-end script that sets the error configuration then include's other files you're probably fine though as the setting would be applied prior to the include being executed.

 

For your live server, setup your php.ini file with an error_log value pointing to a file somewhere you can check for errors and display_errors=off.

 

For your development server you can set display_errors=on and error_reporting=E_ALL to hopefully get the errors in the browser directly. If you're using a fast-cgi setup for PHP you might need to configure it to pass through the errors as well.

[ginerjm]

For development I have always used my little err setting module and for all except fatal errors that crash the script I usually got a message that got me thru all my typos and such. Nowadays I am not. So did some recent version change alter this behavior?

 

Like right now - I made a few changes to a script and introduced an error and my script won't run and I'm not getting the usual messages that I always got before.

 

I understand what Kicken says about doing my error control this way but it has worked for years and I've been happy.

[mac_gyver]

if you were seeing fatal parse errors before, it was because of the configuration settings, not anything you were doing in the code (unless the errors were in a required/included file and the settings were either in the main file or a file included/required before the one where the error is at.) if you are not seeing them now, it's because the configuration settings are different.

 

use a .php script with a phpinfo() statement in it to find what the master/local error_reporting, display_errors, and log_errors settings are.

[ginerjm]

It appears that something has changed in that case. I used to see almost every simple error and rarely had "fatal ones" that stopped the script. Now everything seems to be going to the error_log file.

 

display errors - set to off

error reporting - 32767

error_log - error_log

log_errors - on

 

Anything else I should look at?

[kicken]

Your host probably re-configured things when it upgrade PHP. In the past many shared hosting providers I used would have things configured with display_errors=On but that's not an ideal configuration for a production server as it exposes too much. Your host was probably setup like that previously and when they upgraded finally changed it to the better display_errors=Off with logging setup instead.

 

The old configuration would let you see the parse errors because of the PHP configuration, not your script specific settings. The new configuration doesn't show the errors, and your script can't override that if it can't be parsed.

 

So your options now are

• Re-configure PHP to show errors again or
• Start checking the error log file when you get a blank screen or
• Re-work your application to use a main front-end file that sets your error reporting then require's the rest of your code.

[ginerjm]

Thanks!