Deleted groups causes EntityMalformedException in og_is_group().

I cannot reproduce, clean install, added 2 groups (and 1 group content for each group).

Deleting a group does as you say leave the reference in user object (og_user_node), however I am not getting any errors when trying to create new group content (the deleted group is simply not listed under group audience).

I just wanted to chime in even though this issue has been closed. After quite a bit of poking through the database, I found I was getting this exact error because there were deleted group names/fields still present in the "og_memebership" table/"field_name" field. Once I deleted the offending rows in the table, the error went away.
Hopefully this helps someone else.

I get the provided error as well on og_is_group(). While trying to reproduce that error on a clean install I managed to get an EntityMalFormedException in a different way. This time og_group() failed.

Steps to reproduce the failure in og_group():

1. Enable modules og, og_ui, og_access.
2. Create a node type used as group.
3. Create a node type used as group content.
4. Create a role with permissions to create, edit and delete own group and group content nodes.
5. Log in as an user with this role.
6. Create two group nodes.
7. Create group content node, assign to both groups.
8. Delete the first created group.
9. Go to the node edit page of the group content.
10. Click "Save".

Boom! EntityMalFormedException.

Note: after flushing caches, there is no longer an EntityMalFormedException when editing and saving the group content.

Attached a test that more or less follows above steps.

I'm hoping to find out how to reproduce it for og_is_group() as well.

Changed title to better reflect differences with #1559766: EntityMalformedException when deleting users, in og_get_user_roles().

Okay, I got a EntityMalformedException inog_is_group() reproduced as well! Steps are similar to what I described in #5.

Steps:

1. Enable modules og, og_ui, og_access.
2. On the OG settings page (/admin/config/group/settings), enable the "Use queue" option.
3. Create a node type used as group.
4. Create a node type used as group content.
5. Create a role with permissions to create, edit and delete own group and group content nodes.
6. Log in as an user with this role.
7. Create two group nodes.
8. Create group content node, assign to both groups.
9. Delete the first created group.
10. Do something that checks if the current user may update the group content, using a node_access() call. For example a View with your own nodes that includes a Views edit link (views_handler_field_node_link_edit).

Boom! EntityMalformedException!

I added a test to demonstrate the exception with a node_access() call.
Also attached: stack trace (result of the test).

Hm, testGroupContentNodeAccessAfterDeletingGroupAndWhenUsingQueue() did not fail on the testbot while it did locally.

Let's try that again, but then using an actual page.

I made some mistakes in the last test. It would not pass when the bug would have been fixed.

After inspecting the stack trace for testEditGroupContentAfterDeletingGroup() it looks like that results into the issue in og_is_group() as well, which means that what I did manually in #5 is not properly covered by an automated test yet. But that could be handled in a follow-up as well.

Attached tests + fix for og_is_group().

Great! Tests are passing. I created a pull request of the patch in #10:
https://github.com/Gizra/og/pull/429

https://github.com/Gizra/og/pull/429 has been merged into 7.x-2.x on GitHub which is great. It still needs to be synced back to Drupal.org. We should probably leave this at "Reviewed and tested by the community" until that happens.
@MegaChriz, is #1673472: Deleting groups does not delete the group member users group audience references to the group the followup you're talking about? Is anything other than that remaining?

Hi,

I applied the patch 10# to version 7.2.10 and the error went away.

My question is, is this related to same issue which did not went away:
In short, when a group has members, and the group node is deleted by site admin using a views which has a delete link,
the user data is not removed from the "og_membership" table and the user is not able to join to a new group.

The problem does not exist when the group admin deletes the node
or when the site admin deletes the group node from the Drupal core content -list.

To reproduce:
1. Create a node A which is a group. Add a user X to the group.
2. Create a views table (content) which has a list of group nodes and add a delete link
3. Delete the node A using the views delete link.
The problem: The user X data in the "og_membership" table is not removed.
This causes a problem; the user X is not able to join to any group.

Everything works when the group node is deleted by the group admin (from the node/edit page)
or by the site admin from the Drupal core content list "delete" link.

Is this a bug in OG or in my views ?

EDIT: removed the VBO mentioned, same problem comes just with the delete link -field.

I have #10 applied and I still managed to get the same exception reported in the OP by using og_is_group() in an access callback and passing it a string rather than a group ID. Of course the string should never pass access checks, but a 403 would be preferable rather than a WSOD :)

The attached patch considers also this case.

Other than that, this looks great to me, thanks!

I agree with #14, event though the patch did break current 2.1. I try again with dev later. Thanks for the fix!

Hello,
I've been having the same issue but directly on og_group, when the group was removed i could get to og_group and it tried to load the node for a gid which doesn't exist, generating an issue on entity_extract_ids. I'm uploading here a patch to cover that too.

@dharizza The patch in #16 looks like a further addition to the patch in comment #14. It would be better to combine them into one patch.

The patch in #14 has already been committed in the og git repository and og-7.x-2.x-dev (2019-05-09).

This leaves the patch in #16 as a new patch that does apply without difficulty and that needs review.

@dharizza Your patch looks more comprehensive. But, it seems to also change some of the variable names. I could see where this might cause issues further down in the function.