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

MarcElbichon’s picture

MarcElbichon CreditAttribution: MarcElbichon commented
Issue summary: View changes

typo

jpwester’s picture

jpwester CreditAttribution: jpwester commented

I am definitely in favor of this also. This is causing issues when using Rules with Shibboleth/CAS.

mitchell’s picture

mitchell CreditAttribution: mitchell commented
Assigned: Unassigned » zhangtaihao

@zhangtaihao, if may I ask please, what are your thoughts?

zhangtaihao’s picture

zhangtaihao CreditAttribution: zhangtaihao commented
Assigned: zhangtaihao » Unassigned

So 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.

MarcElbichon’s picture

MarcElbichon CreditAttribution: MarcElbichon commented

Why 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

jpwester’s picture

jpwester CreditAttribution: jpwester commented

Is 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?

jpwester’s picture

jpwester CreditAttribution: jpwester commented
Issue summary: View changes

typo

kmorozov’s picture

kmorozov CreditAttribution: kmorozov commented
Category: Feature request » Bug report
Issue summary: View changes

Changed to bug. Added steps to repro.

Plecto’s picture

Plecto CreditAttribution: Plecto commented

I'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??

Plecto’s picture

Plecto CreditAttribution: Plecto commented

I'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??