Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Currently, after a clean install of Drupal the PHP error reporting is set to 'All messages' which equals ERROR_REPORTING_DISPLAY_ALL. On this page /admin/config/development/logging we tell users that 'It is recommended that sites running on production environments do not display any errors.'
Shouldn't error reporting be set to 'none' then as a default? If a developer needs it he can always turn it on, but from a security POV I think it should initially be turned off so that inexperienced users don't run their live-sites with PHP error-reporting turned on.
One-line patch attached.
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | error_level-688638-1.patch | 713 bytes | scronide |
| #3 | 688638_error_reporting.patch | 1.74 KB | reglogge |
| error_reporting_none.patch | 765 bytes | reglogge | |
Comments
Comment #1
janusman CreditAttribution: janusman commentedSimple enough. Works. Don't know if this is what we want, though?
EDIT: Also, not a bug?
Comment #2
Dries CreditAttribution: Dries commentedI'm not sure. If we do this, we should probably also enable caching out of the box. It seems inconsistent to disable error messages, and not to enable caching.
Comment #3
reglogge CreditAttribution: reglogge commented@Dries: I get your point.
How about this as an alternative:
Add an entry to the status report that issues a warning when PHP error reporting is not set to 'none'.
This way we could leave it on by default but also gently remind people running production servers that they should better turn it off.
Patch attached.
Comment #4
reglogge CreditAttribution: reglogge commenteddang.
Comment #5
moshe weitzman CreditAttribution: moshe weitzman commentedThis touches on a more fundamental problem with our standard install profile. It serves multiple purposes, and thus fails at all of them. The fancy new admin features are enabled in standard yet they are not for site builders but rather for content creators. Assuming that building a site is what you want to do first, probably want overlay disabled.
I think we need a 'build a site' profile and we need a 'evaluate drupal' profile. build a site will be more technicaly modest (i.e. no overlay, has error reporting, ...). 'drupal evaluation' has all the admin features and more importantly, has sample data.
Sorry to dump that on this poor issue. Been in my head for a while now.
Comment #6
reglogge CreditAttribution: reglogge commented@moshe weitzman: I readily agree with
The solution to ship Drupal with different install profiles seems like overkill to me though. After all, it's only a few settings that would differ (overlay enabled/disabled, error-reporting on/off, caching on/off, maybe dashboard and contextual links enabled/disabled), the consequences of most of which have more of a nuisance value. Also, that would neccessitate some additional (and probably rather convoluted) help texts to be displayed during install. Just my 2ct.
Returning to the issue at hand, are there any reasons not to include this setting in the status report? After all it is a security issue when reporting is turned on on live sites and the status page is visited much more often (I presume) than admin/config/development/logging.
Comment #7
Dries CreditAttribution: Dries commentedLet's assume that the non-expert profile sets things up for newbies, i.e. we should probably enable all the right settings, including error reporting.
Comment #8
1kenthomas CreditAttribution: 1kenthomas commentedHmm.
How about a sort of different paradigm-- for instance-- live(production) mode, dev mode?
Comment #9
valthebaldBumping version and... is it still relevant with the latest profiles/distributions trend? I suppose each profile/distribution can provide default settings of it's own
Comment #10
scronide CreditAttribution: scronide commentedI'm for turning it off.
The default settings should be what a secure production site could use, matching end-user expectations and without introducing platform dependencies. The onus should be put on developers to find and tweak settings to suit their specific development requirements, rather than non-technical administrators. I can only offer hearsay, but it's well known that the vast majority of software users never change the default settings.
A developer is much more likely to want to, and be able to, find and turn on error display than a non-developer would be to turn it off.
Caching is a grey area because it can confuse and frustrate non-developers as much as it would benefit them. I would leave it off.
Comment #11
scronide CreditAttribution: scronide commentedD8 patch to simply set the error_level to 'hide' by default.
Comment #12
scronide CreditAttribution: scronide commentedComment #14
scronide CreditAttribution: scronide commented#11: error_level-688638-1.patch queued for re-testing.
Comment #16
scronide CreditAttribution: scronide commentedInstalled 8.0.0 and, as far as I can tell, this is now the case. Errors and warnings are now hidden by default based on core/modules/system/config/install/system.logging.yml
Traced fixed to: https://www.drupal.org/node/2226761
Comment #25
quietone CreditAttribution: quietone as a volunteer commented@reglogge, thanks for creating this issue and making a patch.
It appears this was addressed in a later issue, #2226761: Change all default settings and config to fast/safe production values, I guess that makes this outdated, closing as such.