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.Discovered while debugging #2188661: Extension System, Part II: ExtensionDiscovery
Views uses quite some fancy code to allow both modules and themes to "modify" the view output before and after it is rendered.
"Modify" → "alter"
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | drupal8.views-pre-post-render-alter.1.patch | 3.16 KB | sun |
| drupal8.views-pre-post-render-alter.0.patch | 3.17 KB | sun | |
Comments
Comment #1
tim.plunkettThis has been done without an alter since at least 6.x-2.x, but I have no idea why. Maybe @dawehner knows?
Comment #2
sunOopsie, the signature is different... :-/
→ #329012: Remove call_user_func_array() from ModuleHandler::invoke() + invokeAll()
Comment #4
sunI guess the reason is simple: Only D7 added support for alter hooks in themes.
Prior to D7, themes did not participate in drupal_alter().
Comment #5
dawehnerMh, so we have all kind of even more hooks:
All of those are mostly used to change the executed view, so we might should consider to mark all of those as alter hooks?
In general you mostly can alter anything in D8 as we use a lot of objects.
On all these hooks in views I would consider views_pre_render as the one which will add new stuff, like new rows etc.
Still not sure whether we want to keep this functionality to be honest. This causes all kind of dependency problems, as for example the theme system
cannot be loaded lazy due to that.
Comment #6
tim.plunkettAha! That seems like a perfectly logical explanation.
Comment #7
sun@dawehner: Interesting.
For the sake of architectural cleanliness, I think that every hook that primarily exists in order to modify previously built/added data should be an alter hook.
Without having any kind of idea what the listed hooks are doing, here are my assumptions:
Comment #9
dawehnerTo be honest I can not imagine many usecases which don't alter the view, for non of those hooks.
No hook_views_pre_execute is not hook_views_query_alter ... executing a view is way more than altering the query, actually query is kind of the special case as the query will always depend on your actual query backend you use, though the execution is a general idea.
Yes, though there are clear usecases like when you wanna take the result and do something without before it comes to the rendering step.