Make WordPress Core

Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#22853 closed defect (bug) (wontfix)

Hyperdb redirects to wp-admin/install.php with no read servers up

Reported by: archon810's profile archon810 Owned by:
Milestone: Priority: normal
Severity: major Version: 3.4.2
Component: Database Keywords:
Focuses: Cc:


Hi folks. Apologies if the dev team doesn't consider HyperDB core WP (I do, since it's used by and is developed by core WP people).

Either way, I also filed this here, though none of the developers seem to be active on that support forum (hence this bug report to bring attention to it). If you choose to close this bug here, I at least appreciate if at least one of the core devs takes a look at the above url and comments there (matt, andy, ryan, mdawaffe, vnsavage).

I'm enabling hyperdb on a high-traffic website but during my testing found pretty shocking behavior in my opinion when a certain situation occurs.

Basically, when all db read servers are down, rather than showing the standard "Error establishing a database connection" page as you would expect, anyone visiting the site is immediately redirected to wp-admin/install.php. No matter if you're logged in or not, that's where you end up.

I kind of understand why it happens, but I'm terrified to think that rather than get a descriptive DB error page, users will be instead directed to a page that shows up during the very first WP install. Moreover, I'm not sure what would happen if they got to that page and the read server came back up in the meantime, then they submitted the form.

Is there a way to get hyperdb to error out when no read servers are available instead of having users deal with this unfriendly and potentially dangerous behavior?

To test, just set all read servers to 0 in the config or just shut down mysql on the hosts with read > 0.

Change History (5)

#1 @archon810
11 years ago

  • Cc admin@… added

#2 @vnsavage
11 years ago

  • Resolution set to wontfix
  • Status changed from new to closed


Thanks for the report. In general you can use the plugins trac: which would probably get you an answer faster.

HyperDB is meant to be as flexible as possible, allowing the usage of both multiple database servers per site and multiple database servers per table. In certain cases, the inability to connect to a certain table might be acceptable and could be handled in the code. For example, if we have a logging table that is on a separate dataset, for some users might not be acceptable to kill the whole site if the database servers for this dataset die.

The solution we have added for this case, which still keeps HyperDB flexible is a callback called "db_connection_error" which is called when HyperDB couldn't connect to a certain dataset. If you want to replicate the behavior without HyperDB and get the "Error establishing a database connection" when you can't connect to servers for a dataset, you can use the following code in db-config.php:

function wpdb_connection_error( $host, $port, $op, $tbl, $ds, $dbhname, $wpdb ) {
$wpdb->add_callback( 'wpdb_connection_error', 'db_connection_error' );

Closing the ticket as "wontfix".

Iliya Polihronov

#3 @SergeyBiryukov
11 years ago

  • Milestone Awaiting Review deleted

#4 @archon810
11 years ago

@vnsavage, I didn't know about a separate Trac for plugins, but in my defense I did start a post on HyperDB's plugin page.

Thanks for the fix - it makes sense to have a behavior like that, but considering my experience, I highly urge you to at least document this in the FAQ section of the plugin ( It is something that is pretty crucial to realize when jumping head first with this plugin and potentially very jarring for any big site in case their db goes down.

#5 @vnsavage
11 years ago

Yeah, that makes sense. I documented this behavior in the FAQ section.

Note: See TracTickets for help on using tickets.