Make WordPress Core

Opened 9 years ago

Closed 9 years ago

#33395 closed defect (bug) (fixed)

Pass $allow_bail to fallback attempt in $wpdb->db_connect

Reported by: bobbywalters's profile bobbywalters Owned by: chriscct7's profile chriscct7
Milestone: 4.4 Priority: normal
Severity: normal Version: 3.9
Component: Database Keywords: needs-patch
Focuses: Cc:

Description

When a database connection can not be established and a fallback call is attempted the value of $allow_bail is not passed to the second call of db_connect. This means the fallback attempt will always bail.

This is the line of concern:
https://core.trac.wordpress.org/browser/tags/4.2.4/src/wp-includes/wp-db.php#L1468

Changing from:

if ( $attempt_fallback ) {
	$this->use_mysqli = false;
	$this->db_connect();
}

to

if ( $attempt_fallback ) {
	$this->use_mysqli = false;
	$this->db_connect( $allow_bail );
}

Will honor the $allow_bail value from the original call to be passed to the fallback attempt if it is necessary.

A test scenario is:

  1. Verify the database is NOT running so all connection attempts fail.
  2. A sample script PHP script that would verify the $allow_bail flag is passed along to the fallback attempt:
<?php
define('SHORTINIT', true);
define('WP_DEBUG', true); // triggers $wpdb->show_errors()
define('WP_SETUP_CONFIG', true); // prevents db_connect() call within new wpdb(...)

require 'wp-config.php';

global $wpdb;
echo "Calling wpdb->db_connect( false )...\n";
$wpdb->db_connect( false );
echo "wpdb->bail() was not called because you can see me!\n";

A work around is possible by calling

$wpdb->hide_errors();

or ensuring WP_DEBUG is not true (calling hide_errors() is safer since you can't undefine a constant) prior to

$wpdb->db_connect();

but this goes further down the error handling path than it needs to.

I can provide additional information if necessary. Thanks in advance for taking a look at this.

Change History (8)

#1 @chriscct7
9 years ago

  • Keywords needs-patch added
  • Version changed from 4.2.4 to 3.9

Introduced in 3.9 in [27935]

#2 follow-up: @chriscct7
9 years ago

  • Owner set to chriscct7
  • Status changed from new to assigned

Your proposed fix looks good. 4.3 goes out tomorrow, but once the 4.4 branch is setup, I'll go ahead and write the patch file for this

Last edited 9 years ago by chriscct7 (previous) (diff)

#3 @chriscct7
9 years ago

  • Milestone changed from Awaiting Review to Future Release

#4 in reply to: ↑ 2 @bobbywalters
9 years ago

Replying to chriscct7:

Your proposed fix looks good. 4.3 goes out tomorrow, but once the 4.4 branch is setup, I'll go ahead and write the patch file for this

Sounds good. Thanks for the quick response.

#5 @chriscct7
9 years ago

  • Milestone changed from Future Release to 4.4

#6 @wonderboymusic
9 years ago

  • Milestone changed from 4.4 to Future Release

move back if a patch materializes

#7 @chriscct7
9 years ago

@wonderboymusic, the patch while not in a patch file is in the description of the ticket itself. I can take care of making it into a formal patch file.

#8 @johnbillion
9 years ago

  • Milestone changed from Future Release to 4.4
  • Resolution set to fixed
  • Status changed from assigned to closed
Note: See TracTickets for help on using tickets.