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

[danarbello]

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

1. Go to imprivata-drupal-8 repo
2. Pull the project down locally and run it with DDEV
3. After getting the project up and running, run composer robo frontend:dev-disable imprivata
4. After completion, run a Drush command like ddev drush @imprivata.ddev cr
5. 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

Beta Give feedback

No tasks being tracked yet.

[danarbello]

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]

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.