Make WordPress Core

Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#16640 closed defect (bug) (fixed)

Blank page when db pass is incorrect

Reported by: rasheed's profile rasheed Owned by: westi's profile westi
Milestone: 3.1.1 Priority: normal
Severity: critical Version: 3.1
Component: Warnings/Notices Keywords: has-patch
Focuses: Cc:

Description

Hello

While installing a clean copy of wp-3.1 am trying to produce the error when the password at wp-config.php is incorrect.

For some reason it gives me a blank page.

I tried to make the same process with older version (3.0.5) and it worked fine.

At first i thought it could be related to my server configuration but another try at a different server gave me the same result (blank page).

is it a 3.1 bug or something else ? Can anyone try it from his end ?

Thanks

Attachments (3)

16640.patch (817 bytes) - added by SergeyBiryukov 13 years ago.
16640-fix.diff (729 bytes) - added by westi 13 years ago.
16440.diff (842 bytes) - added by ryan 13 years ago.
Revert death

Download all attachments as: .zip

Change History (28)

#1 @ocean90
13 years ago

Is there an error message when WP_DEBUG is true in your wp-config.php?

#2 follow-up: @nacin
13 years ago

  • Keywords reporter-feedback added
  • Severity changed from normal to critical

He's using setup-config.php I think.

You need to comment out error_reporting(0) or change it to -1 or E_ALL to see errors.

Bumping severity as this is bad, but I'm hesitant to blame core. Can be HTTP though.

#3 @SergeyBiryukov
13 years ago

Confirmed. Broken in [15808].

#4 in reply to: ↑ 2 @SergeyBiryukov
13 years ago

Replying to nacin:

He's using setup-config.php I think.

wp-config.php is already created, so it's actually wp-admin/install.php.

#5 @SergeyBiryukov
13 years ago

The patch restores 3.0.x behaviour. The error message is displayed by wp_die() later.

#6 @nacin
13 years ago

  • Milestone changed from Awaiting Review to 3.1.1

#7 @rasheed
13 years ago

When WP_DEBUG is true i got this error:

=====
Warning: mysql_connect() [function.mysql-connect]: Access denied for user 'rashedes_31final'@'localhost' (using password: YES) in /home/rashedes/public_html/wordpress/3-1-final/wp-includes/wp-db.php on line 1036

Error establishing a database connection

This either means that the username and password information in your wp-config.php file is incorrect or we can't contact the database server at localhost. This could mean your host's database server is down.

  • 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?

If you're unsure what these terms mean you should probably contact your host. If you still need help you can always visit the WordPress Support Forums.
=====

#8 @rasheed
13 years ago

  • Keywords reporter-feedback removed
  • Owner set to rasheed
  • Status changed from new to reviewing

#9 @SergeyBiryukov
13 years ago

  • Keywords has-patch added

#10 @ryan
13 years ago

  • Milestone changed from 3.1.1 to 3.2

Punting to 3.2 per bug scrub.

#11 @ryan
13 years ago

  • Milestone changed from 3.2 to 3.1.1

Oops, punted the wrong ticket.

#12 @westi
13 years ago

  • Owner changed from rasheed to westi

#13 @scribu
13 years ago

  • Summary changed from Blank page to Blank page when db pass is incorrect

#14 @westi
13 years ago

I think the correct fix here is to expand this check:

if ( defined( 'WP_SETUP_CONFIG' ) ) 

to include WP_INSTALLING

As install.php will then handle as setup-config.php does.

Last edited 13 years ago by westi (previous) (diff)

@westi
13 years ago

#15 @ryan
13 years ago

Tested. Works for me and looks good.

#16 @ryan
13 years ago

  • Resolution set to fixed
  • Status changed from reviewing to closed

(In [17536]) Don't die for failed db connects during install. Props westi. fixes #16640 for trunk

#17 @ryan
13 years ago

(In [17537]) Don't die for failed db connects during install. Props westi. fixes #16640 for 3.1

#18 @ryan
13 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

#19 @ryan
13 years ago

There are other issues. dead_db() is no longer called, meaning we get the detailed message instead of the terse message for front page loads and do not look for the custom db-error.php file.

#20 @ryan
13 years ago

db_connect() could call dead_db(), but dead_db() is an external function. wpdb cannot rely on it. That gets us into some refactoring, which I'd rather not do for 3.1.1. I'm thinking we should revert the die.

Last edited 13 years ago by ryan (previous) (diff)

@ryan
13 years ago

Revert death

#21 @ryan
13 years ago

The front page will be blank if WP_DEBUG is not set. Revert seems the way to go.

#22 follow-up: @SergeyBiryukov
13 years ago

Wouldn't $this->set_charset() and $this->select() be inappropriate if $this->dbh is false? I guess it's safe to return, as in 16640.patch.

Last edited 13 years ago by SergeyBiryukov (previous) (diff)

#23 @ryan
13 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

(In [17546]) Don't die inside db_connect() if connection fails. Let dead_db() handle it. fixes #16640 for trunk

#24 @ryan
13 years ago

(In [17547]) Don't die inside db_connect() if connection fails. Let dead_db() handle it. fixes #16640 for 3.1

#25 in reply to: ↑ 22 @ryan
13 years ago

Replying to SergeyBiryukov:

Wouldn't $this->set_charset() and $this->select() be inappropriate if $this->dbh is false? I guess it's safe to return, as in 16640.patch.

I added the return, retested, and committed.

Note: See TracTickets for help on using tickets.