Invoke hook after a site install is complete

I think this would be better suited as an event, there's no altering of data needed here. SiteInstalledEvent or something like that?

I applied this patch cleanly , but i did not know how to use it.

+++ b/core/lib/Drupal/Core/Extension/module.api.php
@@ -477,6 +477,23 @@ function hook_install_tasks_alter(&$tasks, $install_state) {
 /**
+ * Responds to Drupal being installed.
+ *
+ * @param $install_state
+ *   An array of information about the current installation state.
+ *
+ * @see install_tasks()
+ */
+function hook_site_install_finished($install_state) {
+  if (!empty($install_state['parameters']['profile'])) {
+    $profile = $install_state['parameters']['profile'];
+    if ($profile === 'special_profile') {
+      \Drupal::state()->set('my_module_special_profile_support', TRUE);
+    }
+  }
+}

What about listing some concrete usecases in the documentation?

@borisson_
Are events fired for installation profiles?

@dawehner: not sure what you're asking here. Are you asking if there are any events related to installation profiles? If so - I couldn't find any. So I guess that means a hook is a better way to go?

I've patched 8.5 with this but the hook is not invoked upon site install. I am using the standard profile. My motivation to use this is to remove the 'default' shortcut set added by the Standard install profile. This is breaking my build process.

@samuel.mortenson

My implementation is in a custom module that I see is enabled in core.extension.yml

/**
 * Implements hook_site_install_finished().
 */
function my_module_site_install_finished(&$install_state) {
  echo "Removing default shortcut set \n";
  \Drupal::entityManager()->getStorage("shortcut_set")->load("default")->delete();
}

I expect that, after Drupal installs with the 'standard' profile, that the Shortcut links (content) will be deleted. This is not happening.

For background, I use Travis CI and Acquia BLT and this process includes a full installation of Drupal followed by a config import. This process fails due to the much discussed problem of the 'Standard' profile adding Shortcut link content. The UUID collision is a thorn in many sides. Using this approach, I hope to remove the shortcut content in order to allow for a clean config import without warning me that the Shortcut menu links exist with a different UUID.

@samuel.mortenson - So, this is a basic question but just as a sanity check - Since my custom module is not invoked until it is enabled by config import, how _should_ this post install hook be instantiated? Don't we need to explicitly instantiate the hook somehow?

@samuel.mortenson #facepalm - yep, this make sense. I was confusing the chicken and egg. So, I have a different approach now that is working with Acquia BLT using a BLT post install hook - in case anyone is reading it is:

blt/src/Hooks/DeleteShortcutsHook.php

namespace Acquia\Blt\Custom\Hooks;

<?php
use Acquia\Blt\Robo\BltTasks;
use Consolidation\AnnotatedCommand\CommandData;
use Acquia\Blt\Robo\Exceptions\BltException;

/**
 * This class defines example hooks.
 */
class DeleteShortcutsHook extends BltTasks {

  /**
   * This will be called after the `internal:drupal:install` command is executed.
   *
   * @hook post-command internal:drupal:install
   */
  public function DeleteShortcutsHook($result, CommandData $commandData) {
    /** @var \Acquia\Blt\Robo\Tasks\DrushTask $task */
    $task = $this->taskDrush()->drush("en")->rawArg("my_custom_module -y");
    $result = $task->interactive($this->input()->isInteractive())->run();
    if (!$result->wasSuccessful()) {
      throw new BltException("Failed to delete Shortcuts!");
    }
    echo "Removed default shortcut set.\n";
    return $result;
  }
}

whereby the my_custom_module includes a hook_install() with:

function my_custom_module_install() {
  \Drupal::entityManager()->getStorage("shortcut_set")->load("default")->delete();
  echo "Shortcut links removed \n";
}

Tested this out, and looks good to me. Helpful for performing some specific configuration after core was installed. Code looks good and API docs are solid IMO.

Would it be worth moving the cron run from install_finished() to system_site_install_finished()? It's not essential to installation but rather something we do to improve initial user experience.

One thing that @catch's comment makes me ask is whether this is happening at the right point. I don't think this hook should be fired whilst user 1 is logged in. Atm it is. I think this hook should be fired from install_finished() just after where cron is run. I.e. at the point where a non interactive install is finished. Therefore non-interactive and interactive versions of this hook are fired under the same circumstances i.e. without a user being logged in.

That said I'm also not 100% convinced on the use-cases.

Elaborating on

That said I'm also not 100% convinced on the use-cases.

Enable an optional module feature if a specific profile is installed.
For me, profiles themselves should not have functionality and there functionality should be in modules and therefore this should be achieved with a traditional hook_modules_installed or hook_install.

Show a status message to the user once the install is finished.
Such as what? I'm not convinced modules should be cramming up the first page people see after an install with messages. This is a pattern that could cuase problems

Act on optional config installed at the end of the profile installation process (see install_install_profile). This is really hard to do without this hook.
The statement that it is hard to act on that config is true but what is the use-case of acting on such config? I think there might be better ways of doing things. For example, building your own install profile without the default shortcut set.

Oh and this needs work because even if we do decide to do this the non-interactive and interactive hooks should be fired with the site in the same state.

I think one use case for this hook would be to install default content.

I've run into an issue using module install hooks to do this when installing from existing config, because field storage and field configs, among others, are not imported until after the modules are installed.

By strange coincidence, I've found myself here whilst trying to add a status message pointing out #2989541: Add a welcome tour to Umami where we have added a Tour to the Umami demo. It would be good to actually point new users at the Tour...

Use case: Allow one last cache clear, which is all that blocks Redis caching from working on install. (If Redis is wired up in settings.php, the cache is not yet built in Redis so the site fails with missing class or missing-config errors. A `drush cr` fixes it. With a hook/event at the right place, the Redis module could force a cache rebuild and then the site just-works with Redis from day 1.)

Re-roll. Applies to 8.6.x, 8.7.x, .8.8.x.

I have reviewed this by applying the patch then adding the following function to /core/profiles/demo_umami/demo_umami.install

/**
 * Implements hook_site_install_finished().
 *
 * Perform test action after the install has completed.
 */
function demo_umami_site_install_finished($install_state) {
  \Drupal::messenger()->addMessage('The thing has been done.');
}

which resulted in the message being added at the right time and, most importantly, only at the right time - at the end!

Basically, the code works.

I do think, however, that we could probably add some more detailed explanation of when the hook is invoked to the documentation in module.api.php.

Apart from that documentation, looks good to me!

oh - and seeing as I'm sat in the DrupalCon building, let's add the tag ;-)

