SequelPro button doesn’t use the configured “database name” setting (DB_NAME), it always uses local… actually it uses the setting in the sites.json file.
Blueprint save saves all databases.
Blueprint save honours the setting in sites.json
Blueprint install doesn’t use the setting in the exported local-site.json file.
So installing from blueprint - ignores DB_NAME, or local-site.json setting and loads all data into “local” and looses the setting. It then overwrites the wp-config setting, with “local”.
(It would be nice if the database name was set somewhere other then wp_config)
(It would be extra nice if Lbf left site files well alone, wp-config could/should use ENV variables.
We have a per-site database and a large shared templates/images database. To make it more interesting - multiple versions of both.
I have set up one LbF ‘site’ specifically as a shared database, the other sites can get to their shared database by specifying the host and port. Very workable. (even if they are both called “local”). So now we have one server and one database per site, and one server and one database per templates ‘site’ (all called local).
Then I discover that the name change works, if you manually rename the database and hack the sites.json file, all good!
This leaves four issues.
Handing the setup to another developer via a blueprint doesn’t honour/restore the setting hacked into site.json and saved in the blueprint in local-site.json Specifically the import process loads the data into a new database called “local”, instead of the name given in the local-sites.json file that came with the blueprint. (Surely other settings such as user/pass are honoured.)
It would make sense to have multiple versions of the shared database on the same server instance under different database names. This allows versions to be created via the “duplicate” database command (Sequel Pro) within a single server, rather than via import export.
the wp-config.php file is not needed.
In summary, the easiest and most useful fix would be issue 1 above.