[wp-trac] [WordPress Trac] #27240: Add allow_bail Argument for wpdb->check_connection() the Same as for db_connect()

[WordPress Trac]

#27240: Add allow_bail Argument for wpdb->check_connection() the Same as for
db_connect()
-------------------------+----------------------
 Reporter:  DrProtocols  |       Owner:
     Type:  enhancement  |      Status:  closed
 Priority:  normal       |   Milestone:
Component:  Database     |     Version:  trunk
 Severity:  normal       |  Resolution:  wontfix
 Keywords:               |     Focuses:
-------------------------+----------------------
Changes (by pento):

 * status:  new => closed
 * resolution:   => wontfix
 * milestone:  Awaiting Review =>


Comment:

 Thanks for the suggestion!

 So, there are a few different paths for this code.

 * Before `template_redirect`:
   1. If `WP_DEBUG` and `WP_DEBUG_DISPLAY` are set, `wpdb::bail()` will
 call `wp_die()`. This will normally only be the case on dev sites.
   1. If they're not true, `dead_db()` will be called.
 * After `template_redirect`:
   3. `wpdb::check_connection()` will not die, it will return `false`,
 which will usually translate into `wpdb::query()` returning `false`.

 For the first case, while it's possible (using the `wp_die_handler`
 filter), I'd suggest that a plugin wouldn't want to change this - `wpdb`'s
 usage of `wp_die()` is to give feedback in a dev/testing environment, not
 in production.

 For the second case, `dead_db()` can be overridden by adding a custom DB
 template at `WP_CONTENT_DIR . '/db-error.php'`. This covers the vast
 majority (I would guess >99%) of cases where the DB is dead, as it dies
 before WP can even connect to it. It's done this way, because `dead_db()`
 can be called before plugins are loaded.

 For the third case, this is much trickier to handle, given that it could
 happen any time during page generation, from the very beginning of the
 header, right through to the end of the footer. I would imagine any custom
 handling for this would be very different to the handling of the other two
 cases, so I'm okay with a plugin having to have different handlers for
 different failures.

 (The extra scenario, as you mentioned, are uses that will never do
 `template_redirect`. These include wp-cron, admin-ajax, and anything that
 loads WP by calling wp-load.php directly. These cases are comfortably
 covered by `wp_die()` and `dead_db()`.)

--
Ticket URL: <https://core.trac.wordpress.org/ticket/27240#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform