wp-includes/wp-db.php WP_DEBUG constant

[wpmuguru]

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

[wpmuguru]

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.

[dxjones]

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

[nacin]

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.

[wpmuguru]

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

[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.

[nacin]

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.

[nacin]

I suggest we revert [12922].

[donncha]

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

[automattor]

(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

[nacin]

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