Install a site from config if the config directory is set in settings.php

Triggering bots.

+++ b/core/includes/install.core.inc
@@ -1528,16 +1529,24 @@ function _install_get_version_info($version) {
+  }
   // If the profile has a config/sync directory copy the information to the
   // install_state global.
-  if (!empty($install_state['profile_info']['config_install_path'])) {

I think this could be an else?

+++ b/core/includes/install.core.inc
@@ -1528,16 +1529,24 @@ function _install_get_version_info($version) {
+  if (!empty($config_directories[CONFIG_SYNC_DIRECTORY])) {
+    $sync = new FileStorage($config_directories[CONFIG_SYNC_DIRECTORY]);
+    if ($sync->exists('system.site')) {
+      $install_state['config_install_path'] = $config_directories[CONFIG_SYNC_DIRECTORY];
+      $install_state['config']['system.site'] = $sync->read('system.site');
+    }
+  }

Doing this in install_load_profile feels super odd. So here's the interesting thing - what happens if the install profile the user is in the process of choosing is different to the install profile in configuration. I think what would be better is that when there is existing configuration the option to use it for an install appears on the profile selection form as this needs to be decided then.

Turns out that I think a small UI is actually worth it. Rather than polluting the settings.php with a new setting that only is used during installs we can add an install state parameter to do this. Drush/Console can then set this when installing depending on a flag and they can work out the correct profile to use from config too.

Test still pending.

Here's test coverage.

Patch addresses #13 and adds a test for this case.

Adding screenshot to summary. Shows that we need to add word-wrap: break-word; somewhere :(

Fixing the word-break issue.

The patch looks great. It is a small feature but it is much needed. I just have on concern about the UI change. For a normal user, it can be confusing as first three options are installing profiles and last one states 'Use existing configuration'. I think it should state 'Use existing configuration to install %profile'. Adding UX review tag to loop in UX team.

I know this is an active initiative but should we not need a release and product manager review here after all this is affecting the way we install the product?

As mentioned in IS we are going to update https://www.drupal.org/node/2897299 on commit but IMO this should have a separate change record as well as stated above it is affecting the way we install Drupal.

+++ b/core/lib/Drupal/Core/Installer/Form/SelectProfileForm.php
@@ -78,6 +87,27 @@ public function buildForm(array $form, FormStateInterface $form_state, $install_
+        // @todo https://www.drupal.org/project/drupal/issues/2982052 Remove

s/Remove/removes.

A UX team review was requested and so we looked at this patch on today's UX meeting, which will eventually be at https://www.youtube.com/watch?v=n4zlDxVVnnQ. The demo started at about an hour in and was pretty painful since Drush wasn't working. :D

- Big+1 for the feature itself. It's a very common use case to have a new developer come onto a project, for example, and to want to get them up and running with a current copy of the code + config.
- The new entry in the installer is a bit 😱😱😱...that directory name is frigging scary, and the wording there is extremely technical. But one nice thing is it only shows up if you're in this exact situation, meaning you deliberately put a bunch of config files into your sync directory and started installing Drupal from scratch. (e.g. you're a "user 1" type.)
- One suggestion to counteract that was to maybe do the same thing that we do with the Umami selection, and initially show much smaller help text (maybe something like "Install the Profile profile from pre-existing configuration.") and then only show the long scary directory name if the option is actually selected. (maybe transitions to append "The configuration will be imported from the [directory] directory.") This would make the initial list far more scannable and hopefully lead people to make better choices, vs. that one option leaping out due to its visual prominence. Because the scary text is only visible if you're in this exact situation, this suggestion doesn't have to block commit, but if it's easy it would be cool to do.

Otherwise, no UX concerns from us, with the caveat that none of our "usuals" in terms of designers/UX folks were on this week's call cos they're at Dev Days.

Also, we did hit one bug... I'm not moving down to "needs work" because it could've been something on my install, but since I couldn't get drush cex working, we did a slightly different workflow which was to:

1. Install the minimal profile
2. Make some configuration changes: changed site name during install, added a content type + field
3. Do a manual "Full export" from the config sync tool.
4. Copy/paste all of the files from the downloaded tarball to the config_xxx/sync directory
5. Drop your database and re-create an empty on with the same name
6. Reinstall choosing "Use existing configuration"
7. Everything imported properly, but the Tools and Administration menu blocks were gunked up: it said "This block is broken or missing. You may be missing content or you might need to enable the original module." But we didn't mess with any block-related stuff (and there's video proof! ;)).

So one more run-through using the Config Manager in core, not Drush, by someone who knows what they're doing, might be good. :)

Thanks UX team for the review. Patch attached changes the visual weight by only displaying the path ala the Umami warning. I've updated the issue summary screenshots. Also what's nice about this is that we don't need the CSS change then.

I discussed the text and user experience with @gábor-hojtsy and have incorporated the feedback.

@jibran thanks for the review too. I don't think the profile name should be in the radio button title because then you've got a problem with which "Minimal". The most important thing is that you are installing from existing configuration.

@webchick - yeah I noticed the minimal menus when I was testing this morning too. I'm filed a follow-up to address this - #2983603: Move menu_ui_menu_* entity hook implementations to the Menu entity

Screenshots look great to me, thanks! And thanks for the follow-up, too. Good to know we found a legit bug. :)

