db error page unconditionally displays db details

looks reasonable to me. needs testing.

- Mysql should be MySQL in the new text portions of the patch
- The real underlying problem is not what geeky message we display but whether we display a geeky message or a friendly one. Unfortunately if there is no database, we cannot display a page which was set on the admin interface (as with 404 and 403 pages). What we could do however is to provide a setting to specify the text on the page somehow.

I think this needs to be thought through properly. What is possible by theming this page? Should we document that better or make it easier, or should we provide settings for how would it be possible to "ungeek" this page?!

IMHO we should not reinvent the wheel. There are methods to define what is displayed on a page and how it is displayed on a page. We have an answer for the second: maintenance page theming. So we need to find says to customize what is displayed when a database error is encountered.

We have a default error message which provides a bit too much information for the visitor. But it is very good for debugging reasons. Instead of teaching people PHP, and linking out to Drupal.org, why not encourage them to think about their users? I'd recommend:

- adding two PHP array level settings to settings.php which provide the title and body for the database error page
- if these are specified, use their contents
- if not either display the full error as it is now, or if we'd like to go that extra mile (why not:) display an intermediary error message as it is suggested here

Because these are very closely related IMHO, we should fix them all at once. Now that we have maintenance theming, I do think this is an obvious way to go and not standalone HTML files, as argued before (and as I myself also use them on some sites).

Good points. Just wanted to say my opinion: Database details on error page are not only ugly for end-users, but also kind of useless for the webmaster, who is still able to check these in settings.php - and if he can't for some reason, he's probably unable to debug the site anyway. So - aside from customizing/theming and that stuff - I would vote for the default message without details (or with a reminder to check settings.php, but no more).

Note that http://drupal.org/node/141727 (which allows theming of maintenance pages) is a more comprehensive approach to the "let me control exactly what's shown" problem. I would vastly prefer that to doing things like adding arrays in settings.php to control presentation, as that's an extremely slippery slope. It remains to be seen whether or not that can get that patch into 6.x.

This approach seems like a reasonable alternative to me; we can't use Drupal's error_level variable, since we have no database, so we use PHP's equivalent instead.

Pardon me. I said "alternative" but that's not what I meant. I meant that the two could co-exist well.

Power users and developers are going to want control over exactly how this page looks, what it says, etc. The solution for them is to make maintenance pages themable, so they can go to town.

New users, however, shouldn't have to understand the theming system in order to hide this information. This patch caters to them.

My fundamental problem as explained is that we are displaying a message to a visitor here, not to a site maintainer. The previous test was precisely tailored to the site maintainer and the short version is still just that. I don't think this patch solves the underlying issue.

Previous text, I mean.

I guess theming is quite too much for this moment in D6 release cycle... (?) Should we consider just the message for now?

