0

I just changed hosts. Everything is set up and working except I get a ton of errors that all start out PHP Strict Standards:

I turned off E_STRICT in php.ini. When I run phpinfo() to verify it, it shows as off. It shows

error_reporting = 22519 = 01010111 11110111. E_STRICT is bit 11 (2048).

My first question is, is it possible for these errors to be generated without E_STRICT somehow?

My phpinfo() call is at the root directory. But I've also checked each directory between root and the directories where these functions occur. Neither there is any other php.ini, nor is there a .htaccess file with a conflicting suPHP_ConfigPath call.

These PHP files get called anytime someone presses a link or button on my site, so I'll get a MB per hour or some such of these darned warnings. But I can't figure out how I'm getting them if E_STRICT is turned off.

Anyone got a bright idea of something else I should check?

DhruvJoshi
  • 17,041
  • 6
  • 41
  • 60
mikekehrli
  • 332
  • 3
  • 10

2 Answers2

0

Best Mikekehrli,

Please try to add:

error_reporting(E_ERROR | E_WARNING | E_PARSE);

at the start of your script, and look if you still get strict messages.

Perrykipkerrie
  • 380
  • 1
  • 3
  • 12
  • It seemed to actually generate more errors than before. But they all start with "PHP Strict Standards:" Note, it could just be there was more activity at the moment in time. – mikekehrli Dec 18 '15 at 07:43
  • try error_reporting(0), then you should get no errors (just for debugging for now) – Perrykipkerrie Dec 18 '15 at 07:44
  • Furthermore, i found this page, maybe it is to use for you [link] (http://stackoverflow.com/questions/1248952/php-5-disable-strict-standards-error) – Perrykipkerrie Dec 18 '15 at 07:46
  • Still getting the errors. Where could they be coming from? I'll show a sample error here: [18-Dec-2015 02:45:56 America/Detroit] PHP Strict Standards: Declaration of categoriesParser::identifyPage() should be compatible with SSUParser::identifyPage($uri_parts) in /home/fuelsave/public_html/includes/classes/ssu/plugins/parsers/categories.php on line 160. Now in the categories.php, i put at the top, but in part of the php body "error_reporting(0);". Immediately below that was the beginning of a class definition. – mikekehrli Dec 18 '15 at 07:49
  • There's something I'm missing. By all rights I have done the actions that should be turning off these errors, but they won't turn off. I just don't know what I'm missing. – mikekehrli Dec 18 '15 at 07:51
  • Hey, one other thing. I looked up the categories.php file and the iine number that the error is reporting is the last line in the file. What does that mean? I'm thinking maybe the error is happening somewhere else, but it's being reported for categories.php incorrectly. Does that sound possible? – mikekehrli Dec 18 '15 at 07:55
  • If everything worked on your previous host, and now it doesnt, try to contact the new host, maybe they have some setting that you cannot change this reporting – Perrykipkerrie Dec 18 '15 at 08:04
  • What have you done to accomplish this, (It is nice for other users if you post the solution) :D – Perrykipkerrie Dec 18 '15 at 08:05
  • I found out where the file was that had the class that the error message should match, and set error_reporting(0); in that file. That stopped the errors. Even thought that file name was never mentioned in any of the errors. I think now, I can turn on normal error reporting, and turn off strict where it needs to be only. – mikekehrli Dec 18 '15 at 08:06
  • I'll post the solution when I get get it all finalized. But this was a toughie. – mikekehrli Dec 18 '15 at 08:06
  • Haha, but some thoughs, is it possible to solve this strict error problem? as hiding the error will not fix the error ;). BTW the large problems which needs a lot of time are often the ones in which you dont have to change a lot in the code xD. Maybe search your project for error_reporting or display_errors and remove them all make one global error_reporting at the start of your script. – Perrykipkerrie Dec 18 '15 at 08:08
0

Ok, the problem is solved.
But changing error_reporting in the file that was reported in the error didn't change anything.

I had to find the file that had the class that the error said was in conflict, and when I changed error_reporting in that file, the errors stopped proppping.

Note, that changes the the php.ini error_reporting variable were not effective in changing this situation. Only changing it in the script itself handled the problem.

DhruvJoshi
  • 17,041
  • 6
  • 41
  • 60
mikekehrli
  • 332
  • 3
  • 10