Support

We cannot implement that functionality because the number of hosts where just trying to check if there’s a file outside the site root will immediately kill the application is far larger than the number of sites which use a wp-config.php file outside of the site root (and even that requires a bit of additional configuration).

We used to support that, as well as having less rigidly formatted config files. It wasn’t worth it. The problem I described was happening once every two weeks. What happened to you, however, has happened once in 12 years. Up until now nobody had reported it, even though we knew it’s theoretically possible. This should tell you immediately why it’s no longer supported 

Ultimately, this is mass distributed software. When there are mutually exclusive features we will implement the one that’s most common across the population of users. 

I can explore whether WordPress can tell us where wp-config.php is really stored and include it in the backup. I haven't found anything like that yet, but maybe the newly reorganized WP documentation may shed some light.

Creating a wp-config.php from scratch is risky. At best, I could warn you there is no wp-config.php in the restored site, and ask you if you want to create the default one – basically, run similar code to WP-CLI's. It's not a perfect solution, but probably better than giving up silently?

As for roles and users, this is all stored in the database and does not get modified in any way. I suspect that the problem you have may have to do with the wp-config.php file not connecting your site to the right database.

As I already told you, the wp-admin.php file has nothing to do with WordPress Roles and Capabilities as these are stored in the database.

As I already told you, the restoration script does not and cannot change your WordPress Roles or Capabilities in any way. The only thing it can do, as per the documentation, is optionally change only the email and password of a single user, if you select one.

The drop-down dialog is populated by looking at the #__usermeta table. This table is backed up and restored verbatim.  The rows with a meta_key of #__capabilities holds the roles of each user. We go through all users, looking for the administrator role. If these users also have a row with a meta_key of #__user_level and meta_value of 10 they are shown to you in the drop-down.

The Role to Capabilities assignment takes place in the #__options table. There's a row with option_name equal to wp_user_roles and an option_value which is a PHP serialized array, holding role IDs and the list of their capabilities. This table is backed up and restored verbatim.

Can WordPress actually connect to the database? Do you see the content in the frontend? If you change content in the original site, can you verify it does not change in the restored site i.e. the restored site is confirmed not to be reading data from the original site's database?

I have double-checked the process for moving wp-config.php outside the site's root. WordPress does not actually allow you to do that by itself. It will only load a wp-config.php file above the site's root if that folder does NOT contain the wp-settings.php file, i.e. it's a nested installation of WordPress sites. If the wp-settings.php file exists, as it should on a functional installation, WordPress will always look for wp-config.php in the site's root only.

This makes me wonder about your configuration.

Do you have two nested WordPress sites? If so, it would explain why you have a problem with Roles. You'd need to back them up separately.

If you do not have nested sites, you would have to use a trick to get wp-config.php to load from the root's parent directory. Since wp-config.php is not a configuration file per se –it just a regular .php file– you can exploit how PHP works. Changing it to something like this:

<?php include_once __DIR__ . '/../wp-config.php';

tells PHP to load a wp-config.php above the site root whenever WordPress or any plugin try to load the wp-config.php file in your site's root.

If you instead moved wp-settings.php as well, you have something that looks like WordPress, functions a lot like WordPress, but is not WordPress. That, I cannot help you with.

If you have merely changed the wp-config.php in your site's root to include the other file, yes, it is possible to restore the site. Replace the file in your site's root with a regular wp-config.php after extracting the backup archive, but before visiting  the/installation URL. Here's a minimal file that will do the trick:

<?php
define('DB_NAME', 'irrelevant');
define('DB_USER', 'irrelevant');
define('DB_PASSWORD', 'irrelevant');
define('DB_HOST', 'localhost');
define('DB_CHARSET', 'utf8');
define('DB_COLLATE', '');
define('AUTH_KEY',         'Xk;!X9n.Q6??#>oD#DtK:7{17??D(28L7J4JF_R^|BDwe1c~@ImOK53v(V2a)||F');
define('SECURE_AUTH_KEY',  'ms|s._~)4 ZQr1a_L$BP6@+-m)2bYIraq-ih)D^E=mlG((+,-gUZ|4[@d +/{R*i');
define('LOGGED_IN_KEY',    ' [b4!9+^uq:G/P4i;Rrdb-&:_xQ%k@=u^_$Rfh&#|!%2h~-X//6|ABTA:uQfK|ZS');
define('NONCE_KEY',        '>H2&ASYj;;Zym4^O_OZ74.5~?zkIp,Ocfx{7lPmx|*sPyu#M%Y~)o4]a>{ |,Obq');
define('AUTH_SALT',        'wdK>MqqF(0|oo7+>;5m0BtCs@R&z|6.z{{/$~Tp?F1xk7-0)qu:c]pGf$sJ]6X(X');
define('SECURE_AUTH_SALT', 'e$SGwNh3k}z}9>[l<9+*@6|.O[jn+Y$lbyp{BD=3FL,J1H$T|wg,&DX&H^<,}t>n');
define('LOGGED_IN_SALT',   '}$mAP%ZPjN*nf0O%u)*Xj7RbgR7151?+/&<I5e&c[C<DO1W9NkK6j:_6|n0Scs*g');
define('NONCE_SALT',       '/l*se,x:>Yz`[f#CL7IoG?zAXIU|v<Hb>dG^#ie Mw*(=40x_U$z4b>{0^|(a]XQ');
$table_prefix = 'wp_';
define('WP_DEBUG', false);
/* That's all, stop editing! Happy blogging. */
if ( !defined('ABSPATH') )
define('ABSPATH', dirname(__FILE__) . '/');
require_once(ABSPATH . 'wp-settings.php');

I have fixed not being able to proceed pas the Site Setup when an Administrator is not found.

We are not going to issue a warning about this issue because it's very rare, and we'd create a precedent that a warning must be issued for every way you can possibly break WordPress. Being WordPress, it can be broken in way too many ways for this to be practical.

We cannot backup your wp-config.php file if it's in an off-site root. I mean, we could, but this creates a lot of weird technical issues and does not help with the restoration since the file is still not where it should be to be taken into account.

Finally, and most importantly, there is at best no security impact from moving your wp-config.php file. The file must be readable for WordPress to function. The only attack you can incorrectly think it will save you from is a vulnerability which allows files in specific paths to be read verbatim. It won't actually save you. The attacker will try both possible locations. What about moving it completely off-site? You will still a wp-config.php in either the site root or its parent directory with an include() or require() to the correct file. So, big whoop, you slowed down the attacker by 15 seconds. You are still pwned.

The worst part is that moving your wp-config.php starts causing all sorts of problems to you which make it harder for you to manage your site. This might cause a security-relevant issue, or might cause you to neglect or delay updates to test things out which in its turn introduces a security-relevant issue. So, usually, doing this kind of moving files around ends up deteriorating your site's security instead of improving it.