Enable debug mode / debug options in site health

[amykamala]

Debugging is a necessity for any developer and for WordPress users in general. As it stands now debug mode and the related debug options can only be enabled through manually editing the wp-config file to add or adjust wp-config constants. This makes debugging harder to access for everyone, and even more difficult to access for users that are either not familiar with ftp/ssh or who only have wp-admin access and not access to the filesystem.

Adding toggle options for debugging mode in the Site Health tools wp-admin page would make troubleshooting errors and issues easier and more accessible for all users with administrator access. As a bonus, this would also decrease the demand on web host technical support because users would be more equipt to identify plugin conflicts, php errors and other issues independently.

Proposed Site Health Options:

• 'Enable debugging on/off' -- WP_DEBUG true/false with false as default and subtext about only setting to true/on for troubleshooting bc of adverse performance effects.
• 'Enable debug log on/off' -- WP_DEBUG_LOG true/false - set to true/on as default and
• Site Health could and should have a tab to view contents of debug logs within wp-admin (maybe -tail 30 or the last 30-50 results, potentially could improve on this to hide duplicate entries, to hide warnings and notices and to grep/search for keywords)
• 'Show errors on front end on/off' - WP_DEBUG_DISPLAY true/false with a default to false so as not to expose debugging to end users and this could also have a toggle option to display errors only in wp-admin pages and not on the front end
• Debugging should be set to never display on the front end in the first place as a default (ever), that could probably be it's own ticket
• This could be expanded on to include toggle settings for SCRIPT_DEBUG and SAVEQUERIES constants

[afragen]

Take a look at the ​WP Debugging plugin. It seems to me this is more an area for plugins than it is for core.

[jorbin]

These settings are ones where people could enable things in production that should never be enabled in production. I think using the ​WordPress philosophy of Decisions Not Options, this should be closed as wontfix.

[amykamala]

Replying to jorbin:

These settings are ones where people could enable things in production that should never be enabled in production. I think using the ​WordPress philosophy of Decisions Not Options, this should be closed as wontfix.

Understood, although these settings can already be enabled in production.

[nico23]

Replying to amykamala:

Replying to jorbin:

These settings are ones where people could enable things in production that should never be enabled in production. I think using the ​WordPress philosophy of Decisions Not Options, this should be closed as wontfix.

Understood, although these settings can already be enabled in production.

The point is, not every casual user should be able to (accidentally) flip a switch in the WP admin to then expose all kinds of possible dangerous information on a production site.