Encountering fatal error after upgrade

I'm seeing the same errors whenever anonymous users view any nodes that are related to subgroups, as well as when accessing views that list subgroups. Displays a rather ugly "unexpected error corrued on the site" message to the user. Reverting to 7.x-2.0-beta1 also fixes the problem for me.

Hi,

I also encountered the same problem when I am going to save parent group for a sub group. Reversing back to '

7.x-1.x-dev tar.gz (11.51 KB) | zip (13.4 KB) 2013-Oct-01

' is fixed me the error. It now the functionality also working fine.

- John

Same error on a fresh install of both OG and OG Subgroups. Cannot create subgroups. Reverting to 7.x-2.0-beta1 fixes it for me.

Same problem here. I upgraded from og_subgroups_7.x-2.0-alpha2+0-dev with patch #5 from #2407399. The uberadmin can access all group pages without a problem. A non-admin gets the fatal error on every group page whether or not they are a member of that group.

Clearing the cache did not help, and as the OP points out there is no db upgrade to be performed.

Just encountered the same problem. In my case, I have a View that lists all the Organic Groups on the (test) site, each Group displayed linking to the Group itself. I have two Groups, and two users, each of which is manager of one of the Groups. When a user clicks on the link in the View to consult the OG of which he is not the manager, I get this error message

I'm thinking this should be upgraded to critical. It definitely meets the "render the system unusable" criterion. I don't know what percentage of people are experiencing it, but we've had 6 people report it in this issue in the last 10 days, so I'm guessing that's more than the fatal error "under rare circumstances or affecting only a small percentage of all users" criterion (which would mean it was correctly categorized as major.) If I'm wrong, feel free to put it back.

Same problem.

Apparently 7.x-2.0-beta2 introduced a new field/option for permission inheritance, which enables users to gain additional permissions in subgroups based on permissions in a parent group they are a member of.

Problem is: The module just assumes that the field exists for each group. This will never be true for existing sites which just updated the module (leading to the fatal error) and may not be true even for new sites, if this field is not explicitly created for each group type.

Additional problem: In og_subgroups_og_fields_info() the field_name is wrong for the new field, so it's generally impossible to create it.

Quick fix:

1. og_subgroups.module, line 70: Replace OG_USER_INHERITANCE_PERMISSION_CHILD with OG_USER_INHERITANCE_PERMISSION_FIELD
2. og_subgroups.module, line 266: Add
   

   foreach ($ids as $k => $gid) {
     $group_entity = entity_metadata_wrapper($group_type, $gid);
     if (!isset($group_entity->$field)) {
       unset($ids[$k]);
     }
   }
   if (count($ids) == 0) {
     return;
   }

There may be a better solution for this, but mine seems to work for now…

Did you insert that code right after the $child_inheritence = _og_subgroups_get_field_matching($parent_group_type, $ids, OG_USER_INHERITANCE_PERMISSION_FIELD, OG_USER_INHERITANCE_PERMISSION_CHILD); line? Your solution didn't worked for me, I got the same error message (after cleaning cache etc.)

Working on this. One other issue with the beta2 is #2185849: How to create a view of subgroup content where there was a missing file that was causing errors in ctools plugin autoloading. Now that those errors are gone, I'll focus on the errors in this post.

Issue 1 from #9 is handled/fixed in this new issue: #2590217: Incorrect field name used for Permission inheritance

So, I think the core problem here was the incorrect field name that is fixed in #2590217: Incorrect field name used for Permission inheritance. Once that is applied, then Drupal *should* see the existence of the field definition even if you haven't placed it on any groups yet. Just like with any other optional OG field.

However, in case this still doesn't fix it, here is a patch that prevents the child permission check if the field definition for OG_USER_INHERITANCE_PERMISSION_FIELD doesn't exist. This is more direct than the code in #9. Also, the code in #9 would cause performance issues since it causes the group nodes to be loaded in order to fetch the wrapper. Since entity_metadata_wrapper causes an entity_load, we need to be more careful with where this is used (thus many of the recent performance improvement patches).

If we can get confirmation that either #12 or #13 fix this issue then I can roll a new release asap.

Edited: Also be sure to apply the fix in #11!