Also, crediting @benjifisher for the "copy/paste from Umami's entry" idea.

Do we need release and product manager review? The only thing left here is a change record with proper screens ;-) This looks a lot better now. Thanks, @webchick, and @alexpott!

II don't *think* so? This is adding a new capability to an existing API, not a whole new subsystem and/or module to the system.

Re #21 #22 #23:

I'd say the profile should not be mentioned in the install option. When I use a profile like minimal, it is a starting point. Once I start adding modules and building my site, I don't see it as minimal anymore. The fact that it once started as minimal is no longer relevant; it's my own site now.

What users need at that point, is confirmation that they are making the right choice, so they can predict the outcome. Mentioning the install profile is not going to give that confirmation and may even be confusing ("Which one is it, minimal or my own config?").

What would be really nice, is to extract some info from the existing config yml's, probably the site name, and present that to the user. So the radio button title could become "Install the site named %name using existing configuration."

Well, if that suggestion is easy to do, I agree that'd be preferable.

@marcvangend great idea to use the site name! I'll implement that next unless someone else does in the next couple of hours.

I've added the site name to the radio description. I didn't add it the radio title because I think this will then bring up the difficulties of sorting the radio buttons, also the site name can be literally anything and any length so it presents a design problem. And it is not a profile but imagine you site was called "Profile". It'd be hard o make ha look right. At the moment the order is alphabetical apart from Standard (which always comes first) and Minimal (which always comes second). I will file a followup to discuss the UX issues of sorting this list because once 8.6.x is out and Umami is present I'm not sure the order makes sense.

Screenshots in the issue summary updated.

I've created #2983839: The sort of install profiles is interesting to discuss the install profile sorting issue.

I tested this manually and it works as described in the issue summary. I'm happy to see the site name in the radio description, I think it's a big improvement for UX. Personally I'm not too concerned about the "scary" directory name (#22) because it now only shows up as a confirmation after selecting that option, and it has the friendly green color and check mark.

Regarding #22 point 7:
I tested the same scenario and indeed this message is rendered instead of the original block content: "This block is broken or missing. You may be missing content or you might need to enable the original module." See the screenshot:

Unfortunately this is to be expected and beyond the scope of this issue, I'm afraid. Custom blocks are part config (block id, label, placement, visibility settings etc.) and part content (the actual block content). Everywhere there is config depending on content (there are more examples, like embedding a node in the header of a view), you will see that config management cannot prevent this.

I'm calling this RTBC.

Related issues for around block content not playing nicely with config in this way:
#2906919: Allow users to create a block content entity with a specific UUID if it is a missing dependency of a config object
#2756331: Custom blocks cannot be properly exported and imported

Adjusting credit.

Committed 8fbece0 and pushed to 8.6.x. Thanks!

Still needs the change notice update. Should be marked fixed afterwards.

I think this commit broke HEAD for PHP 5.5: https://www.drupal.org/pift-ci-job/1012684

I've updated https://www.drupal.org/node/2897299

So excited to finally see all this going in! Crazy good site builder DX wins!

Good point, let's mention this explicitly as a highlight of 8.6.0! :D

Great work everyone!!

Does this actually work? I'm on 8.9 and have my configuration directory set in settings.php and do NOT see any option to install from configuration.

Ah, okay, you can't do this if you use the Standard profile. Wow, that sucks.

For future reference. To work with the Standard profile this need to be fixed #2982052: Allow an install hook in profiles to install from configuration