Installer tries to create nonce before options table exists

[nullvariable]

When creating a new install via wp-admin/install.php the following errors occur:

WordPress database error: [Table '....wp_options' doesn't exist]
INSERT INTO wp_options (option_name, option_value, autoload) ....

WordPress database error: [Table '....wp_options' doesn't exist]
INSERT INTO wp_options (option_name, option_value, autoload) ....

This error occurs with the following conditions:

• wp-config.php created by user instead of installer
• all salts and keys in wp-config are identical
• database has not been installed

[nullvariable]

Looks like this is caused by localizing stuff for the api.

wp-includes/script-loader.php line 510 creates a nonce:

'nonce'         => wp_create_nonce( 'wp_rest' ),

[nullvariable]

patch

[nullvariable]

I added a check for WP_INSTALLING when the nonce is created to skip generating one during install

[nullvariable]

to be more specific on the error conditions, this only seems to occur if you leave the 'put your unique phrase here' string in your wp-config (or have duplicate keys/salts). pluggable.php's wp_salt function will try to generate unique keys and salts for you but fails because the database hasn't been created yet.

it may be that wp_salt should be updated to check for WP_INSTALLING also

[pento]

I'm not sure the best way to fix this - checking WP_INSTALLING limits the future possibility of using the REST API during installation, which I'm not wild about.

This is pretty edge-casey, let's investigate it further for a point release.

[nullvariable]

@pento this fix wouldn't prevent the API from working during install, just prevents it from creating a nonce during install.

Edit: more specifically the patch I attached modifies the script localization to exclude the nonce if WP_INSTALLING

[rmccue]

Replying to pento:

I'm not sure the best way to fix this - checking WP_INSTALLING limits the future possibility of using the REST API during installation, which I'm not wild about.

The nonce is only used for authentication checks in any case, which doesn't make sense if you don't actually have any users to authenticate against. If we add things in the installer in the future, those will need some other way of authenticating.

The way the patch handles this makes sense to me (although, no need for parens around the constant).

[nullvariable]

updated patch to remove extra parentheses

[pento]

@nullvariable: I haven't been able to reproduce this error.

Could you please upload a copy of the wp-config.php you're using that causes this?

Have the database user and database name defined in your wp-config.php been created in MySQL?

Are there any other tables in that database using the same table prefix as defined in your wp-config.php?

[nullvariable]

Replying to pento:

@nullvariable: I haven't been able to reproduce this error.

Could you please upload a copy of the wp-config.php you're using that causes this?

<?php
define('WP_HOME', 'http://wordpress.dev');
define('WP_SITEURL', 'http://wordpress.dev');
define('DB_NAME', 'wordpress');
define('DB_USER', 'root');
define('DB_PASSWORD', 'root');
define('DB_HOST', 'db');
define('DB_CHARSET', 'utf8');
define('DB_COLLATE', '');
define('AUTH_KEY',         'put your unique phrase here');
define('SECURE_AUTH_KEY',  'put your unique phrase here');
define('LOGGED_IN_KEY',    'put your unique phrase here');
define('NONCE_KEY',        'put your unique phrase here');
define('AUTH_SALT',        'put your unique phrase here');
define('SECURE_AUTH_SALT', 'put your unique phrase here');
define('LOGGED_IN_SALT',   'put your unique phrase here');
define('NONCE_SALT',       'put your unique phrase here');
$table_prefix  = 'wp_';
define('WP_DEBUG', true);

Have the database user and database name defined in your wp-config.php been created in MySQL?

Yes

Are there any other tables in that database using the same table prefix as defined in your wp-config.php?

no, brand new database, no tables.

[pento]

Thanks @nullvariable, I was able to reproduce it with that. :-) Could you try out 39047.diff​? Instead of removing the nonce through the entire installation process, it only happens while the tables don't exist (which is a reasonable proxy for determining when the REST API is able to be used, too).

[nullvariable]

@pento that solves it in my testing. Agreed on testing to see if the table exists, should solve the problem with the least impact.

[ocean90]

39047.diff​ will produce a PHP fatal error if SCRIPT_DEBUG is false because wp_installing() isn't available in load-scripts.php.

[dd32]

Replying to ocean90:

39047.diff​ will produce a PHP fatal error if SCRIPT_DEBUG is false because wp_installing() isn't available in load-scripts.php.

Yeah, the conditional needs a did_action( 'init' ) && prepended to it at a minimum.

I don't like the direct SQL here, or anything which triggers a SQL. Can this scenario be handled by checking that the underlying values that nonces rely upon is already setup maybe?

[ocean90]

#39440 was marked as a duplicate.

[rmccue]

The underlying reason for the query is that wp_salt() attempts to save the salt to the DB when it's default ("put your unique phrase here"), but the table does not yet exist. The error doesn't occur when the salts are set manually/in your wp-config.php, since it doesn't need to write to the DB.

Detecting this isn't super easy, as you can't know whether the salt will be loaded from a constant or the DB beforehand. In addition, changing that function is a bit tough, because it's pluggable.

I remain convinced that what I said still holds:

The nonce is only used for authentication checks in any case, which doesn't make sense if you don't actually have any users to authenticate against. If we add things in the installer in the future, those will need some other way of authenticating.

I'd say we still use wp_installing().

Replying to ocean90:

39047.diff​ will produce a PHP fatal error if SCRIPT_DEBUG is false because wp_installing() isn't available in load-scripts.php.

load-scripts.php isn't used during installation, as wp_print_scripts() is called directly rather than via print_footer_scripts. (This actually might already fail from calling wp_create_nonce, which isn't stubbed...; will investigate.)

[rmccue]

Replying to rmccue:

load-scripts.php isn't used during installation, as wp_print_scripts() is called directly rather than via print_footer_scripts. (This actually might already fail from calling wp_create_nonce, which isn't stubbed...; will investigate.)

As it turns out, the did_action( 'init' ) && already handles this, so it's perfectly safe to call wp_installing() (and wp_create_nonce()) inside the localisation.

[rmccue]

39047-2.patch, but using the function instead of the constant

[rachelbaker]

@ocean90 @pento @dd32 Any objections to Ryan's approach in 39047.2.diff​?

[dd32]

Using wp_installing() seems okay, but it should be paired with a multisite check I believe - installing is truthful during a new site creation, but the salts are network wide IIRC.

wp_installing && ! is_multisite() would be correct I think.

[rmccue]

Add multisite check

[rmccue]

Updated patch to include the check.

@pento Any final thoughts before this goes in? Speak now, or forever hold your peace. :)

[pento]

Get to da choppa.

[rmccue]

In 39684:

Upgrade/Install: Avoid creating nonce during installation.

When installing and using database-saved salts, wp_create_nonce() causes database errors as wp_salt() attempts to insert into the not-yet-created options table. Since authentication isn't available during installation, we can safely skip creating a nonce.

Props nullvariable, pento, dd32.
Fixes #39047.

[dd32]

In 39697:

Upgrade/Install: Avoid creating nonce during installation.

When installing and using database-saved salts, wp_create_nonce() causes database errors as wp_salt() attempts to insert into the not-yet-created options table. Since authentication isn't available during installation, we can safely skip creating a nonce.

Props nullvariable, pento, dd32, rmccue.
Merges [39684] to the 4.7 branch.
Fixes #39047.