Anybody?? I don't want to commit #13 unless it's really necessary. I'll do a release with #11 and #12 and without #13 if I don't hear from anybody.

I've been really anxious to test this but got caught up in some more urgent work. I was planning to test it this weekend or Monday but I can try to do it this evening if you're about to roll a new release. Let me know your timeframe and I'll try to prioritize this.

I'm going to start by saying that I'm not great at this and I'm using the Patch Manager module on a clean drupal install.. So if I'm being silly, let me know.
Anyways, clean drupal with OG and OG subgroups 7.x-2.0-beta2 and their dependencies.

Patch 16 from #11 doesn't apply which is expected since it's 6 months old.
Patch from #12 applies but doesn't fix the issue when I move the folder into my dev.
Patch from #13 either without or after #12 gives a server 500 error for the whole site.

I tried to patch them with the latest dev from October 15th and #11 + #12 don't apply and #13 still gives a server 500 error.

Also, the dev doesn't fix the issue. Get the below when I view a group.

Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 64 bytes) in C:\wamp\www\edlogin_local\sites\all\modules\og_subgroups\og_subgroups.common.inc on line 272

Could you upload your patched module for me to test or let me know where I went wrong?

OK I downloaded the latest dev, which already has the patches referenced in #11 and #12 (plus the patch I had mentioned in #5 that I had previously applied), and tested that on my site to see if it solved the issue. However, I continued to get the EntityFieldQueryException: Unknown field: og_user_inheritance in EntityFieldQuery->addFieldCondition() (line 817 of <snip>/includes/entity.inc) error. And now I got it in every page, even non-OG pages.

So then I applied the patch in #13 but I get the following fatal error: EntityFieldQueryException: Unknown field: og_user_inheritance in EntityFieldQuery->addFieldCondition() (line 817 of <snip>/includes/entity.inc).

I tried running db update but that page is WSOD.

Next steps?

Wow, I wish I knew why I can't reproduce those errors.

niallmurphy-ie: Using the latest -dev to get #11 and #12 is the correct method. The patch in #11 doesn't apply because if you read the whole issue you'll see at the end it was reverted and reapplied, and there isn't a specific patch file for that re-commit.

Not sure why #13 would give a WSOD or server error 500.

BrightBold: I'm particularly interested in your test case. The code added by patch #13 is the same code that Drupal uses to generate that error exception in line 817 of entity.inc.

      $field_definition = field_info_field($field);
      if (empty($field_definition)) {
        throw new EntityFieldQueryException(t('Unknown field: @field_name', array('@field_name' => $field)));
      }

So I'm not sure how the patch from #13 would be failing to stop that error. Is there any way you can add a:

print_r(debug_backtrace())

just before the "throw new EntityFieldQueryException" link in /includes/entity.inc so we can be sure exactly what code in og_subgroups is causing this?

EDITED: Btw, I assume you cleared cache after applying the patches?? That will be needed for Drupal to see the field definition patched in #12

Can you upload your patched module so I can check? And are you testing on OA or vanilla?

niallmurphy-ie: The dev version from Oct 15th has the patches you need. You just need to manually apply the one in #13, but it sounds like you have already done that. Nothing else for me to upload.

Maybe you can post your exact testing procedure? What kind of content are you creating on your fresh Drupal install? What kind of Group content type did you create and what options did you give for it to enable the subgroups functionality. That kind of information should help me reproduce this on a clean install.

Nevermind, I was able to get a clean D7 + OG-related-stuff site going on my local dev and reproduced the error. Working on it now.

OK, here is a new patch to test on the latest -dev version. Turns out it wasn't just the OG_USER_INHERITANCE_PERMISSION_FIELD field. The problem was the new helper function _og_subgroups_get_field_matching() that was added that does the field query. I added the test for the field there so it handles *any* fields that are not defined yet. This fixed it in my clean D7 test site, so let me know.

Got some others to replicate this and verify #23 seems to fix the issue. Since this is a Critical and the previous release is so borked, I'm going ahead with a commit and release of this today. Committed to 60f9377.

I thought it was still broken but finally realised that between all the testing and mucking about, one of the nodes I was testing had somehow ended up og_group_reffing itself.

Good work. All errors seem to be gone.

Sorry I couldn't help to test this, the error had gone away for me and I have no idea how or why!