Here are my own observations. It contains details that were not mentioned in @ kiamlaluno's answer.
Things that need to rebuild
There are two "caches" that need to be rebuilt, if a * .module file with hook implementations has just been created, in a module that previously did not have such a file.
"Conteneur.modules"container parameter, which we can inspect with
dpm ( Drupal :: getContainer () -> getParameter (& # 39; container.modules & # 39;));.
Each entry has a
['filename' => *]key, which can be either
& # 39; MODULENAME.module & # 39;.
If it is
noDrupal has not yet found the * .module file and does not include it to look for hook implementations.
- The hook implementations, which we can inspect with
dpm ( Drupal :: moduleHandler () -> getImplementations ($ hook_name));.
Operations that rebuild these things – or not
The first part, the container parameter, is not rebuilt when removing the development cache, or
drush cr. This was the real problem.
The second part, the module_implements cache, is not rebuilt when the development cache is cleared, but it is rebuilt on
To rebuild the first part, the container settings, you can, as suggested by @kiamlaluno, uninstall and re-enable the module with the new anchor points. But this can be inconvenient because uninstallation can result in data loss.
Fortunately, there is a simpler solution: Enable any other module that was not previously installed, and then uninstall it again.
For example. for me, it was the module "statistics". But can be any other.
drush pm-list | grep "not installed" drush in statistics drush pmu statistics
EDIT: NOT SO FAST!
I must correct myself, for the moment:
- The above method of activating and uninstalling any other module corrects the container parameter "filename" at first.
- However, clearing the cache again later deletes the "file name" setting again.
This means that this setting is stored in a more persistent place somewhere.
The reason: APCu file cache: cli vs web
ExtensionDiscovery uses a cache to store discovered extension files.
In my case, it is
Drupal Component FileCache FileCache, with a
Drupal Component FileCache ApcuFileCacheBackend apcu backend.
The problem: the APCu cache contains isolated domains for cli and for the web.
This means that if the file cache is erased on cli, for example. via drush, the web entries are still there.
This problem seems to apply only to the file cache in ExtensionDiscovery. Other caches are not affected. This is probably because this file cache is at a lower level in the Drupal boot.
Another part of the problem may be that the file cache is never completely erased. At least I can not find such a place. Instead, individual entries are deleted by key.