Okay, I've added a little more context to the hook function to show some examples (and used the same commentary to explain they are examples)

Review should be repeatable using the same test I described in #29.

Rather than adding a hook is there a reason why we wouldn't just want to fire an event? Then anyone could write an event listener to "do stuff" via OO rather than using a hook?

Another similar issue that calls for this but hasn't been worked on was worked on by @sun and others forever ago. #2206347: Use event system in ModuleHandler

I think one use case for this hook would be to install default content.

For color, that's the original reason why we filed this patch. And its been successfully used for the past few years both on the 3.x and 4.x versions of the scenarios module - a module that is focused on providing demo content, works with default_content, migrate and acquia's content hub.

Usage: https://git.drupalcode.org/project/scenarios/blob/8.x-4.x/scenarios.api.php

Implementation: https://git.drupalcode.org/project/scenarios/blob/8.x-3.x/scenarios.modu...

re: #31 I am not saying we shouldn't commit this. Its a good hook - I've been using it for years!

But in some ways aren't hooks kinda considered deprecated?

Rather than adding a hook is there a reason why we wouldn't just want to fire an event?

This was also suggested in #2. I think it makes sense to be an event instead of a hook.

This will also need a test to ensure the event is fired.

This new hook would definitely also be interesting for profiles.
When a site is installed from config a profiles install hook would (if it was allowed) fire at the wrong relative to the other install tasks. So this new hook would also allow profiles to create content etc. see #2357215: Clean up hook_install() in Standard Install Profile.

We could even argue that this hook should be in the .install instead of the .module as it is not code that is ever useful on a normal page load.

If we reduced the scope to only supporting this for install profiles and clearly documented that it is about doing things other configuration change then I'm +1 to this. And I think it makes doing #2357215: Clean up hook_install() in Standard Install Profile a lot easier.

As feature

Re-roll. Applies to 9.1.x

Just in case there needs to be more justification for this, I have a use case.

Currently, Acquia suggests users build their sites using BLT and Pipelines. As such, when Pipelines builds the site to do its testing, it executes a site install in a temporary environment. Then, it tries to do a config import. When that config import occurs, many different errors occur because none of the installation hooks have been executed for the profile. With lighting (yuck) being required for blt 10.x, we have no choice but to deal with profiles.

https://www.drupal.org/project/drupal/issues/2982052#comment-13548411

Running installation hooks for the profile and all the modules associate with the profile need to be a part of the drush si process.

***EDIT*** remove my own comment.

I have reviewed and tested, it is working fine.

Hi - Abhinand - thanks for your testing. In order to progress the issue, though, the maintainers will need to be able to see evidence of your testing.

