Displaying PHP Errors from admin-ajax.php in Wordpress 4.9+

Question

We've got some custom endpoints set up that do various things, which we access via /wp/wp-admin/admin-ajax.php?action=some_action

However whenever there is an error as we're developing, such as syntax, logical, fatal etc, we simply get "500 Internal Server Error" when viewing the page in the browser.

Every other page on the site when there's an error, it gives us the PHP error, to help us debug.

However when the error comes from the admin-ajax.php area, we have to then open our PHP Log file to see the error instead - which is more of a pain when actively developing

Is there something in wordpress that disables displaying of errors on this URL namespace? and if so, how can we prevent this to allow rendering of the errors on the browser?

What do you mean by `PHP error` in comparison to a 500? Do you mean warnings which are able to do trace as the error is not breaking the parser? — Lawrence Cherone, Mar 26 '18 at 10:34
As in, whenever PHP throws an error/exception, for whatever reason - if the script goes through admin-ajax.php it gives the apache 500 error page, rather than a white page with a error message on it — owenmelbz, Mar 26 '18 at 11:59

score 23 · Answer 1 · answered Apr 09 '18 at 09:48

23

If you want to see the PHP errors when using ajax, open up the wp-includes/load.php file & on line 336, change this line:

if ( defined( 'XMLRPC_REQUEST' ) || defined( 'REST_REQUEST' ) || ( defined( 'WP_INSTALLING' ) && WP_INSTALLING ) || wp_doing_ajax() ) {
        @ini_set( 'display_errors', 0 );
    }

to

if ( defined( 'XMLRPC_REQUEST' ) || defined( 'REST_REQUEST' ) || ( defined( 'WP_INSTALLING' ) && WP_INSTALLING ) || wp_doing_ajax() ) {
        @ini_set( 'display_errors', 1 );
    }

You will now be able to see the ajax errors in your browser console. Remember to undo this when finished debugging!

answered Apr 09 '18 at 09:48

kb.

1,010
3
17
34

I'm not sure if both are related because it works but I keep getting `Fatal error: Allowed memory size of 134217728 bytes exhausted` – Salathiel Genese Oct 04 '18 at 04:18
Hard to debug WordPress error behind ajax request (worse: in docker)... I finally figured out the infinite loop that caused the leak. Thanks – Salathiel Genese Oct 04 '18 at 04:53
3

As of December 2018, the line number is now 353. – somebodysomewhere Dec 14 '18 at 23:14
As of August 2020, the line number is now 403. – Azamat Aug 27 '20 at 12:16
2

The line numbers may change. So search for the function `wp_debug_mode` in the file. The line to change is inside this function. – melvin Nov 30 '20 at 06:57
As of February 2021, the line number is 454 – EldenChris Feb 26 '21 at 08:43
2

As for June 2021, the line number is 471. You can search text "display_errors" and iterate the found matches, easy to find. – Mark Okhman Jun 02 '21 at 14:02
July 2021 - line 472 – Karue Benson Karue Jul 11 '21 at 07:02
August 2021 - line 485 – EldenChris Aug 13 '21 at 07:35
It does not work for me it just gives 500 server internal error – Karue Benson Karue Aug 23 '21 at 23:48

ABHi · Answer 2 · 2021-06-16T20:18:56.823

Better Solution

Enable PHP Error Output before the error is occurring

Add this to enable PHP Error Output

@ini_set( 'display_errors', 1 );

Eg: At the start of the ajax callback function in this case

Tip:

You can use the Preview tab next to the Response tab in the Dev Tools Network to render the HTML in the Error output. So that you can see the Error without the HTML

Explanation

I don't know why WordPress does not allow enabling this error output but I don't think editing the WordPress Core file and undoing them after debugging is not a good idea as answered here

From that answer, I found that we just need to set the display_errors PHP init setting to true or 1 in order to output the errors.

So why don't we just set this wherever we want this to work so that this display_errors will be enabled for that scop only.

There is no problem if you didn't undo this unlike the other answer

score 2 · Answer 3 · edited Nov 14 '21 at 13:53

Edit wp-includes/class-wp-fatal-error-handler.php and change this in display_default_error_template( $error, $handled ) (Line: 193):

$message = sprintf(
                        '<p>%s</p><p><a href="%s">%s</a></p>',
                        $message,
                        /* translators: Documentation explaining debugging in WordPress. */
                        __( 'https://wordpress.org/support/article/debugging-in-wordpress/' ),
                        __( 'Learn more about debugging in WordPress.' )
                );

to

$message = sprintf(
                        '<p>%s</p><p><a href="%s">%s</a></p>',
                        $message . ' ' . json_encode($error),
                        /* translators: Documentation explaining debugging in WordPress. */
                        __( 'https://wordpress.org/support/article/debugging-in-wordpress/' ),
                        __( 'Learn more about debugging in WordPress.' )
                );

