Cannot use stdClass as array

Hi pbarnett,

Thanks for letting me know. I've modified the code and uploaded what's hopefully the fix, although I was unable to reproduce the error. If you could let me know if this fixes it, I'd greatly appreciate it. If not, and you could report any new symptoms and tell me anything that might be relevant about your setup, I'd like to try again.

You'd said the module made your site stop working - I hope it started working again when the module was turned off?

I believe the problem was caused by how I was determining which groups a user is effectively in. This was done already in the og.module by setting the $user->og_groups array, so og_subgroups.module had to override this to allow "effective" memberships - that is, membership in a group if you're a member of a subgroup, but not an immediate member of the group itself.

I think my mistake was that I was not making elements of the og_groups array arrays themselves, but rather making them stdClass objects. When the og.module looked at the og_groups array, it was upset that its elements weren't themselves arrays. I've changed this in the updated version I've just uploaded.

I've (hopefully) fixed the bug you found in #2, which incidentally was simultaneously found by as http://drupal.org/node/82375 #1. Sorry about that - I'll hopefully look at #3 and #4 soon, but my new job training starts tomorrow so my schedule is less in my control for a few days.

More detail on the bug: the problem was that, on installing the module, a nodeapi insert was faked (as in og.module) for each group that didn't have a term in the Groups vocabulary yet. This insert created the term, but also called the same functions that handled the creation of a new group. These functions looked to see which members and subgroups were selected and saved the selection. Because the insert was called from the install of the module, not the creation from scratch of a group, there was no form input to draw from. Therefore, there was the error message (because the array didn't exist) and the memberships were erased (because the functions were setting the members and subgroups to equal the set of people and subgroups in the nonexistant arrays). The fix was just to have it see if the arrays exist, and if not, skip calling those functions - so, the functions are only called now when there's a true insert of a new group, and skipped when there's a fake "insert" of a group that already existed and is only "new" in the sense that it didn't have a term in the vocabulary before.

Hi pbarnett,

On #3:

I am also seeing

localsite/node/og_node_id/members

as the home page. The URL og_subgroups.modules uses to show members is:

localsite/node/[og_node_id]/view/members (note the "/view/")

and the URL og.module users to show (immediate) members is

localsite/node/og/users/[og_node_id]

I'm not sure what you're expecting to see at

localsite/node/[og_node_id]/members

or if it's something that I've inadvertantly changed. If you could help me understand, I'll get back to work on this.

Thanks!
Don

For #4, I've been hoping to add the requested feature (hierarchical main groups page) but haven't found the time. My job is going to start soon, and I'm going to have less time to work on this. Therefore, I'll just suggest the quick fix of making a group called "All Groups" and putting in whatever groups you like as subgroups of that. Then, put a link to "All Groups" in your menu... Not the same as overriding the default groups page, but hopefully equivalent for most purposes.

On a related note, if anyone sees this and wants to develop for this module, please let me know - I can't give it the full attention it deserves, but hope to give it nonzero attention.