I suggest adding screenshots of the behaviour bot with and without the patch applied along with a description on your methodology (so others could repeat that, if necessary).

We are also in need of some _automated_ tests, by the way!

Re-roll patch created for 9.3.x.

@rachel_norfolk Tests added, Please have a look and advise that the approach is correct or not, I am not too sure and need some guidance.

Test workflow is like, create install file (testing.install) in the profile (testing) and added one hook. So the approach is after completing the installation process check that the hook is called successfully or not.

One more thing while we using php version 8, test is fail and with the lower versions its pass.

Please check and provide some expert advise, this is new for me.

I tried to utilize the latest patch and ran into some issues on how the hook is invoked. Looking at other implementations of invokeAll, I think the correct call should be (note the brackets around the argument):

function install_invoke_finished_hooks(&$install_state) {
  \Drupal::moduleHandler()->invokeAll('site_install_finished', [$install_state]);
}

One may verify this approach by looking at the implementation of invokeAll since it uses call_user_func_array to resolve the arguments.

The second parameter in invokeAll() function must be an array and if we look at the function defined in the patch

+/**
+ * Invokes hooks related to site installation being finished.
+ *
+ * @param $install_state
+ *   An array of information about the current installation state.
+ */
+function install_invoke_finished_hooks(&$install_state) {
+  \Drupal::moduleHandler()->invokeAll('site_install_finished', $install_state);
+}
+

here, the param $install_state is already in array form! So, I don't think we need to add an extra []around $install_state as mentioned in #49. Pardon me if am wrong, just sharing my views.

Thanks!

Actually, after further review I found out that since PHP 8.0 call_user_func_array considers argument unpacking differently. See e.g. php.watch documentation! Therefore, the proposed change in #49 will be necessary if the new hook should accept only $install_state. Maybe this change will also resolve some of the errors in the prior test runs.

While using this hook I noticed that (of course) invoking this hook does not respect dependencies between modules. For an experienced Drupal developer it is clear that the order of execution is governed by the weight of the module. Therefore, one may manipulate it like so:

/**
 * Implements hook_install().
 */
function my_module_install() {
  module_set_weight('my_module', 1);
}

But, I can imagine that for a newer Drupal user it can lead to frustrating results. For example, when using an installation profile and multiple modules with configuration. One may expect that the dependencies are resolved as during the installation.

I like the lean implementation of this patch. And, invoking the hook should work as usual. But, I would suggest adding a note describing module weights to the documentation.

• Created a MR with the patch at #47 as starting point.
• Fixed the PHP 8 compatibility issue
• Fixed the test by replacing deprecated assertions and removing unneeded assertions.
• Cleaned up comments and renamed the test itself

I didn't address the point made at the beginning of this issue by several people (why isn't this an event instead of an hook).

Simonboy's comment in #52 does seem worth some extra documentation. Added.

My re-queues of tests are not coming back but it seems like any problems are with the testbot?

And this does have a test.

Patch looks good and working beautifully.

Returning to RTBC.

1. +++ b/core/profiles/testing/testing.install
   @@ -0,0 +1,15 @@
   +<?php
   +
   +/**
   + * @file
   + * Install, update and uninstall functions for the testing installation profile.
   + */
   +
   +/**
   + * Implements hook_site_install_finished().
   + *
   + * Perform test action after the install has completed.
   + */
   +function testing_site_install_finished($install_state) {
   +  \Drupal::messenger()->addMessage('Perform action after the installation.');
   +}
   

   I don't think we should add this to the testing profile. It's used by default for all tests. I think we should write our own profile - see how \Drupal\FunctionalTests\Installer\DistributionProfileTranslationQueryTest creates an install profile for example.

2. +++ b/core/tests/Drupal/FunctionalTests/Installer/TestingInstallerTest.php
   @@ -0,0 +1,52 @@
   +    $this->assertInstalledConfig($skipped_config);
   

   I don't see why we need to test the configuration here. It's not really part of the change.

This patch is a follow up on #38, just added PHP 8 compatibility (see the interdiff file), because in PHP 8 for the call_user_func_array function (which ModuleHandler::invokeAll() invokes) 'keys will now be interpreted as parameter names, instead of being silently ignored', and $install_state has non-numeric keys.

See also: #49.

Fixed failed commands on #61
Attached patch against Drupal 9.3.x

Needs rerolls for drupal 9.5.x, when testing previous patches with Drupal 9.5.7 I get following errors:

When installing profile via UI:

