Quantcast
Channel: Issues for Drupal core
Viewing all articles
Browse latest Browse all 291053

module_hook is broken for disabled modules and included hooks

$
0
0

In D8, implementsHook calls $this->loadInclude($module, 'inc', $module . '.' . $hook_info[$hook]['group']); which happily tries to do $this->moduleList[$module] without any check in either method whether the $module is enabled.

In D7, it's even more funny:

  1. module_hook
  2. module_load_include
  3. drupal_get_path
  4. drupal_get_filename which reads {system} regardless of status.
  5. The include file of the disabled module is loaded and happily processed.

This is rarely hit because module_implements will iterate the module list and call implementsHook only with module names that happen to exist (in D7 the module_load_include call is inlined into module_implements).

But. In D8, field_views_data will iterate the existing fields and call the modules from there for views data and if you happen to have a disabled module which provided a field type, then boom! you get a notice. If you have a stray modulename.type in your DRUPAL_ROOT that gets loaded. Yes, that's an idiot edge case, but hey, it's me.

I have hit this during the update path where disabled modules are frequent which, alas, makes this critical. Of course, fixing ModuleHandler is not hard at all. I already patched this, still need to write a test, will post a patch soon.

I will file a separate issue for Views to get rid of (pseudohook)_field_views_data because it's not necessary, there's an alter already and we can change that to an alter of array types.


Viewing all articles
Browse latest Browse all 291053

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>