WordPress displays errors normal way

[johnnypea]

Maybe I am doing something wrong but the error handling is not affected at all in my WordPress application (v3.4.2). I followed the instructions in documentation and include it to header.php in theme. I also tried to initialize it directly when WordPress loads but with a same result.

I would like to have all the major errors in plugins and theme handled by your tool which is btw very cool. Thanks for your work on PHP Error anyways, very helpful on other projects too.

[voodooGQ]

I'm having the same issue as @johnnypea . Followed the instructions but am still getting the standard PHP errors. Also using v3.4.2

[JosephLenton]

This should now be fixed, so please test with the version here on GitHub (the official version is not yet updated).

The problem was that Wordpress had made some changes; content type now includes the character set, and it now flushes output as it goes. These had messed up PHP Error, but should now be fixed.

[voodooGQ]

This doesn't seem to have fixed the problem. With the method of adding to the header.php file I still am seeing the normal PHP errors. My .user.ini file is set with display_errors = ON.

When I go about it with the auto_prepend_file method described: https://github.com/JosephLenton/PHP-Error/wiki/Example-Setup it tells me that the file cannot be located, regardless of where I place it.

If you need further details please let me know and I will try and help as much as possible. This looks like a "must have" piece of code and I'd love to get it working.

[JosephLenton]

I am using Wordpress 3.4.2 as well, so it can work (in theory). Ok, lets do a few sanity checks, to ensure nothing obvious is missing.

1) make sure display_errors is definitely getting set to On, by adding:

var_dump( ini_get('display_errors') === '1' );

... to your wordpress site, and recording the output. That should print true, and if it's false, then it's not being set in the .ini file.

2) after calling reportErrors, dump the variable $_php_error_is_ini_enabled, i.e.:

global $_php_error_is_ini_enabled;
var_dump( $_php_error_is_ini_enabled );

That should be returning true. If it's false, it's thinking it's in production and should be silent.

3) If you have just added 'display_errors', make sure you turned Apache off and on again.

4) make sure you are calling \php_error\reportErrors() in your header (or have it set to autorun).

5) What webserver are you using, is it Apache with mod_php or something else? Also which version?

Thanks!

[voodooGQ]

Answer to Question 5: I'm running _IIS v. 7.0.6000.16386_ on _Windows Server 2008 v6.0 (Build 6001: SP1)_ (Not by choice)

I'm going to go through your list and see what I am able to come up with. I'll give you a detailed report here shortly.

[voodooGQ]

Currently running WP 3.4.2. I have a parent/child theme set up \wp-content\themes\parent && \wp-content\themes\child. Obviously the child inherits from the parent.

Attempt 1

1.Downloaded the php_error.php from GitHub and placed it in the \wp-content\themes\child folder 2.Added the following to the \wp-content\themes\child\header.php file, directly above the inital tag:

require( 'php_error.php' );
  \php_error\reportErrors(array(
       'wordpress' => true
  ) );

3.Because of the way our server is setup, the following was added to .user.ini file. This file is located in the root of the project.

display_errors = On

_Result:_

Original PHP Errors still in tact.

Parse error: syntax error, unexpected T_STRING in C:\inetpub\wwwroot\project\wp-content\themes\child\functions.php on line 14

*Applying your suggestions: *

1.Added the ini_get call directly below the require in the header and received a result of true. 2.Added the $_php_error_is_ini_enabled global and call and also received a result of true. 3.Suggestions 3-5 are already covered. display_errors is on. reportErrors() is in the header. And my webserver sucks :)

Attempt 2

1.Steps 1 and 3 are still in play from the previous attempt, but this time I removed the information from step 2.

2. I updated the .user.ini file to the following:

display_errors = On
auto_prepend_file = "C:\inetpub\wwwroot\project\wp-content\themes\child\php_error.php"
php_error.autorun = On
php_error.wordpress = On

_Result:_

Original PHP Errors still in tact.

Parse error: syntax error, unexpected T_STRING in C:\inetpub\wwwroot\project\wp-content\themes\child\functions.php on line 14

sigh. I'm guessing it has to do with IIS 7. Why would I ever expect Microsoft to play nice with another program. Any help you can give would be amazing.

[JosephLenton]

Yeah, I'm betting it's IIS too.

I'll try getting it setup on my home PC tonight, and debugging this.

[voodooGQ]

Sounds good, thank you for all your help with this.

[JosephLenton]

Try it now!

I've just been running it successfully under IIS 7. A few bugs have been hammered out.

[voodooGQ]

Sounds good. I will be able to test it here shortly. I'll give you a report back before the end of the day.

[voodooGQ]

Still no results :(

At this point the only thing I can really think that may be causing a conflict is the fact that I'm using a .user.ini file instead of a php.ini file. I honestly don't understand how that would make a difference but it seems to be the only thing I can really notice that's out of the norm.

I changed permissions, moved the files around, even tried closing the end of the php_error.php file itself but would just get the same thing every time.

Anything else I can supply to you to try and help debug this?

[JosephLenton]

One thing that should work, is if you open the IIS Manager, click on FastCGI Settings, open the PHP setup, and change 'Standard error mode' to 'IgnoreAndReturn200'.

That worked for me last night, however I was pretty sure I had worked around it, so the default worked too. : (

[voodooGQ]

I'll have to test this tonight on XAMP before I go forward in my current "live" environment. But I'll give this a try next. Thanks again Joseph.