We can still target the text to the end user and not the site maintainer, providing a small hint to the site maintainer only. Unfortunately no activity in this issue in a month made more extensive themeing late for D6 :(

Okay, attaching a patch with only the texts changed. The hint for maintainer is now minimal, which is IMO correct - we have nice installer now, so these error-pages are only shown if the server goes down, and doesn't serve as install-troubleshooting help anymore. Also the hint is now formatted as a tiny footnote only, below an usual "try again later" message for the end users. The manual-page link is taken from existing code without change. I think that the "Troubleshooting FAQ" section should have a page on this subject, though.

Attaching the patch, as well as screenshots before/after. Tested on MySQL only.

Updated patch, with page titles and 'site' instead of 'requested page'. I also noticed that the HTML header was set inconsistently, only for SOME errors, so fixed that too.

The db details on display_errors - well, it would be consistent indeed, but IMO not necessary. There's already a reminder to check settings.php, which contains all the details. The site maintainer is probably going to visit that file anyway, so there's not much need to add extra code to show name/host on the page too. Just my opinion on this part...

This still applies cleanly.

More feedback welcome. This needs to be fixed IMO, the text for D6 shouldn't wait. (Rest is for D7 now)

I just realized, that this was probably not getting attention, because it was set to "feature". That was true while considering theming, but now this is only about the message again - and THIS is clearly UI bug, a confusion between messages facing site *visitor* and site *maintainer*. So updating category now.

The wording looks much, much better, and yes this is much more for site visitors than admins. If you're an admin and your site goes down, the existing error message doesn't tell you anything you don't know already, and if you don't know, it won't help you. So a big +1 from me.

As far as I see:

- we can loose the () around the small text
- "handbook" => "the handbook"
- it would be better to make these small admin notes shorter *and* include a TROUBLESHOOTING.txt in Drupal, where the original troubleshooting tips are included, and this error message can point to there. Currently it points to the root of the getting started guide, which still requires the admin to look around and find where these things are explained

So basically, not treating the viewer the site admin with the error messages is IMHO all good, but site admins should still have good instructions, to which this patch should only add a little bit of indirection.

The '()' and 'the handbook' are fine with me, going to include on next re-roll...

But let's discuss the rest a bit:
Old:

If you still have to install Drupal, proceed to the installation page.

If you have already finished installing Drupal, this either means that the username and password information in your settings.php file is incorrect or that we can't connect to the MySQL database server. This could mean your hosting provider's database server is down.

The MySQL error was: **** .

Currently, the username is **** and the database server is ****.

- Are you sure you have the correct username and password?
- Are you sure that you have typed the correct hostname?
- Are you sure that the database server is running?

For more help, see the Installation and upgrading handbook. If you are unsure what these terms mean you should probably contact your hosting provider.

New:

The site is currently not available due to technical problems. Please try again later. Thank you for your understanding.
--------------------------------
(If you are the maintainer of this site, please check your database settings in the settings.php file, and whether your hosting provider's database server is running. The MySQL error was: ****. For more help, see handbook, or contact your hosting provider.)

Apart from the mention of install process (which is probably not the case now, with our current installer), the database username/server (which is rather private information, and may be easily found in settings.php), and some redundancy (twice mentioned username/password, server not/running), the new wording say basically the same: Check settings.php, whether the server is up, read manual or contact hosting provider, and here is your error message. Amen. The provided link is the same as previously, too. Showing the DB error message is IMO unavoidable, as it's the only really useful part for the maintainer, which can't be observed (easily) elsewhere.

So, this patch only changes wording to be more site-visitor focused, without really changing the contents of that page. I think changing the contents is out of this issue scope - if we want to add a really sensible and useful TROUBLESHOOTING.txt to Drupal, it would probably require nothing less than a summary from corresponding handbook section, or at the very least some common pitfalls (installing and file permissions, legendar "how to log in on maintenance mode", update.php access and usage, how to disable bad module manually, how to get rid of broken clean URLs etc. etc....)

That would probably mean a lot of discussion, arguing whether such a file is even needed (and yes, it would be another instance of the same texts to be kept up-to-date), a lot of work... Forgive me my pesimism, but I don't think that such a task is realistic for D6 timeframe. (See also where http://drupal.org/node/191310 got stuck.)

We already postponed the theming attempt here. I would say - let's drop changes to the text's logic too. We need to make it visitor-focused first of all. Then we can do more, if possible - or postpone if appropriate.

More opinions welcome :) I will be happy to reroll with any suggested text.

Re-rolled without '()' and with 'the' for now...

As for me - it's rather production site suddenly down (if anything), where I need to see error message, to know what to tell my hosting provider. Testing environment is likely to show errors on install-time only, unless I changed something consciously.

But OK, I see general agreement here is leaning towards dispaly_errors route, and I've no problem with that. I don't strictly need to see *any* error messages on the front-end.

Fine. I never got a chance to access these on the shared webhosting where the site is, as well as I have no permission to create another database, to use .htaccess URL rewriting, to set_time_limit(), or to execute command-line things in any way... But I guess that I'm the only one here with so limited permissions on live server...?

But anyway, no need to discuss this further. I already said, that I'm OK with removing the error message; the plain fact that the page got displayed is sufficient for me. If there's agreement on dispaly_errors way (seems like that), let's have it so. Visitor focused text is most important here.

#25 still applies with just a tiny offset, and needs some review. Most of the patch was my proposal, and my setup makes the display_errors part hard to review too, so I'm not going to set this RTBC; leaving that to others ;)

"Bump" - that's what people call it here? Just a reminder that this needs to be fixed IMO; I feel really bad when the db-down screen appears, and I know that all site visitors see that techno-page.

Two things:

- I'd like to see more feedback from the development community (ie. post on the devel list and ask for feedback as comments on this issue). These error messages removed by this patch (which I don't like either) serve an important debugging purpose, and help people solve their problems much more quickly. As said earlier, I am not sure they are to be completely removed when error reporting on on.

- All error messages introduced with this patch look identical. Why not have a central error message function then? Only the single line error message part looks different in these pages.

The patch only just changes existing messages (this code duplication is pre-existing), it should be possible to change easily, but testing would be quite difficult (I don't have PgSQL). Also if we need to communicate and discuss this in mailing lists, considering the issue queue insufficient/inappropriate, then it'll be nice if someone else step in.

I'm sorry, but although the above comment is good and valid feedback here, it makes this issue go beyond my possibilities (I'm not on any mailing lists, purely for time matters - the issue queue alone consumes 90% of my Drupal-available time for just reading, given my sub-optimal English skills). I would say that I de-assign myself now, for time matters, but I was not really assigned anyway. ;)

