1

I consider installations like this pretty standard.

composer create-project --no-install drupal/recommended-project:9.5.11 . composer config platform.php 8.1 composer config allow-plugins true composer config process-timeout 2000 composer config optimize-autoloader true composer config classmap-authoritative false composer require --no-install php:8.1 drupal/field_group drupal/geolocation drush/drush composer install 

I then open up the site, go through the process of setting up a fresh site.

drush pm:enable --yes field_group geolocation geolocation_leaflet telephone drush cr composer dump-autoload 

Everything seems to work fine, but when the configuration menu leads me to /admin/config/services/geolocation/nominatim, that one displays

InvalidArgumentException: Class "\Drupal\geolocation_leaflet\Form\NominatimGeocodingSettings" does not exist. in Drupal\Core\DependencyInjection\ClassResolver->getInstanceFromDefinition() (line 24 of core\lib\Drupal\Core\DependencyInjection\ClassResolver.php).

Drush lists the modules as enabled, also \Drupal::config('core.extension')->get('module'); lists the enabled modules correctly and so does the webinterface of "Extend" at /admin/modules look as expected.

But \Drupal::service('module_handler')->getModuleList(); does not include them and the autoloader just does not get namespaces under web/modules/** added.

I can go debug deeper and probably will, I can also include all the<100 namespace-prefixes into the composer.json file manually, but I am here in the wrong place, since this all should just work out of the box.

Anyone experienced such? Any advice here?

3
  • It might be worth noting that this isn't (or at least has never been for me) a problem with Drupal 10 or 11. Drupal 9 hasn't received any changes, apart from a security fix, since July 2023, and things have moved on since then Commented Oct 29 at 17:13
  • 1
    Drupal 9 was end-of-life almost two years ago, so installing it right now is not actually standard. Commented Oct 30 at 19:24
  • Well, I am fully aware of Drupal 9 being discontinued, but still many are and will be porting even older versions up, passing through this "tooling" - so I thought it is worth of documenting. Commented Oct 31 at 10:25

1 Answer 1

0

I managed to get Drupal pick up the modules by running

drush cache:clear container 

It seems so that drush cr only rebuilds certain caches conditionally, whereas the drush cc container runs unconditionally. Maybe someone can explain with more credibility than AI stating "this happens for modules without services.yml".

I also wonder how drush cr is the recommended approach all over the internet when it is known to be not fully sufficient. People are truncating raw database tables and pruning filesystem directories in addition to it in their blog posts, for years and years now. When all it takes would be adding a --force switch or at least documenting which caches get cleared under which circumstances.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.