Allow recipe command to write to the container - ensuring that cache does not be cleared after a recipe installs a module

After installing the recipe using the php script, and receiving a success command, visiting the `/admin/config/search/path` results in an error:

Looks like this kills the whole site, not just that page.

What's confusing to me is that I would have expected the underlying API to install the module to clear caches. Investigating!

I've been working on this and while I have a "fix", I'm not confident it's the right one.

At a basic level, if we clear all caches in \Drupal\Core\Recipe\RecipeRunner::processInstall() by calling drupal_rebuild() after installing modules and themes, everything works fine. I was able to narrow it down rebuilding the container and clearing the cached container definitions by throwing this at the end of processInstall().

    $kernel = new DrupalKernel('prod', $GLOBALS['classloader']);
    $kernel->setSitePath(DrupalKernel::findSitePath(Request::createFromGlobals()));
    $kernel->invalidateContainer();
    $kernel->boot();
    $kernel->preHandle(Request::createFromGlobals());

What's throwing me for a loop is that Drush doesn't have any code like this for it's module install command (\Drush\Drupal\Commands\pm\PmCommands::install) and doesn't have this problem. I'm not finding any code that rebuilds the container separately. As well, the module installer itself calls \Drupal\Core\DrupalKernel::updateModules which rebuilds the container.

Any ideas? On the one hand, given how broken this is I wonder if committing a basic cache clear for now makes sense until we can confirm a proper fix.

This came up in #3301370: Model core's standard install profile as recipes — see #3301370-45: Model core's standard install profile as recipes. This is hence a blocker to the Standard install profile getting converted to a Recipe.

I'm somewhat surprised this needs an explicit/manual cache clear … and it seems that @deviantintegral was similarly surprised in #5 with his excellent research 🤓

Steps to reproduce this issue for standard recipe install:

• Checkout 11.x branch and apply recipe patch curl https://git.drupalcode.org/project/distributions_recipes/-/raw/patch/recipe-11.x.patch | git apply
• Apply patch from https://www.drupal.org/project/distributions_recipes/issues/3301370#comm... curl https://www.drupal.org/files/issues/2024-01-23/recipes-standard-profile-3301370-45.patch | git apply
• Install empty profile drush si -y empty
• Install standard recipesphp core/scripts/drupal recipe core/recipes/standard
• Visit website homepage to seeThe website encountered an unexpected error. Try again later. error.
• Clear cache to get a standard site install using recipesdrush cr

@deviantintegral, I've had the "Plugin does not exist" error pop up even while enabling/disabling modules with drush.

After applying any recipe the site cache should be cleared because every time I apply a recipe the website throws different errors after successful application and only cache clear manually fixed the issues, therefore, IMHO a cache clear should always trigger after applying a recipe.

Thanks!

I can replicate the issue with the given "pathauto" recipe above, but what I find interesting is that I can run: ./vendor/bin/drush php:eval "\Drupal::service('module_installer')->install(['pathauto']);" in the exact same state as before the recipe and I do not see the issue.

This leads me to believe something else is at play here since the Recipe is using that same method to install the module. I don't think just killing all cache when applying a recipe is the answer rather than tracking down the cause of this issue.

I found the root cause of this here, in which the RecipeCommand's Kernel was set to not allow writing to the container.

-    $kernel = new DrupalKernel('prod', $this->classLoader, FALSE);
+    $kernel = new DrupalKernel('prod', $this->classLoader);

This causes discovery, bootstrap, and container caches to not update from the recipe which is why plugin and entity discovery acts up as well as some routes.

What I'm not sure of is WHY this was specifically set to FALSE as the default for the function is TRUE so I have to assume this was an intentional change at this point, so am holding off on the MR until I can confirm with original committers.

Awesome detective work, @b_sharpe! I think we'll need @alexpott to weigh in here.

I'm pretty sure this is a copy and paste fail from one of the other commands we have that do not install modules. Let's fix this in core and I'll merge into the recipe initiative code base.

Added MR. Needs tests.

@b_sharpe and I discussed tests and we agreed that test coverage here is not necessary it is c&p paste fail from our other commands (that do not need to write container) and is really obvious once you see it.

A one-line copypasta bug fix that makes the recipe application process smoother and reduces unexpected exceptions? SOLD! Heartily, I RTBC thee.

Discussed with a @catch and we agreed to put this in 10.3.x because it is a doh! copy pasta mistake (mine) and improves the recipe experience tremendously in 10.3.0.

Committed and pushed 34a6368597 to 11.x and 002bca921a to 11.0.x and bd1049d4c4 to 10.4.x and 350464e891 to 10.3.x. Thanks!