Check for display_errors in Site Health

[zodiac1978]

It would be great if we can also check if display_errors is enabled on the server as this is not recommended:
​https://make.wordpress.org/core/handbook/testing/reporting-security-vulnerabilities/#why-are-there-path-disclosures-when-directly-loading-certain-files

Unfortunately there are many hoster (Siteground, 1and1/Ionos, Domainfactory, all-inkl.com, ...) with this setting enabled as default.

There are snippets flying around to add this to the .htaccess, but there are not working in any environment:

<IfModule mod_php7.c> php_flag display_errors off </IfModule>

This is because if PHP is not running as a module but as FastCGI/PHP-FPM you need to use a .user.ini file with the content display_errors = 0 instead or change this in your hoster settings.

First reported here: ​https://github.com/WordPress/health-check/issues/370

[Clorith]

Would it make sense to include this in the existing check that sees if debug log printing is enabled? It's essentially the same, only enabled at the server level, and not through WP_DEBUG, but the outcome is the same.

[zodiac1978]

Replying to Clorith:

Would it make sense to include this in the existing check that sees if debug log printing is enabled? It's essentially the same, only enabled at the server level, and not through WP_DEBUG, but the outcome is the same.

In both cases there is a full path disclosure which is possibly revealing private information like usernames/client IDs/etc. - so yes, this could be added to the already existing check IMO.

But we should add some hint, so that a user knows which problem needs fixing. In my case I have already added the mentioned code in the .htaccess and was lost for some hours, until I found the explanation and added the code in a .user.uni.

[Clorith]

I think linking to a dotorg document on what this means and the various ways it can be enabled/disabled etc is the best path forward here, since the implementation on host systems can vary, trying to hint at in inside a result may end up being more confusing than helpful I think.

Do we have any documentation on this already that can be linked to? (cc @atachibana as the wizard of HelpHub knowledge)

[atachibana]

@Clorith

We can see some 'display_errors' at
Configure Error Logging section in Editing wp-config.php:
​https://wordpress.org/support/article/editing-wp-config-php/
(Though a bit narrative for non-native English speaker...)

Or, you may use
Hardening WordPress:
​https://wordpress.org/support/article/hardening-wordpress/
(Again, a bit narrative...)

[zodiac1978]

Thanks for looking up those pages @atachibana

Replying to atachibana:

We can see some 'display_errors' at
Configure Error Logging section in Editing wp-config.php:
​https://wordpress.org/support/article/editing-wp-config-php/
(Though a bit narrative for non-native English speaker...)

I am not sure if the examples will work in every case. If it would be necessary to use a .user.ini file it would be not the correct location I think.

Or, you may use
Hardening WordPress:
​https://wordpress.org/support/article/hardening-wordpress/
(Again, a bit narrative...)

This looks like the best place to me. It is a full path disclosure and therefore a hardening for WordPress. A new paragraph explaining the issue and possible fixes would be the best way to solve this IMHO.

In Site Health we could link to the new paragraph and if useful to the first article too (because it is explaining the WP constants).

[Clorith]

Sounds like a great approach then, so let's include it as part of the is_in_debug_mode test, and include a link to that new documentation area once it's been written. Adding the needs-codex keyword here, that it is dependent on user-facing documentation being in place before this can be implemented.

[zodiac1978]

Replying to Clorith:

Sounds like a great approach then, so let's include it as part of the is_in_debug_mode test, and include a link to that new documentation area once it's been written. Adding the needs-codex keyword here, that it is dependent on user-facing documentation being in place before this can be implemented.

I am not sure how to start a suggestion for this text. On ​https://make.wordpress.org/docs/handbook/helphub/migrating-articles/ I doesn't found any info about adding content to a page. Can someone point me in the right way? Maybe @atachibana ?

Would it be useful to start with a Google doc?

[atachibana]

@zodiac1978

We are trying to use github issues (​https://github.com/WordPress/HelpHub/issues) or this ticket system or Slack. (But, in reality, each editor is updating the contents especially when issue was found...)
For this issue, please use this thread so that everyone can watch the same page.

By the way, I'll update your specified handbook page to guide github page for the issue report. Thank you.

[aurimakela]

Greetings from WordCamp Finland 2023! We worked on documentation for this on the Contributor Day. Props to @nullbyte and @javiercasares! Do you think this is sufficient? :) ​https://developer.wordpress.org/advanced-administration/security/hardening/display-errors/