Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

From what I can see, dbDelta() is designed to suppress database errors that occur during its operation. Generally speaking, this seems to be the case, but New Relic is still reporting MysqlErrors from the function. The exact error message is of the format:

MysqlError: Table 'xxx.wp_yyy_posts' doesn't exist

From dbDelta() in /wp-admin/includes/upgrade.php, we have:

// Fetch the table column structure from the database
$suppress = $wpdb->suppress_errors();
$tablefields = $wpdb->get_results("DESCRIBE {$table};");
$wpdb->suppress_errors( $suppress );

It appears that suppress_errors() is doing it's job and preventing error messages from being echoed to the screen. However, it also appears that these errors are not actually being handled, as shown by our New Relic installation.

Understandably, we would like to eliminate all possible sources of errors on our production app so that we can accurately use the New Relic tool for tracking actual error rates and associate them with New Relic's reporting tools.

Is there a compelling reason why dbDelta() doesn't handle this error? The only reason I can think of is that this is a deliberate design decision to facilitate development and bug-fixing. It could be hard for a developer to track down issues when dbDelta() completely suppresses any errors. Of course, a new parameter/option could be introduced to specify whether or not this automatic error suppression should occur (which would make catching the MysqlError a no-brainer).

This becomes a bit of an issue in our case in which every single call to install_blog() generates this error. Since we are running a large multisite installation, every time we create a new blog, an error is generated.

share|improve this question

1 Answer 1

DB errors of that type should only appear on the UI if DB_DEBUG is enabled. On a production system that should be disabled. You should find that setting in the wp-config.php file for your WP install.

You can try to manually force the errors to "hide" by resetting the EZSQL_ERROR global. This is my personal hack and probably not recommended or best practice for working with dbDelta:

 * Update the data structures on new db versions.
 * @global object $wpdb
 * @param type $sql
 * @param type $table_name
 * @return string
function dbupdater($sql,$table_name) {
    global $wpdb;
    $retval = ( $wpdb->get_var("SHOW TABLES LIKE '$table_name'") != $table_name ) ? 'new' : 'updated';

    require_once(ABSPATH . 'wp-admin/includes/upgrade.php');
    $were_showing_errors = $wpdb->show_errors;
    global $EZSQL_ERROR;
    if ( $were_showing_errors ) {

    return $retval;
share|improve this answer
Thanks for your answer! Unfortunately, the issue isn't related to errors showing or not showing. Rather, the issue is that Wordpress is not catching the related database error (regardless of whether or not it is displayed to the end user). Put succinctly, Wordpress is generating errors that appear in our error log that are not really true errors. They are (I assume), side-effects of a correctly functioning dbDelta() function. This causes our reporting systems to inaccurately conclude that there are issues with our production environment, since it is consistently generating errors. –  rinogo Apr 21 at 22:31
Good point. Part of the issue is the construct of using DESCRIBE {table} when table does not exist. Before executing the DESCRIBE SQL statement the MySQL engine should be queried to see if the table exists in the first place. The issue is not that a warning/error is not being caught it is that the construct is generating a warning/error in the first place. –  Charleston Software Associates Apr 22 at 16:58
Either way, sounds like a patch might be in order! :P –  rinogo Apr 22 at 18:50

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.