Hi,
this is not directly a request for advagg, I am rather just asking your opinion on something else :)
I consider to create a D6 (and maybe D7) module named "pageapi".
This module would hijack/replace template_preprocess_page() via hook_theme_registry_alter().
At the beginning of this hijacked template_preprocess_page, it would invoke all hook_pageapi(). This is meant as a place for modules to do things like drupal_add_js() and drupal_add_css(), which have previously been in hook_init(), where they slow down things like ajax requests.
Another thing I consider this module to do is to provide an API to mess with CSS aggregation, region rendering and other things.
In current D6, core's template_preprocess_page() will waste a lot of time to do all these things, only to let other modules overwrite the variables.
Atm I consider to do this for my own private purposes, but I can imagine to release the module one day, if it proves useful.
---
Now, the question.
As the author of advagg, what would you do differently, if you had a module like pageapi available?
What additional hooks would you expect to see?
(I imagine you had your own battles with hook_preprocess_page() already, so you might be a good person to ask)
Thanks!
(and btw, I think there is something like this already in D8, is it?)
Comments
Comment #1
mikeytown2 commentedThe main thing to look out for is the ordering of the calls to hook_preprocess_page; but if your replacing the first one I really don't see any issues; but then again I haven't thought this through too much.
As for hooks, if hook_init() knew what kind of response was going out, that might help to clean things up in terms of running unnecessary code; in addition to something like hook_pageapi(). I haven't dug too deep so I'm not 100% sure if such a hook exists in D7/D8.
Comment #2
donquixote commentedMight be a stupid question..
What exactly is the reason why advagg preprocess page has to run last?
----
Btw, some related discussion on gdo:
pageapi.module - providing a place between hook_init() and hook_preprocess_page()
CSS and JS alteration hooks module
Comment #3
mikeytown2 commentedAdvAgg has to run last because any CSS/JS that gets modified in another hook_preprocess_page function will break AdvAgg. There isn't a good way around this in D6 currently.
I'm looking at your current need for PageApi and AdvAgg can be used to to suppress CSS/JS aggregation on that page load. You can also modify JS settings in here as well. I do admit that fixing how drupal_add_css works would be good.
Comment #4
donquixote commentedI wonder, what is the typical use case where a module wants to modify js and css? Do those modules add new scripts and styles, or what exactly are they doing?
If they just play with the aggregation, then there is no reason why they need to be enabled if you have advagg..
hook_preprocess_page() is too late for drupal_add_js() and drupal_add_css(), so these modules can only alter the $vars['scripts'] and $vars['styles'].
Btw, I probably researched that myself long time ago, just don't remember anything :)
Comment #5
mikeytown2 commentedUsually they are replacing or removing js or css files and compressing the aggregates. They want to do something not supported by the core's drupal_add_* functions.
Comment #6
donquixote commentedOk, so this means, these modules need to have the $vars['styles'] and $vars['scripts'] available as strings, as it is expected from Drupal core. So it would be not wise in this case to suppress that.
So I guess I should rather look at these other modules, if it would make sense for these to do something in hook_pageapi() instead of hook_preprocess_page().
Atm my use case is something quite unrelated to js/css aggregation. I just think, if I am grabbing template_preprocess_page(), then I have some responsibility to other modules that want to do the same.
Comment #7
donquixote commentedLooks interesting,
http://google.com/codesearch#search/&q=%5C$vars%5C%5B'styles'%5C%5D&type=cs
Comment #8
mikeytown2 commented99% of the code examples can use an advagg hook to accomplish the same goal. That is the master plan ;)
Comment #9
mikeytown2 commentedClosing this issue http://drupal.org/project/pageapi