Running `frontend:dev-disable` Results in `cache:backend` Error

danarbello commented 4 weeks ago

Description

As a developer, I would like to disable front-end development tooling like Twig Debugging. To do this, Usher provides a Robo command to do this via composer robo frontend:dev-disable. However, when I run this on Imprivata (composer robo frontend:dev-disable imprivata) although the command completes successfully and without error any successive Drush commands result in the following error:

ddev drush @imprivata.ddev cr

In Container.php line 157:

  You have requested a non-existent service "cache.backend.null". Did you
  mean one of these: "cache.backend.redis", "cache.backend.apcu", "cache.b
  ackend.memory", "cache.backend.php"?

Failed to run drush @imprivata.ddev cr: exit status 1

Ultimately, this results in a WSOD for the rendered site with the following error:

The website encountered an unexpected error. Try again later.
Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException: You have requested a non-existent service "cache.backend.null". Did you mean one of these: "cache.backend.apcu", "cache.backend.php", "cache.backend.memory", "cache.backend.redis"? in Drupal\Component\DependencyInjection\Container->get() (line 157 of core/lib/Drupal/Component/DependencyInjection/Container.php).

Issue Owner

@danarbello

To Reproduce

Steps

Go to imprivata-drupal-8 repo
Pull the project down locally and run it with DDEV
After getting the project up and running, run composer robo frontend:dev-disable imprivata
After completion, run a Drush command like ddev drush @imprivata.ddev cr
See error

Environment

OS: macOS 14.5
Device: MacBook Pro M1 2021
Docker: OrbStack (1.6.2)
DDEV: 1.23.2

Expected Behavior

This should function as described by Usher's documentation: disables front-end tooling, especially Twig Debugging.

### Tasks

danarbello commented 4 weeks ago

From this Slack message from @agarzola:

Immediate solution — The issue is that line ~41~ 37 of web/sites/default/settings.local.php loads web/sites/fe.development.services.yml (I can’t link to either file in GitHub because they are both ignored in Git). Remove ~that line~ the fe. prefix from the file, and you should be good to go.

Open a ticket for this — This has a bit of a long tail: web/sites/imprivata/settings.php requires web/sites/default/settings.php, which in turn requires web/sites/default/settings.local.php if it exists. We probably don’t need default/settings.php to load default/settings.local.php and we definitely don’t need default/settings.local.php to load web/sites/fe.development.services.yml because the web/sites/imprivata/settings.local.php file created by the frontend:dev-enable command already loads that services file. What’s puzzling to me is why default/settings.local.php (a file that is not tracked in Git) is updated to load fe.development.services.yml (a file that we create with Usher and Drupal should know nothing about). It’s as if there were a custom process somewhere that updates web/sites/default/settings.local.php to point to the fe.development.services.yml file we invented, instead of the default, which is just development.services.yml (i.e. no fe. prefix).

agarzola commented 4 weeks ago

To clarify: the real mystery here is how a reference to fe.development.services.yml made its way to web/sites/default/settings.local.php. I remember that when the frontend:dev-enable/frontend:dev-disable commands were created, there was a bit of back-and-forth. It’s possible that originally frontend:dev-enable only created fe.development.services.yml and then developers were required to update settings.local.php on their own, which would explain why Dan’s settings.local.php —and mine!— were pointing to fe.development.services.yml in the first place.

ChromaticHQ / usher