Thanks for the comment, still.

The existing messages provide context sensitive tips on what might have gone wrong, although these overlap somewhat. I specifically asked this:

(ie. post on the devel list and ask for feedback as comments on this issue)

So I did not say this issue queue is not sufficient. I said we need to breathe in some life here and gather feedback. I'll post a note to the mailing list.

Thanks a lot :)

(This little misunderstanding only just underlines my need to learn further about the other ways of communication here in community, which would mean another evening worth of research for me, probably. My Drupal activity in general is growing over my time resources, I'm afraid. Going to stop posting rants, now ;)

In response to #31 (request for additional feedback), I completely support this patch.
-- There are debugging avenues open to the site owner that go outside relying on information from the current error message.
-- To quote statistics that I am even now making up, 90% of sites aren't going to theme these pages, and will rely on the default presentation.
-- The default presentation presents too much information to the general public, even if nothing it reveals is inherently damaging information. See this article, complete with screenshots of this page in the wild: http://soopergeek.blogspot.com/2007/11/unity08com-oops.html

Opinions here, not much time for test, sorry! Most of the current message most of the time makes no sense since the installer is in -- if you'd have mistyped this or that you wouldn't be installed in the first place. Therefore, I support the idea of this patch. I am not 100% I ike the current text but honestly, I do not really care, at the end of day, the actual message matters not that much as long as there is a friendly message. Any serious site is monitored by nagios or similar and if the normal page disappears, it'll alarm anyways, so do not sweat with emailing or somesuch.

Where do we get the e-mail from if not the database? Not a bad idea, but I think this could be done at theme level.

+1 for this patch anyway.

It's great to see so much support for this. So all is left on the code part IMHO is to centralize this instead of repeating the same stuff in all places, and parameterize the variables.

I found a bit of time finally, so there's the patch with all error messages centralized in one function. So this gives us just one instance of these to maintain - I also used it for all other db-dead pages, which were quite similar: Apart from the actual error message (now passed into the new function), there was always something like 'see handbook or contact hosting provider' everywhere.

Error messages are only shown if 'show_errors' is on. (i.e. the bottom line will go away if 'show_errors' is off - see screenshot).

It also saves us quite a bit of code (also removed the MySQLi differentiation between two types of errors, as the resulting pages are the same now), and brings us consistency (HTML headers, 'show_errors' handling).

Tested on MySQL, and the MySQLi/PgSQL/unknown db type 'not supported' failures. Needs to be tested to *not* break other databases.

Unfortunately, that's impossible. These constants are defined in system.module, which is not available (bootstrap dies far before the module system initialized, with no database available); constants are undefined for us. Although it would be more or less possible to hardcode the path, and include system.module manually, I think that it would be definitely an overkill.

But otherwise you're quite right that the message (which I just pasted from existing code without substantial change) is now pretty outdated, speaking about version numbers far below the Drupal minimum. IMO, the version numbers are not necessary there - the message actually just says that the provided database type is not supported, and hints which ones would be ok; no need to elaborate further. After all, this error is most probably caused by a typo in a manual edit of settings.php (migrating the site to a different server), and the important information for db type selection is rather php-extension availability on the server (plus hosting provider's advice), and not primarily any research on version numbers.

So I just removed the version suggestions from that message.

A couple of very minor things now that I look at the new message in detail:

+  $message = '<p>The site is currently not available due to technical problems. Please try again later. Thank you for your understanding.</p>';
+  $message .= '<hr /><p><small>If you are the maintainer of this site, please check your database settings in the settings.php file, and whether your hosting provider\'s database server is running. For more help, see the <a href="http://drupal.org/node/258">handbook</a>, or contact your hosting provider.</small></p>';

How about this small change (the use of whether is a bit vague):

+  $message = '<p>The site is currently not available due to technical problems. Please try again later. Thank you for your understanding.</p>';
+  $message .= '<hr /><p><small>If you are the maintainer of this site, please check your database settings in the settings.php file and ensure that your hosting provider\'s database server is running. For more help, see the <a href="http://drupal.org/node/258">handbook</a>, or contact your hosting provider.</small></p>';

Never mind -- I should have just rolled a patch, 'tis just two words. (Please don't credit me for this, btw.)

Thanks a lot; as a non-native speaker, I just don't see these nuances at all...

#49 still applies cleanly, but needs someone to test and set RTBC if feeling so - this would be really good to have fixed in time for 6.0

The patch looks good for commit, but would need some testing still for sure.

Applies cleanly, tested with a mysql restart, works, much nicer :)

Since #49 fixed pgsql issues ought to be fine.

Great, thanks, committed.