Errors not being written to error.log, inside a custom class

Viewed 187

I've made a WordPress theme with a bunch of custom classes and custom functionality (this is more of a PHP-question though). In the past, whenever there had been an issue in one of those classes, then I could check the wp-content/debug.log to see what the problem was. This had been working for 6 months reliably.

But now I'm getting an error, where in the frontend it says:

There has been a critical error on your website. Please check your site admin email inbox for instructions.

But if I check wp-content/debug.log, then I can't see any error.


Solution attempt 1: Try to 'provoke' an error

I tried adding this to the top of my functions.php-file:

if( !empty( $_GET['test'] ) ){
    require('some/path/that/doesnt/exists.php' );
}

And then visit: https://example.org/?test=1234

And this results in a 'critical error' - and the output is written to wp-content/debug.log. The error being:

[03-Aug-2021 09:20:10 UTC] PHP Warning: require(some/path/that/doesnt/exists.php): Failed to open stream: No such file or directory in ... on line ...

However... If I move that faulty line (require('some/path/that/doesnt/exists.php' );) inside one of my custom classes, that I know is throwing the error, the I don't get anything in the debug.log. Hmm!

Solution attempt 2: Ensure debug.log wasnt too big

Sometimes I've seen wierd results, if the debug.log was enormous (like 50mb+). So I tried deleting it and creating a new. Same result.

Solution attempt 3: Ensure debugging-setting are setup properly

This is what I have in my wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set('display_errors',0);

And since it throws the warning as it should on the faulty require()-function, then I think that is as it should be.

Solution attempt 4: Tried pointing to a different debug.log-file

I can change which file WordPress will write to, but replacing this line:

define( 'WP_DEBUG_LOG', true );

with this line:

define( 'WP_DEBUG_LOG', 'wp-content/new-debug.log' );

But it's the same here: Still only some of the errors appears.

Solution attempt 5: Ensure error_reporting is set correctly

I tried following the instructions on setting error_reporting like suggested in that answer there.

But I'm still not getting the error in my debug.log-file.

If I write these lines:

var_dump(E_ALL);
var_dump(E_STRICT);
var_dump(E_ALL | E_STRICT);
var_dump(E_ALL & E_STRICT);

Then it outputs:

int(32767) int(2048) int(32767) int(2048)

Both, when doing it just after setting the ini_sets, in the wp-config.php-file, but also if I do it inside one of the classes that "doesn't write to the debug.log"-file. I'm not sure what that means, though.

Solution attempt 6: Clear cache

I tried clearing a bunch of cache: The server varnish cache. The cache setup using a WordPress-plugin. Nothing changed.

Solution attempt 7: Read WordPress Troubleshooting documentation

I read WordPress Documentation on Troubleshooting, but wasn't able to find anything in there.

Solution attempt 8: Copy to other server and try an replicate error (SUPER-WIERD!)

This is when it gets really wierd!

I copied the site to another server and at first the same problem was there: That I got the error in the frontend, but nothing was written to wp-content/debug.log.

Then I tried doing a binary-search for exactly what was causing this 'critical error'. So I went through the files adding the lines:

<?php
die('Do I make it this far?');
?>

And moving that down through the code. In the end, I figured out that it was this line here:

if( array_key_exists( $some_id, $shortlisted_part_ids ) ){

... where $shortlisted_part_ids is null (not an array).

But having found that, then I removed my 'die()'-statement AND THEN THE ERROR APPEARED IN THE wp-content/debug.log-FILE!? Without changing anything else, beside going through the code making it 'die' a bazillion times.

And note, that this is only on the development-server. If I add the same die()-statement to the production-server and then remove it again afterwards, then (sigh), still getting the critical error in the frontend and still nothing is written in the error-log.

Non-attempted solutions

  • List most recent changed files: I figured that maybe a plugin or some code changes which debug-file to write to. So if I listed the most recent changed files, after getting a critical error, then it may show which file the error is being written to. I Googled around, trying to find this terminal-command - and played around with grep a bit, but I couldn't find the right command.
  • Boot server: I haven't tried restarting the server, since it's a production environment, with a lot of visitors. And even if that solves it, then I hate relying on booting something, to make it work.
  • Deactivate plugins + change theme: I haven't tried the usual: Deactivate all plugins and change to default theme', since - again - It's not a viable troubleshooting-technique,

Other comment

  • Xdebug: I recently played around with setting up Xdebug on that server. Maybe I did something, while doing that. What I can't understand is what some of the errors shows up and some doesn't.
  • Admin email: I received and email with the error, some of the times?!
1 Answers

Recently modified files can be found with something like find . -type f -newermt '2021-08-19'. That's only part of the solution.

One also needs to have in mind that WooCommerce can intercept PHP errors and log them in /wp-content/uploads/wc-logs/.... (credit: Zeth).

Related