After subscribe or unsubscribe, non-super users locked out of entire site.

I finally moved the entire site to a platform with a PHP debugger. I could not find any thing. Drupal seemed to be running to completion without error.

So I started deactivating modules. I hit upon RealName (7.x-1.0-rc2). With that module disabled, the submit for join (subscribe) and remove (unsubscribe) works again. The odd thing is that no other forms with submit were having a problem. It seems to be something particular about Real Name and Organic Groups.

Any Ideas?

I have also opened an issue for the realname module at 1341868. I cannot determine if og is the issue or if the problem resides with realname.

This is caused by a loop, though I do not know enough to assign fault.

1. It begins with og.module (287) in the user_load_multiple function.
2. This eventually causes a user entity to be loaded
3. This will cause the hook_user_load to be driven for realname.
4. Reaname performs an update, triggering a token_replacement.
5. This eventually drives a hook_field_access which og_field_access has implemented.
6. og_field_access then eventually causes an og_load_entity.
7. This starts another entity_load, thus begins the recursive loop.

This is locking out other members. This seems to be a major issue. Normal>>Major ??

Attached is a captured image of the call stack. Most recent calls are at the top. The area highlighted in the red rectangle is the area that keeps repeating. In this case, I decided to quit after the 46th interation. The image only shows the initial setup, one complete segment that is repeated, and part of the next repeat segment.

I'll try to set that up. On the development system I finally found the out of memory (132MB) error message.

I did the following:

Fresh install of Drupal 7.9 (standard profile)
created a test member account
Fresh install of Entity 7.x-1.0-rc1
Fresh install of OG 7.x-1.x-dev (based on 11/10/11 date)
enabled Entity, OG and OG UI.
Added test content types for group and group content
Added one group and one group content node.

logged in a test member:
navigated to node/1/subscribe
subscribed to the test group -- OK
unsubscribed to the test group -- OK

As super user:
added and enabled token module 7.x-1.x-dev (based on 11/09/11 date)
added and enabled realname module 7.x-1.0-rc2
added text field to user for displayname
configured realname to use new textfield.
Tested realname -- OK

back at regular test member:
subscribed to the test group -- OK
unsubscribed from the test group -- OK

As super user:
enabled OG Field Access

As test member:
subscribed to test group -- Failed: out of memory
unable to access any page on website.

as super user:
still able to access website.
disabled realname.

As test member:
Now able to access website.
The subscribe above had succeeded.
unsubscribe from test group -- OK
subscribe to test group -- OK

The problem is the recursive call to entity_load noted in #2.

1. An entity_load of the user entity drives realname_user_load hook.
2. That hook calls token_replace. This eventually drives any module_field_access hooks
3. og_field_access_field access causes (indirectly) another entity_load of the user entity which is recursive.

Is there anyway that og_field_access can determine that the entity was already loaded?

After spending more time and thinking on this, I went back to trap the call to og_field_access_field_access. The call is for the field used by realname, which in this case, has nothing to do with OG. The issue here is that this is a field that is associated with the user entity which in itself is also associated with OG. This is causing OG to issue an og_load_entity (line 1946 og.module) which begins the recursive activity.

Somehow, OG has to be smart enough to know that a field on a user entity might not be a og field.

The reason the super user continues to work is that this is all bypassed by line 1823 og.module for uid == 1.