jquery_update_preprocess_page() overwrite $variables['scripts'] [#965680]

jquery_update_preprocess_page() is overwriting the $variables['scripts']:

jquery_update.module line #84
$variables['scripts'] = drupal_get_js('header', $scripts);

This is causing problems with other modules that add code into the $variables['scripts'], see open issue here.

Could you solve this?

Thanks.

Comments

Comment #1

achton

Denmark

CreditAttribution: achton commented 25 January 2011 at 22:09

Subscribe.

Comment #2

stackpr CreditAttribution: stackpr commented 31 March 2011 at 22:59

noie6 was putting information into the $scripts block that could not be added via drupal_add_js() at all -- otherwise, it could have been a trivial change to that module. Anything that adds standard JS to the $script at the preprocess_page step could be compatible with this module by also using drupal_add_js() so it would be preserved on regeneration.

I suggest that the change be made to noie6 instead of jquery_update, and I have submitted a patch on that issue #946232: Don't work together with jquery_update module. If a maintainer agrees, then this can be closed as a duplicate issue.

Comment #3

altrugon CreditAttribution: altrugon commented 28 April 2011 at 20:11

Witti you are suggesting that any developer that need access to the $scripts variable should forget about that idea and instead use the $head variable. I don't see why $scripts variable have to be owned by jquery_update module only, we all are trying to collaborate here in Drupal.

I think it would be a much efficient approach to replace the $variables['scripts'] = drupal_get_js('header', $scripts); by a $variables['scripts'] .= drupal_get_js('header', $scripts);, giving the possibility to other developers to use this variable too.

Comment #4

stackpr CreditAttribution: stackpr commented 12 May 2011 at 21:14

No one module needs to "own" the $scripts variable, but I was looking for a way to allow the modules to work together. jquery_update (and others like bundlecache) destructively recreate the JS that is rendered. However, without a core patch, they are unable to have their changes reflected in future calls to drupal_add_js(), at least in D6.

Your append suggestion would cause all script files to be included twice, which would not work, although I get your general point.

Since noie6 is strictly adding and not removing, it is the only one of the two modules that is currently capable of addressing the incompatibility without a core patch. So I am not suggesting that everyone has to bow to jquery_update. However, it seems that the choice might be between moving code incompatible with drupal_add_js() to the $head variable or requiring a core patch to allow both/either module to reset the static array contained in drupal_add_js(), and a core patch would make it much less friendly.

The other option would be to have jquery_update parse the $scripts variable to extract any JS file names rather than pulling them from the drupal_add_js() array. That would be a pretty major shift from 6.x-2.x, so one of the maintainers would need to comment on whether that method would be reliable enough for that type of patch to be approved if it were submitted.

Comment #5

alexweber CreditAttribution: alexweber commented 13 May 2011 at 17:35

This is an old gripe of mine and I guess one of the reasons why hook_js_alter() was introduced in D7.

That said, it kinda sucks that jquery_update owns $variables['scripts'] and it's pretty trivial to add an extra line of code to preserve the scripts array for other modules.

I'm at a client who blocks pretty much all internet access outisde of port 80 so I can't do it myself but it's just a matter of adding the following line of code at the end of this function:

$variables['scripts'] = drupal_get_js('header', $scripts);
// keep original array for use with headjs, labjs & other modules that might need it
$variables['scripts_array'] = $scripts;

There, now other modules can check for jquery_update and use $variables['scripts_array'] if they need to manipulate the array