The fact that you're using hook_boot() is causing problems because language_cookie_set() is calling drupal_alter('language_cookie', $cookie) and that itself is then calling module_implements() which is now happening far too early in Drupal's bootstrap. An example is the pathauto module where when language_cookie got installed and then cache got cleared again, the module_invoke_all('pathauto', 'settings') does no longer get hooks for modules that get loaded later than language_cookie.
The solution to the problem is quite simple: rename language_cookie_boot() to language_cookie_exit() and the result will be exactly the same and you'll never get close to breaking anything else anymore.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | 2463727-3.patch | 722 bytes | stefan.r |
Comments
Comment #1
jurgenhaasThere is one side effect that I just experienced myself: when files get downloaded then they start sending content before the exit hook and therefore the setrawcookie() doesn't work anymore. But that's no issue as I don't think that for file downloads you would want this functionality to work anyway. THe solution would therefore be to use a silent warning prefix like
@setrawcookie();.Comment #2
stefan.r commentedSee also #496170: module_implements() cache can be polluted by module_invoke_all() being called (in)directly prior to full bootstrap completion
Comment #5
stefan.r commentedPatch against 1.8 and 2.0-rc1 included. Would this fix the issue? (would rather not change too much and stick to hook_boot() for now)
Comment #6
jurgenhaasThis looks pretty dangerous as it is going to call other callback/hooks that may unintentionally call functions that are either not loaded yet or that will populate static variables far too early with potentially terrible side-effects. Using hook_boot is fairly dangerous and as the documentation for hook_boot says, "most include files" won't be loaded when this hook is going to be called.
Comment #7
stefan.r commented@jurgenhaas your concern is addressed in the core issue #496170: module_implements() cache can be polluted by module_invoke_all() being called (in)directly prior to full bootstrap completion (and related).
This patch was done so as to not break BC in any way, ie. not with the alter hook, nor with the hook_boot implementation. While this may look dangerous, this piece of code is a copy of the core hook
bootstrap_invoke_all(), which is there exactly for the purpose of being used duringhook_boot(). So all of the 3 calls to other drupal core functions ought to be safe here and should not cause cache contamination, even when called duringhook_boot().So while for the previous call to
drupal_alter()duringhook_boot()your concerns definitely applied, I don't know that they do in this case.However, if anyone implements a
hook_language_cookie_alter()that calls a hook that it shouldn't, that's another story. Maybe we can document another warning in a comment?Comment #10
stefan.r commentedNew releases for both 1.x and 2.x posted.