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

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 "Pugin 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!

b_sharpe → changed the visibility of the branch 11.x to hidden.

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, @bsharpe! 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.

b_sharpe → changed the visibility of the branch 3315694-cache-broken-after-install to hidden.

b_sharpe → changed the visibility of the branch 3315694-cache-could-be to hidden.

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!

Automatically closed - issue fixed for 2 weeks with no activity.