At Genuine, we’re getting ready to tackle some sites that have the need for groups of content (and users), so I was tasked with checking out the current state of the modules that are out there right now. There are currently two modules that aim to solve this specific problem: the “OG” module that’s been around since Drupal 4 (Drupal 4) (Organic Groups) and the newcomer looking to dethrone the status quo (Group). We decided to come up with a theoretical site outline to see if either module could provide an architecture with the following requests:
- Users should be able to sign up to the site and either join or create a group for their company (provide basic company information).
- That user becomes the “owner” of the company and can add other users to the “company” group.
- Within the company there can be “project” teams.
- Any company user can create a “project” within their “company” and assign people project roles of “developer”, “project manager”, “legal team.”
- Within a “project” group and member can create a “product” group, which has a product team.
- The product team can create basic page only viewable by people on that team.
To outline the site structure, we’re looking at something like this:
What we’re looking at is groups of groups (of groups). With this in mind, let’s break down each module.
The Organic Groups module is the granddaddy of Drupal group functionality. In fact, I remember building a community website with the D6 (Drupal 6) version of OG way back in the day.
Which brings us to the D8 (Drupal 8) version of OG…or lack thereof. There is currently a dev version, but as of right now, there is no official release of Organic Groups for D8 (but it’s in active development — https://www.drupal.org/node/2591017).
What does this mean in practical terms? Well, the module does work similarly to the D7 (Drupal 7) version, but with some rather sizeable caveats:
- In the current dev version, members can’t be added to groups without this patch: https://github.com/Gizra/og/pull/231.
- There’s also work being done to add field_ui integration to OG membership types that will probably change some things: https://github.com/Gizra/og/pull/222
- I couldn’t get both of these patches working together, so I wasn’t able to test out the field_ui integration.
- The group permissions aren’t configurable as they were in D7.
The real question at hand is, “does the OG module allow us to create the aforementioned site architecture?” The answer: eh, kind of.
As in previous versions of the module, the group functionality is added to pre-existing nodes. This allows the node access permissions to be inherited by the groups, but, as of now, custom per-group permission configurations do not exist.
Subgroups, on the other hand, come built into the Organic Groups module. When you’re creating the content types to add group functionality to the node type, you have the ability to designate it as either a Group and/or Group Content. This allows for the content to easily be both a group, as well as content for another group at the same time.
And the last positive for the OG module is the built in Views integrations. While the module itself doesn’t come with any helpful views, building them out is relatively straightforward. For instance, I managed to build two blocks: one that lists all the content of the group and one that lists all the members of the group. Both of these worked well, even in nested groups.
Unfortunately, there are some downsides:
- Since the groups functionality is built around content types, the groups themselves show up in the Content Admin list (/admin/content) along with the other content on the site.
- Any group-specific menus have been historically handled by third party modules, of which none have been updated to D8 as of yet.
- There isn’t a good way to create group-specific content from within a group, either. Creating content is the same as creating any other node, but requires the Group Audience field to be filled out to associate it with a specific group. There is the entityreference_prepopulate module, which is supposed to help. But of course it doesn’t have a D8 release yet, either.
The Group module (https://www.drupal.org/project/group), on the other hand, does have a D8 release; albeit a beta one. As with the Organic Groups module, the Group module’s D8 version is more stripped down than the D7 version.
The main difference between this module and the OG module is that the Group module relies on entities and entity relations to handle everything instead of tying themselves to nodes. Having said that, there is a Group Node submodule, but this only allows nodes to be able to be added to a Group entity.
The good thing about groups in the Group module is that the admin is self-contained. The module adds a Groups button to the admin menu, and all of the group related materials are housed inside. This is where the groups are listed, along with the group types and (global) settings. Unfortunately, the UI is pretty sparse at the moment; for instance, there’s no way to filter the list of groups by group type so all you have is one long list of groups. The Settings tab also only has a single setting: whether or not to use the admin theme when editing groups/members/etc. Probably should be the Setting tab for now.
Other than that, the UI for Groups is pretty good. Adding groups and group types is pretty straightforward and more fully featured than the current OG interface.
The module also creates a Group operations for group content creation out of the box, and Views integrations that allow you to easily create member and subgroup listings.
Unfortunately, nesting groups inside each other doesn’t come by default with the module. The D7 version has a Subgroup submodule, and it’s currently being ported to D8 here: (https://www.drupal.org/node/2736233). It’s workable in a “you can add groups as available content (see image above) in the group settings” kind of way. But, there’s still a decent amount of work left to figure out how it’s actually going to be accomplished. Right now, nested groups seem to exist in two spaces: as child content of its parent group AND its own group (with its own children). These two ideas can be seen in the different URLs that you can use to get to the same content. Here’s a quick example:
Let’s say we’ve created a Company called Genuine (URL: /group/1). Within this company, we create a Division called PHP Team. With the Group module, the PHP Team entity exists in 2 places:
- As child content to Genuine at /group/1/content/3 that looks like this:
2. As its own group with its own group content at /group/2:
We can see that all of the group-related blocks and tabs change depending on the URL used to access the entity. I think this has to do with nested groups not being a part of the original plan when development of the Group module began, as I heard an interview with the developer when the module was first released where he mentioned that he didn’t see a need for nested groups.
The other caveat with the Subgroup submodule – and this is a big one – is that access controls haven’t been figured out just yet. There are a lot of conversations going on about how they should be handled in terms of inheritance, but this is the big outstanding strike against the Group module. In my testing, the group-specific permissions worked fine, but the inheritance of permissions from a parent group to a child group is wonky at best. Going back to the previous example of the two different ways to access a subgroup: a group member can view a subgroup if viewing it as group content, but can’t view the actual content when trying to access it directly (without being added as a member of the subgroup directly).
Neither of these modules are quite ready for primetime just yet. While both of them are in active development, both are missing certain features that would make them a “plug and play” solution. Since I’m a visual person, here’s a table to show you what I mean: