Make WordPress Core

Opened 6 years ago

Last modified 6 years ago

#43665 new defect (bug)

XHR requests disregard the WP_DEBUG_DISPLAY flag

Reported by: owenmelbz's profile OwenMelbz Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: General Keywords:
Focuses: Cc:

Description

Within wp-includes/load.php and the wp_debug_mode() method it does

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

This then turns off the rendering of PHP issues.

This makes it very problematic when actively developing ajax endpoints via admin-ajax.php as you have to keep turning them back on.

It seems that it should at least appreciate the WP_DEBUG_DISPLAY constant

Is this something we could look at getting addressed?

Change History (2)

#1 @ocean90
6 years ago

  • Version 4.9.5 deleted

Hello @OwenMelbz, welcome to WordPress Trac!

I don't see this as "very problematic" since there are at least two alternatives mentioned in ticket:26262:17 and ticket:26262:18.

#2 @OwenMelbz
6 years ago

Id say that the fact there is a simple solution to the problem, would it really that bad to include it if it can help enhance the development experience? Wondering what the downside actually is?

Regards to being problematic I feel it should still definitely be considered as this, especially as it creates a peculiar dynamic between debugging ajax work and everything else - why is there a difference? Why can't it be consistent?

Regards to constantly referring back to an error log, this adds an additional overhead to the developer during development, making them refer to other files to simply understand whats in front of them.

It also adds an initial understanding barrier - as somebody will be setting up their configuration, e.g in their configs for example, then they're blindly getting overwritten, without explanation - which can affect deadlines and stress for developers trying to track down whats going on.

Yes as you say theres "alternatives" but why should people have to find alternatives? This doesn't seem a very user-centric approach to the issue, if there is something that can be done, fairly easily, why not?

If this is something that the core will consider, I'd happily submit the PR myself.

Everybody wants to create the best product possible for all those involved, so I think making small decisions like this to enhance the development experience can be really important.

Note: See TracTickets for help on using tickets.