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.I just ran into a compatibility problem with a module of mine, which uses hook_boot() to set up an SPL autoloader for some external code.
The problem lies in that _securesite_user_login(), which is triggered (indirectly) from securesite_boot, invokes user_authenticate_finalize(), which in turn invokes hook_login and therefore causes other modules' hook_login implementation to run, BEFORE their own hook_boot implementation, causing this type of problem.
An easy workaround is to set the module weight of securesite to 1 more than any other module implementing this hook, so maybe it should be done upon install (which wouldn't work for other modules installed later), or even simply documented.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | securesite.install-382572-1.patch | 1.78 KB | Darren Oh |
Comments
Comment #1
Darren OhTry this patch.
Comment #2
fgmAs a workaround, it looks fine. You could also save some code by just invoking securesite_update_6201() from securesite_enable(), since this is exactly the same code, inlined.
However, IMHO this does not really solve the issue, which is dependence on the login step during the boot step for the same session. If another module implements a similar system, it is likely that they will trip on each other.
Considering the role of Secure Site, maybe this can't be avoided, but then maybe it would be better in that case to have two independent loads be performed, one of them being minimal (emulated ?), and rolling just the S.S. login, and the other completing the normal login sequence with all hooks being fired normally. That way, the login/boot dependency loop could be opened. Just an idea...
Comment #3
Darren OhIt may be a bug for modules to assume that log-in will only occur after boot is complete. However, I will look into to this more.