Do I need to edit db_user when migrating Wordpress from localhost to a live server?

Question

WordPress

Hello everyone I

have a fresh installation of Wordpress on the server I
have a backup of the local version (made by the Updraft plugin)

I'm going to do this:
1. paste the backup on ftp
2. restore this backup from a fresh wordpress,
3. open wp_config and add it there

define('WP_SITEURL', 'http://123123.ngrok.io/wordpress'); 
define('WP_HOME', WP_SITEURL);

4. Go to the admin panel and use the Better Search And Replace plugin to change the old link in the entire database to the new one

. But, the question is:
1. After restoring the backup, how do I need to fix wp_config so that everything works? After all, for sure - the matter will not be limited to adding two lines. The settings in the local config are very basic.
2. In the next folder on the server there is another working WordPress installation. What is the probability that it will break after restoring from a backup on an empty wordpress? The base is called differently, but maybe you should wait for a catch somewhere?

Thank you for your attention.

The current settings in wp_config, which is sewn into the backup, are as follows

define('WP_SITEURL', 'http://123123.ngrok.io/wordpress'); 
define('WP_HOME', WP_SITEURL);

define( 'DB_NAME', 'wordpress' );


define( 'DB_USER', 'root' );


define( 'DB_PASSWORD', '' );


define( 'DB_HOST', 'localhost' );


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', false );


if ( ! defined( 'ABSPATH' ) ) {
  define( 'ABSPATH', dirname( __FILE__ ) . '/' );
}

require_once( ABSPATH . 'wp-settings.php' );

And on the server of a fresh WordPress donor, the config is as follows:

define( 'DB_NAME', 'Name___3' );


define( 'DB_USER', 'Name___3' );


define( 'DB_PASSWORD', 'Name2bo2bo' );


define( 'DB_HOST', 'localhost' );


define( 'DB_CHARSET', 'utf8' );


define( 'DB_COLLATE', '' );


define( 'AUTH_KEY',         '___________' );
define( 'SECURE_AUTH_KEY',  '___________' );
define( 'LOGGED_IN_KEY',    '___________' );
define( 'NONCE_KEY',        '___________' );
define( 'AUTH_SALT',        '___________' );
define( 'SECURE_AUTH_SALT', '___________' );
define( 'LOGGED_IN_SALT',   '___________' );
define( 'NONCE_SALT',       '___________' );

$table_prefix = 'wp_';


define( 'WP_DEBUG', false );

if ( ! defined( 'ABSPATH' ) ) {
  define( 'ABSPATH', __DIR__ . '/' );
}


require_once ABSPATH . 'wp-settings.php';

Answer 1

Isn't it easier to install Akeeba Backup on the locale, and transfer your project from locale to production without hemorrhoids? Akeeba also sometimes blunts with paths, but does everything automatically and usually without jambs.