WordPress.org

Make WordPress Core

Opened 8 years ago

Closed 8 years ago

#2544 closed defect (bug) (fixed)

Running setup-config.php?step=2 (no wp-config.php) produces a 'Headers already sent' error

Reported by: apidevlab Owned by: davidhouse
Milestone: 2.1 Priority: normal
Severity: normal Version: 2.0.1
Component: General Keywords: wp-db.php bg|has-patch bg|commit
Focuses: Cc:

Description

Running the install script with wp-config.php not present, setup-config.php properly detects the missing file, and offers to create one. After filling in the necessary entries for hostname, user, password, database, and "submit"ing the data, setup-config.php fails at step 2 with this error.

Warning: Cannot modify header information - headers already sent by (output started at /storage/Debian/wordpress/wp-admin/setup-config.php:22) in /storage/Debian/wordpress/wp-includes/wp-db.php on line 308

This error is present in a 'clean' install of 2.0.1 and has been 'worked around' by commenting the following lines:

header( 'Content-Type: text/html; charset=utf-8');
<h1 id="logo"><img alt="WordPress" src="http://static.wordpress.org/logo.png" /></h1>

More in this thread: http://wordpress.org/support/topic/64003

Attachments (1)

2544.diff (1.3 KB) - added by davidhouse 8 years ago.

Download all attachments as: .zip

Change History (14)

comment:1 apidevlab8 years ago

Just looking again and see the header is declared twice:

header('Content-Type: text/html; charset=utf-8');
echo <<<HEAD
<!DOCTYPE html PUBLIC "-W3CDTD XHTML 1.0 TransitionalEN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>

<title>SkratchPad &rsaquo; Error</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<style media="screen" type="text/css">

comment:2 davidhouse8 years ago

Yes, it's normal to both send an HTTP header and have said header in an HTML meta tag.

comment:3 davidhouse8 years ago

  • Owner changed from anonymous to davidhouse
  • Status changed from new to assigned

davidhouse8 years ago

comment:4 davidhouse8 years ago

  • Keywords bg|has-patch added

Try that for size.

comment:5 apidevlab8 years ago

  • Resolution set to worksforme
  • Status changed from assigned to closed

Fixed for me. Patch worked fine.

comment:6 davidhouse8 years ago

  • Resolution worksforme deleted
  • Status changed from closed to reopened

Thanks for your eagerness, but "worksforme" is for closing tickets that don't appear to be valid, i.e. no-one can replicate them. People tend to write patches then upload them onto bugs, which then eventually filter through into the core. When that is done (once the proposed code moves into the core), we then close the bug.

Sorry about the confusion.

comment:7 davidhouse8 years ago

  • Keywords bg|commit added

On the other hand, now we've got verification, I'll push it for commit.

comment:8 apidevlab8 years ago

Not to worry at all, it does seem to work.

Afraid I'm pretty new to SVN so still finding my feet. I'll see if the codex has any info I can read up on the process on here. Thanks for the help.

comment:9 davidhouse8 years ago

Allow me to explain the bug process.

1) User finds a bug
2) User asks around to make sure it's actually a bug, perhaps posts to the testers list
3) User makes a ticket on trac (this site, trac.wordpress.org)
4) Various code monkeys find the ticket, test it does actually exist
5) Someone writes a patch
6) That person uploads the patch using the 'Attach file' button
7) Someone else verifies the patch works
8) A committor (one of Matt Mullenweg or Ryan Boren) comes along and 'commits' the patch: changes the core code in our svn repository to include the patch that someone coded back in stage 5.
9) Bug is closed with 'fixed'.

comment:10 davidhouse8 years ago

That was horribly formatted, let me try again.

  1. User finds a bug
  2. User asks around to make sure it's actually a bug, perhaps posts to the testers list
  3. User makes a ticket on trac (this site, trac.wordpress.org)
  4. Various code monkeys find the ticket, test it does actually exist
  5. Someone writes a patch
  6. That person uploads the patch using the 'Attach file' button
  7. Someone else verifies the patch works
  8. A committor (one of Matt Mullenweg or Ryan Boren) comes along and 'commits' the patch: changes the core code in our svn repository to include the patch that someone coded back in stage 5.
  9. Bug is closed with 'fixed'.

comment:11 MichaelH8 years ago

David's description of the bug process added to Codex at:

Submitting_Bugs, The bug reporting and resolution process

comment:12 ryan8 years ago

  • Milestone set to 2.1

comment:13 ryan8 years ago

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

(In [3643]) setup-config fix from David House. fixes #2544

Note: See TracTickets for help on using tickets.