Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.There are a number of rebuilds that can be done as static code analysis. The advantage is, of course, breaking a lot of chicken-egg problems. The class registry is one. The oft-debated hook registry is another. Right now we are building this on-the-fly using the cache layer but this is not quite cache. This of course requires #548470: Use something other than a single underscore for hook namespacing. For radical simplifying we could do the theme registry as well -- we are already passing in a single variables array and so hook_theme() is much less necessary. So based on the name of functions and the .tpl.php we can build up the theme registry. It'd be great to have CMI for storing this. We will figure it out what to use instead for now.
When you enable a module then a rebuild.php runs. If you add a new theme function / hook, you run the same.
Comments
Comment #1
bojanz CreditAttribution: bojanz commentedVery interested in working on this.
Comment #2
bojanz CreditAttribution: bojanz commentedWhat we are talking about is basically a hook registry.
And this could be very useful for several reasons:
1) If we had a list of all hooks, we could have the ability to disable certain hooks, or certain module's hooks, or hooks of certain types (all form_alters for example).
This would be very useful for debugging, while allowing us to kill disabled modules: #1199946: Disabled modules are broken beyond repair so the "disable" functionality needs to be removed.
2) It would allow us to move to a world where not all modules are loaded all the time.
Drupal could just load the modules that have implementations of hooks fired, that need to supply content, and their dependencies (we could have two levels of dependencies, where the first one is for loading modules whose functions you use, while the other is for modules on which you rely, like Views for powering your listing view).
As chx said, we first need a clear way of distinguishing which functions are hooks. Naming, namespaces, registration, you name it.
Another important step is killing all hooks that shouldn't be hooks (but callbacks, or plugins, or whatever. I'm looking at you, Field API).
I could imagine a table with a row for each hook (hook type, module name, and file perhaps. For example: form_alter, commerce, commerce.module).
200 modules, 30 hook implementations per module, that's 6 thousand rows, which is not much, and the real number would probably be lower.
Then we could have a cache per hook type, so we could fetch all hook_boot() implementations in all go, etc.
Comment #3
sunClosely related or even duplicate of: #1668892: Enable secure compiled information on disk
Comment #4
pounardNot a duplicate, but related yes. Compilation is a specific rebuild use case, while this issue we're speaking into is generally speaking about all rebuilds.
Comment #17
smustgrave CreditAttribution: smustgrave at Mobomo commentedWonder if still a valid task after 11 years?