Then preview HTML response to admin-ajax.php using Dev Tools.

TurtleTread · Answer 4 · 2018-03-28T15:03:51.270

1

https://codex.wordpress.org/Debugging_in_WordPress

 // Enable WP_DEBUG mode
define( 'WP_DEBUG', true );

// Enable Debug logging to the /wp-content/debug.log file
define( 'WP_DEBUG_LOG', true );

// Disable display of errors and warnings 
define( 'WP_DEBUG_DISPLAY', false );

Define the following constants as such. You will be able to see debug.log under wp-content. I usually leave the debug display off too because it causes the headers already sent problem.

EDIT:

So apparently error reporting is turned off for ajax requests in the last of line of the method wp_debug_mode() in wp-includes/load.php

if ( defined( 'XMLRPC_REQUEST' ) || defined( 'REST_REQUEST' ) || ( defined( 'WP_INSTALLING' ) && WP_INSTALLING ) || wp_doing_ajax() ) {
        @ini_set( 'display_errors', 0 );
    }

edited Mar 28 '18 at 15:03

answered Mar 26 '18 at 16:41

TurtleTread

1,297
2
12
23

Hi, - This seems to be the opposite of what we've asked for i'm affraid - we've already got errors logging to file - we want to be able to see them in the browser whilst developing. – owenmelbz Mar 27 '18 at 08:37
To debug ajax request errors, you need to use the log file for checking the error. To check the response in chrome, go to the inspector tool's 'network' tab, select 'xhr' to check your ajax resposne. If you simply open the ajax url in browser, it would only work for GET request and is not the proper way of doing it. – TurtleTread Mar 27 '18 at 14:14
We're not worried about "how to debug", or the "proper way of doing it" we want to know why the PHP errors are getting hidden in the `admin-ajax.php` - e.g if we do things such as `error_reporting(E_ALL);` at the top of the file it turns them back on, this means something specifically is turning them off, but only when you get into the admin-ajax world – owenmelbz Mar 27 '18 at 14:17
Ok, did you read my last part about the GET request? If your admin-ajax request function checks for POST vars, then it won't work. My point is just utilize the chrome's network's xhr to see the response and the debug log to check errors. Trust me, I've been doing this for a while now. You need to show some code and how is your admin-ajax on the frontend and backend implemented exactly. – TurtleTread Mar 27 '18 at 15:42
So to explain this a bit, I'm not sure if you are familiar with the xhr stuff. XHR is not directly displayed on the page, it's a XMLHttpRequest send by the browser to avoid page refresh, so the ajax response is not going to show up on the page. – TurtleTread Mar 27 '18 at 15:47
We're completely familiar with the ajax whole process, which is why we're saying its not related to what we're after. We're not really doing a XHR/Ajax request This is why it's not related to our question, the endpoint simply pre-renders react components server side to be used in an SPA in this instance. So there is never a need for POST data anyway, and not after "how to debug in chrome" - what we're literally after is to find out WHY php errors are not displaying on admin-ajax.php scripts unless you turn error reporting on directly in that file – owenmelbz Mar 28 '18 at 14:11
See my edit. They are actually turning off display_errors for ajax request. – TurtleTread Mar 28 '18 at 15:04
This looks like the one!! Appreciate the effort scouting that out, seems strange they do that, without regard for the other debug flags, especially the `WP_DEBUG_DISPLAY`, doesn't look like theres much you can do about that except for turning it on when needed in the file hmmm – owenmelbz Mar 30 '18 at 09:28
Not to beat it to death but normally debug logging seems to be more helpful because display errors often cause the headers already sent problem preventing you going further sometimes with just a notice popping out and not executing code further. – TurtleTread Mar 30 '18 at 14:06

Klaassiek · Answer 5 · 2023-08-15T20:30:14.257

What you can do to enable debug mode also for ajax calls is editing wp-config.php by adding the following lines before the line /* That's all, stop editing! Happy publishing. */:

$GLOBALS['wp_filter'] = array(
    'enable_wp_debug_mode_checks' => array(
        10 => array(
            array(
                 'accepted_args' => 0,
                 'function'      => function() {
                     return false;
                 },
             ),
         ),
     ),
);

This stops WordPress interfering with error reporting. (See the comments for the function wp_debug_mode in wp-includes/load.php.) Docs

Now you have the default PHP settings for debug mode. To control the settings yourself, add the following lines to your wp-config.php file:

error_reporting( E_ALL );
ini_set( 'display_errors', 1 );
ini_set( 'log_errors', 1 );
ini_set( 'error_log', ABSPATH . "wp-content/debug.log" );

Congrats! You have successfully circumvented WordPress from dealing with errors and are now in full control of this yourself.

Displaying PHP Errors from admin-ajax.php in Wordpress 4.9+

5 Answers5

Better Solution

Tip:

Explanation