Hooks are loaded in rules_init().
If other module with a smaller weight do user_login in its own hook_init(), events.inc is not loaded so, hooks are not triggered.
See #375265: login action not invoked when user logs in through login block for example
May be good to force rules_init to be processed first by adding this function :
function rules_module_implements_alter(&$implementations, $hook) {
if ($hook == 'init') {
$group = $implementations['rules'];
unset($implementations['rules']);
$implementations = array('rules' => $group) + $implementations;
}
}
I am having an issue with the same cause:
1. We have a module that authenticates users with a remot server. In hook_init, we call user_save.
2. If it happens that our module's hook_init runs before rules_init, then the events.inc is not loaded.
3. When user_save runs. It eventualy calls module_implements('entity_update').
4. Since events.inc is not yet loaded, module_implements caches that rules does not implement hook_entity_update.
5. Later, when an entity is updated, module_implements uses the cached value and rules_entity_update is not called.
Workaround:
We used hook_module_implements_alter to move our init to the end of the line. This is bad though because now if we had a third hook_init dependency we would have to do lots of sketchy scanning of the implementation array.
Solution:
Could we just require the events.inc inside rules.module? events.inc is part of the rules core.
If not that, then we need to have rules_init run first.
Comments
Comment #0.0
MarcElbichon CreditAttribution: MarcElbichon commentedtypo
Comment #1
jpwester CreditAttribution: jpwester commentedI am definitely in favor of this also. This is causing issues when using Rules with Shibboleth/CAS.
Comment #2
mitchell CreditAttribution: mitchell commented@zhangtaihao, if may I ask please, what are your thoughts?
Comment #3
zhangtaihao CreditAttribution: zhangtaihao commentedSo is this problem (a) events not being triggered or (b)
hook_init()
being triggered at the wrong moment?In case (b), the solution is ambiguous. A rule could succeed or precede the implementation of another module. A Drupal module has no acceptable way of enabling both. Truth be told, the need to hijack a hook implementation often indicates misuse/absence of a hook.
In case (a), the solution is simple: load
modules/events.inc
with the module. Conventionally, any non-lazy loaded hook implementation should be loaded with the module file. If this is indeed the problem, perhaps details of this issue should be updated to reflect as such.Comment #4
MarcElbichon CreditAttribution: MarcElbichon commentedWhy events.inc is loaded in hook_init rather than be defined in .info file ?EDIT : Forget my question. Files declared in .info files need to declare classes or interfaces
Comment #5
jpwester CreditAttribution: jpwester commentedIs there any update to this? I believe I'm still running into issues with Rules interacting with Shibboleth/CAS. Is there any downside to this feature request getting incorporated into Rules?
Comment #5.0
jpwester CreditAttribution: jpwester commentedtypo
Comment #6
kmorozov CreditAttribution: kmorozov commentedChanged to bug. Added steps to repro.
Comment #7
Plecto CreditAttribution: Plecto commentedI'm experience the same issue too,using the following configuration:
- Drupal 7.24
- Shibboleth authentication 7.x-4.0
- Shibboleth User Provisioning 7.x-1.0-beta4
- Rules 7.x-2.6
The code proposed by MarcElbichon also works for me, but I don't know if it has any side effect on any other Drupal module/behavior.
Is there any official solution yet for this issue??
Comment #8
Plecto CreditAttribution: Plecto commentedI'm experience the same issue too,using the following configuration:
- Drupal 7.24
- Shibboleth authentication 7.x-4.0
- Shibboleth User Provisioning 7.x-1.0-beta4
- Rules 7.x-2.6
The code proposed by MarcElbichon also works for me, but I don't know if it has any side effect on any other Drupal module/behavior.
Is there any official solution yet for this issue??