The website encountered an unexpected error. Please try again later.
Error: Unknown named parameter $interactive in call_user_func_array() (line 426 of core/lib/Drupal/Core/Extension/ModuleHandler.php).
call_user_func_array(Object, Array) (Line: 426)
Drupal\Core\Extension\ModuleHandler->Drupal\Core\Extension\{closure}(Object, 'myprofile') (Line: 405)
Drupal\Core\Extension\ModuleHandler->invokeAllWith('site_install_finished', Object) (Line: 433)
Drupal\Core\Extension\ModuleHandler->invokeAll('site_install_finished', Array) (Line: 1895)
install_invoke_finished_hooks(Array) (Line: 700)
install_run_task(Array, Array) (Line: 571)
install_run_tasks(Array, NULL) (Line: 119)
install_drupal(Object) (Line: 48)

When installing width drush si ( drush 11.5):

Error: Unknown named parameter $parameters in /var/www/html/docroot/core/lib/Drupal/Core/Extension/ModuleHandler.php on line 426 #0 /var/www/html/docroot/core/lib/Drupal/Core/Extension/ModuleHandler.php(426): call_user_func_array(Object(Closure), Array)
#1 /var/www/html/docroot/core/lib/Drupal/Core/Extension/ModuleHandler.php(405): Drupal\Core\Extension\ModuleHandler->Drupal\Core\Extension\{closure}(Object(Closure), 'myprofile...')
#2 /var/www/html/docroot/core/lib/Drupal/Core/Extension/ModuleHandler.php(433): Drupal\Core\Extension\ModuleHandler->invokeAllWith('site_install_fi...', Object(Closure))
#3 /var/www/html/docroot/core/includes/install.core.inc(1895): Drupal\Core\Extension\ModuleHandler->invokeAll('site_install_fi...', Array)
#4 /var/www/html/docroot/core/includes/install.core.inc(700): install_invoke_finished_hooks(Array)
#5 /var/www/html/docroot/core/includes/install.core.inc(571): install_run_task(Array, Array)
#6 /var/www/html/docroot/core/includes/install.core.inc(119): install_run_tasks(Array, Array)
#7 /var/www/html/vendor/drush/drush/includes/drush.inc(129): install_drupal(Object(Composer\Autoload\ClassLoader), Array, Array)
#8 /var/www/html/vendor/drush/drush/includes/drush.inc(113): drush_call_user_func_array('install_drupal', Array)
#9 /var/www/html/vendor/drush/drush/src/Commands/core/SiteInstallCommands.php(152): drush_op('install_drupal', Object(Composer\Autoload\ClassLoader), Array, Array)
#10 [internal function]: Drush\Commands\core\SiteInstallCommands->install('myprofile...', Array)
#11 /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(257): call_user_func_array(Array, Array)
#12 /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(212): Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback(Array, Object(Consolidation\AnnotatedCommand\CommandData))
#13 /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(176): Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter(Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
#14 /var/www/html/vendor/consolidation/annotated-command/src/AnnotatedCommand.php(390): Consolidation\AnnotatedCommand\CommandProcessor->process(Object(Symfony\Component\Console\Output\ConsoleOutput), Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
#15 /var/www/html/vendor/symfony/console/Command/Command.php(255): Consolidation\AnnotatedCommand\AnnotatedCommand->execute(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#16 /var/www/html/vendor/symfony/console/Application.php(1039): Symfony\Component\Console\Command\Command->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#17 /var/www/html/vendor/symfony/console/Application.php(275): Symfony\Component\Console\Application->doRunCommand(Object(Consolidation\AnnotatedCommand\AnnotatedCommand), Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#18 /var/www/html/vendor/symfony/console/Application.php(149): Symfony\Component\Console\Application->doRun(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#19 /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php(124): Symfony\Component\Console\Application->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#20 /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php(51): Drush\Runtime\Runtime->doRun(Array, Object(Symfony\Component\Console\Output\ConsoleOutput))
#21 /var/www/html/vendor/drush/drush/drush.php(77): Drush\Runtime\Runtime->run(Array)
#22 /var/www/html/vendor/drush/drush/includes/preflight.inc(18): require('/var/www/html/v...')
#23 phar:///usr/local/bin/drush/bin/drush.php(143): drush_main()
#24 /usr/local/bin/drush(14): require('phar:///usr/loc...')
#25 {main}

basically this:

function install_invoke_finished_hooks(&$install_state) {
  \Drupal::moduleHandler()->invokeAll('site_install_finished', $install_state);
}

should become this for php8.1:

function install_invoke_finished_hooks(&$install_state) {
  \Drupal::moduleHandler()->invokeAll('site_install_finished', array_values($install_state));
}

Reroll of #62 for Drupal 9.5.x and PHP 8.1

Reroll of #72