Currently it's impossible to install a new environment with existing configuration. Possible workarounds are:
If site:install would support a --config-directory option, that would make the install a lot easier.
Edit: Not yet read this through, but probably related and possibly a blocker for this issue. I'll read it later and update this issue accordingly.
https://www.drupal.org/node/1613424
Alright, that issue is like a black hole. I'm still not sure where that stands today.
It seems that config_installer should support installs with Drush and a config sync folder setup in settings.php. Though, Drupal Console is not mentioned in that issue. I'm not sure if that solution is Drush specific or if this is just a config_installer thing and automatically supported by DC?
Still, using config_installer sounds like a workaround, right? Shouldn't DC support config imports on install natively? And if so, is this something that we should be able to work on ATM? Or does it depend on above issue to be resolved? I'm not sure, at all.
The config_installer profile is deprecated AFAIK, it was an experiment, but now drush can do what's needed.
There are basically two use cases of reusing an existing configuration for a new site:
Use the config as a template for similar but distinct sites, that is ignoring the UUIDs.
This can be done by creating a new profile with drupal console like this:
ENABLED_MODULES="$($DRUSH pm-list --type=module --status=enabled --pipe | tr '\n' ',')"
ENABLED_THEMES="$($DRUSH pm-list --type=theme --status=enabled --pipe | tr '\n' ',')"
$DRUPAL_CONSOLE generate:profile \
--profile="$PROFILE_TITLE" \
--machine-name="$PROFILE_MACHINE_NAME" \
--description="Drupal installation profile for $PROFILE_TITLE" \
--dependencies=$ENABLED_MODULES \
--themes=$ENABLED_THEMES \
--no-interaction
cp -a "${WEB_ROOT}/profiles/$PROFILE_MACHINE_NAME" "$PWD"
And export the template config under config/install in the profile directory, ignoring the UUIDs, as suggested in https://www.drupal.org/docs/8/creating-distributions/how-to-write-a-drupal-8-installation-profile in the "Configuration" section.
$DRUPAL_CONSOLE config:export --directory="$PWD/$PROFILE_MACHINE_NAME/config/install" --remove-uuid --remove-config-hash
rm "$PWD/$PROFILE_MACHINE_NAME/config/install/core.extension.yml"
Note that core.extension.yml needs to go because the info about the enabled extensions is in the profile now, passed with --dependencies and --themes (after #3092 gets fixed).
Importing the config at install time from the config/install dir in the profile seems to work with no special treatments:
$DRUSH --verbose --yes \
site-install \
--db-su=root \
--db-su-pw="$MYSQL_ROOT_PASSWD" \
--db-url="mysql://${DB_USER}:${DB_PASS}@localhost/${DB_NAME}" \
--site-name="$SITE_NAME" \
--site-mail="$SITE_MAIL" \
--account-name="$ACCOUNT_NAME" \
--account-pass="$ACCOUNT_PASS" \
--account-mail="$ACCOUNT_MAIL" \
"$PROFILE_MACHINE_NAME" \
Recreate the exact same site from an exported configuration
That is preserving the UUIDs of the entities, this can be done using the --config-dir option of drush site-install (NOTE the option description only shows up if the Drupal root directory used by drush contains Drupal 8 or greater), in this case drush will first use the minimal profile and then it will import the configuration, see:
https://github.com/drush-ops/drush/blob/master/lib/Drush/Commands/core/SiteInstallCommands.php#L121
and
https://github.com/drush-ops/drush/blob/master/lib/Drush/Commands/core/SiteInstallCommands.php#L139
When using this mechanism drush ignores the profile name passed on the command line, so I've seen people using the config_installer string as a placeholder, but note that this has nothing to do with the config_installer module/profile.
So I think 1. can be done with drupal console, while 2. cannot be done yet in drupal console, but you can still use drush for that.
I intended to write a blog post on these matters, if the info here is clear enough I might polish it a little bit and post it on Drupal Planet, what do you think?
Ciao,
Antonio
Hi @ao2! Thanks for the thorough explanation, clears up a lot! 馃憤 We're looking for option 2, where we are instantiating new environments for specific projects on the fly. I'll try to find some time soon to try out your instructions above.
I don't see any reason to assume config_installer in contrib is deprecated. Its actually being actively maintained. It does however currently work for drush only.
It has its own installer task which ends up not getting the form state setup by the SiteInstallCommand. Drush actually wouldn't work either but Alex pulls the values out of drush_get_option() directly to work around that. As far as I know there isn't such a simple hack for drupal-console since $input is injected everywhere and not available globally so some sort of hackery is going to have to happen to for it to work with drupal-console.
They are actually working on getting this kind of functionality into core:
In that case it would be nice to have the above mentioned option --config-directory.
Having this option would allow for the there mentioned config/sync to not have to be in the webroot (in the profile dir), after that functionality is in core.
It also looks like this would make it easy to implement here. If i understand it correctly, as the site::install command would only have to put the config-dir value into the settings.php before running the normal install part.
I did some testing and if the above mentioned patch makes it into core, supporting installation from existing config is as easy as adding something along the following lines to runInstaller()
$settings['config_install'] = TRUE;
$settings['profile_sync'] = $config_dir;
@nvaken Since 1.7.0 we have a new feature https://weknowinc.com/blog/how-install-drupal-8-existing-configuration. I think, this issue can be closed. Feel free to reopen it.
Most helpful comment
The
config_installerprofile is deprecated AFAIK, it was an experiment, but nowdrushcan do what's needed.There are basically two use cases of reusing an existing configuration for a new site:
Use the config as a template for similar but distinct sites, that is ignoring the UUIDs.
This can be done by creating a new profile with drupal console like this:
And export the template config under
config/installin the profile directory, ignoring the UUIDs, as suggested in https://www.drupal.org/docs/8/creating-distributions/how-to-write-a-drupal-8-installation-profile in the "Configuration" section.Note that
core.extension.ymlneeds to go because the info about the enabled extensions is in the profile now, passed with--dependenciesand--themes(after #3092 gets fixed).Importing the config at install time from the
config/installdir in the profile seems to work with no special treatments:Recreate the exact same site from an exported configuration
That is preserving the UUIDs of the entities, this can be done using the
--config-diroption ofdrush site-install(NOTE the option description only shows up if the Drupal root directory used bydrushcontains Drupal 8 or greater), in this casedrushwill first use theminimalprofile and then it will import the configuration, see:https://github.com/drush-ops/drush/blob/master/lib/Drush/Commands/core/SiteInstallCommands.php#L121
and
https://github.com/drush-ops/drush/blob/master/lib/Drush/Commands/core/SiteInstallCommands.php#L139
When using this mechanism
drushignores the profile name passed on the command line, so I've seen people using theconfig_installerstring as a placeholder, but note that this has nothing to do with theconfig_installermodule/profile.So I think 1. can be done with drupal console, while 2. cannot be done yet in drupal console, but you can still use
drushfor that.I intended to write a blog post on these matters, if the info here is clear enough I might polish it a little bit and post it on Drupal Planet, what do you think?
Ciao,
Antonio