WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#12041 closed defect (bug) (fixed)

wp-includes/wp-db.php WP_DEBUG constant

Reported by: wpmuguru Owned by: donncha
Milestone: MU 2.9.x Priority: normal
Severity: normal Version: 2.9.1
Component: Multisite Keywords:
Focuses: Cc:

Description

MU Trac Ticket: http://trac.mu.wordpress.org/ticket/1194

The use of WP_DEBUG constant changed from 2.8.6 to 2.9.x, which has caused a consistent new install problem. A new install for me dies because of this.

In 2.8.6 the code was:

if ( defined('WP_DEBUG') and WP_DEBUG == true )

$this->show_errors();

In 2.9.1 it is:

if ( WP_DEBUG )

$this->show_errors();

Can this be fixed so new installs work?

Thank you, David

Change History (11)

comment:1 wpmuguru4 years ago

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

This was being caused during the MU installation process when there was an error with the database (ex. user didn't have permissions to create tables).

Closing unless this is an issue with the WP install.

comment:2 dxjones4 years ago

  • Cc dxjones added
  • Resolution invalid deleted
  • Status changed from closed to reopened
  • Version set to 2.9.1

No, I think you are wrong wpmuguru.

In 2.9.1, the code tries to access WP_DEBUG without checking whether it is defined.
Since it is *not* defined, ... it fails with this error message:

Notice: Use of undefined constant WP_DEBUG - assumed 'WP_DEBUG' in /.../html/wp-includes/wp-db.php on line 370

comment:3 nacin4 years ago

  • Owner set to donncha
  • Status changed from reopened to assigned

This is related to #11881.

In plain WP, we removed a check for whether WP_DEBUG was defined in wp-db.php. The install script (which includes wp-db.php to be db aware without loading the rest of WP) has error_reporting(0), which suppresses everything anyway, so we didn't notice it. That's fixed in 3.0.

However, the MU installer doesn't bother with error_reporting at all, and your environment default probably includes E_NOTICE, hence you're seeing this notice (which would normally be suppressed throughout all of WP).

If there's a 2.9.1.2 (see also #12090), this might as well go in. (An undefined constant is assumed to be true, so $this->show_errors() is turned on even though it shouldn't be.) Assigning to donncha.

Simple fix is to add define('WP_DEBUG', false); to index-install.php before we include wp-db.php.

comment:4 wpmuguru4 years ago

(In [12922]) add WP_DEBUG define check in DB code, props dxjones, see #12041

comment:5 follow-up: wpmuguru4 years ago

Please leave this open. The above change was for WP trunk. If Donncha does a 2.9.2 for MU, this could be rolled in as well.

comment:6 in reply to: ↑ 5 nacin4 years ago

Replying to wpmuguru:

Please leave this open. The above change was for WP trunk. If Donncha does a 2.9.2 for MU, this could be rolled in as well.

I was leaving this open only for a possible 2.9.x MU release. The commit wasn't necessary because this problem shouldn't exist in trunk at all.

Whenever we manually become wpdb aware, we're first defining what we need, including WP_DEBUG. This was one of the two issues in #11881.

If we want wp-db.php to be able to stand on its own, then fine, but it requires wp_die() and a few others anyway. In setup-config.php we define ABSPATH, WPINC, WP_CONTENT_DIR, WP_DEBUG, and include load.php, functions.php, compat.php, and classes.php, before getting to wp-db.php later on when we want to check the connection.

comment:7 nacin4 years ago

  • Milestone changed from Unassigned to 3.0

I suggest we revert [12922].

comment:8 donncha4 years ago

I checked for WP_DEBUG (and also wp_die()) in http://trac.mu.wordpress.org/changeset/2071 in MU to fix this.

comment:9 automattor4 years ago

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

(In [13209]) Assume WP_DEBUG is defined in wpdb. Remove unnecessary constant() calls. Ensure DB_COLLATE defined as empty string doesn't override default Multisite collation. fixes #12041, see #11644

comment:10 nacin4 years ago

  • Milestone changed from 3.0 to Unassigned

We should probably create a "MU 2.9.x" for these.

comment:11 nacin4 years ago

  • Milestone changed from Unassigned to MU 2.9.x
Note: See TracTickets for help on using tickets.