Posted by mrfelton on March 21, 2009 at 10:11pm
| Project: | Javascript Aggregator |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | derjochenmeyer |
| Status: | closed (fixed) |
Issue Summary
This is a strange one... javascript_aggregator is doing its thing. The .jsmin.js files are being created, and the $scripts variable appears to be updated correctly in preprocess_page to reference the minified version rather than the standard one. However, when the $scripts variable is printed in my page.tpl template, the non-minified version is output. The strange thing is that I have tried inserting a dsm() call to show me the contents of $scripts right before the line that prints it in page.tpl, and I can see that it DOES reference the minified version. But on the very next line when the $scripts variable is printed to the stdout, it references the non-minifed version, and that is what my browser gets! Any ideas what could be going here?
Comments
#1
update: ok, so I had a caching issue which was skewing this a little and after disabling all of my caches, doing a dsm of $secript in page.tpl itself actually does show that it references the non-minified version... I have since managed to get javascrip_aggrigation to work, but only by adding this in my theme's template.php:
function mytheme_preprocess_page(&$vars) {
$vars['scriptsmin'] = $vars['scripts'];
}
and then referencing $scriptsmin in page.tpl.
So, when my theme's preprocess_page function is run, $scripts contains the correct js, but at some point between here, and actually printing the variable, it is being reset.
#2
Do you have jquery_update installed?
We need to do 2 things in order to keep Javascript Aggregator working.
/*** Implementation of hook_theme_registry_alter().
*
* Make jQuery Update's page preprocess function run *after* everything else's,
* so that a theme can't call drupal_get_js() and mess everything up.
*/
function jquery_update_theme_registry_alter(&$theme_registry) {
if (isset($theme_registry['page'])) {
// If jquery_update's preprocess function is there already, remove it.
if ($key = array_search('jquery_update_preprocess_page', $theme_registry['page']['preprocess functions'])) {
unset($theme_registry['page']['preprocess functions'][$key]);
}
// Now tack it on at the end so it runs after everything else.
$theme_registry['page']['preprocess functions'][] = 'jquery_update_preprocess_page';
}
}
We can do the same
/*** Implementation of hook_theme_registry_alter().
*
* Make javascript_aggregator's page preprocess function run *after* everything else's (even jQuery Update),
* so that a theme can't call drupal_get_js() and mess everything up.
*/
function javascript_aggregator_theme_registry_alter(&$theme_registry) {
if (isset($theme_registry['page'])) {
// If javascript_aggregator's preprocess function is there already, remove it.
if ($key = array_search('javascript_aggregator_preprocess_page', $theme_registry['page']['preprocess functions'])) {
unset($theme_registry['page']['preprocess functions'][$key]);
}
// Now tack it on at the end so it runs after everything else.
$theme_registry['page']['preprocess functions'][] = 'javascript_aggregator_preprocess_page';
}
}
Attached is an .install file and a patch for javascript_aggregator.module (6.x-1.x-dev, 2009-Mar-23) which sould solve this issue.
To get this working:
function javascript_aggregator_theme_registry_alterfrom above manually)Please test.
#3
#4
Fixing the comment of
hook_theme_registry_alterfor Javascript Aggregator inspired by jQuery Update. Use in combination with javascript_aggregator.install from #2.#5
nice, same issue
and your patch/install mod did the trick (latest dev)
combined with CSS Gzip, I just saved 200k css/js from my front page, verycool...
#6
Thanks for your feedback. I'll include it in the next release of Javascript Aggregator.
Anyone else who tried this patch? Please test.
#7
Added this to current dev.
#8
Automatically closed -- issue fixed for 2 weeks with no activity.