Closed (fixed)
Project:
Subgroups for Organic groups
Version:
7.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
12 Jun 2013 at 15:43 UTC
Updated:
30 Dec 2013 at 20:26 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
mpotter commentedHere is the patch.
Comment #2
mpotter commentedOops, here is the patch without the debug statement.
Comment #3
mpotter commentedFinally, here is another one without the whitespace issue that should apply more cleanly with other patches.
Comment #4
mpotter commentedFound that a recursion loop could also be caused in the og_subgroups_get_parents routine, even with the existing check of _og_subgroups_parent_search. This is because the $parents array actually gets modified later in the routine. Leave it to the customer to find just the right combination of parent data to cause these recursion problems.
In any case, here is another patch to prevent infinite recursion. Combines the previous patch with the new routine and adds a constant for the recursion depth.
Comment #5
mpotter commentedSigh. Bad copy/paste in watchdog message fixed.
Comment #6
mpotter commentedWow, I'm horrible this morning. Let's try this again without rolling in a bunch of other patches. The patch in #5 also included #1985514: Undefined index: und in _og_subgroups_get_unique_parents() , #1993944: Provide a field settings for og_subgroups_get_associated_entities so it doesn't need to fetch and load all content, #1995018: Show child groups when creating content when og_group_ref/og entityref field is using og group selector.
Here is another version that is just for this issue.
Comment #7
kenianbei commentedThanks for the patches. Will review soon.
Comment #8
kenianbei commentedHi mpotter,
I've added a new patch here which changes quite a bit of the current code. It also removes the need for this patch. If you have time please review the patch and let me know any feedback. Thanks!
Norman
Comment #9
hefox commentedWhen fixing issues, the status to set is "fixed". The issue queue bot will come around in 2 weeks and set the closed (fixed) status.
However, it looks like there has been no commited code for this? If it was an duplicate, the status would be closed (duplicate), but as there's a patch that fixes it in a different way, "postponed" would likely be the better status -- indicate that this is still an issue, but postponed on the other issue getting in.
Comment #10
mpotter commentedThe latest code has og_subgroups_children_load_multiple() so this patch no longer applies. It also has code for detecting recursion now.
Comment #11
mpotter commented