Organic Groups in Drupal 7
Organic groups (OG) for Drupal 6 are a powerful and widely used module for creating websites that include groups that are mini-sites in a larger Drupal site. The OG version for Drupal 7 is completely rewritten, embodying the advantages of Drupal 7 in the API for entities and fields.
One of the main differences between Drupal 6 and Drupal 7 versions is the development of the concept of what is a “group”. In D6, the group was a node and other nodes could be subscribed to it as the content of the group. In D7, any type of entity can be a group, and any type of entity can belong to a group.
In this article we will look at the whole architecture of OG and go all the way to build the initial group in D7
Take a look at the illustration below. You can see that a group consists of many different types of entities. In the center is the node itself, which is a group. The essence of the group "parent" for all who are a group.
')
Users and content are two kinds of entities that belong to a group. Each user and each part of the content joins the group with additional entities. Figuratively speaking, this is a simple entry in the table that keeps track of which entity is associated with a particular group.
In fact, in the current architecture there are two different types of entity “group. One is the type of content that you designate “group”, and the second is a special OG entity that you probably won't be implementing here. In essence, OG contains both the group itself and the group identifier (GID). This is one of the most confusing things about the OG architecture in D7. Keep in mind that GID and NID are two different things. This may change in the future, so read the links at the end of the article.
To get started with OG, we have to decide which type of entity will be the “parent”. In D6, this has always been the type of material, but in D7 it can be any type of entity. It will still be content of several types, but it is better not to do so. One example of another way is energy.gov, where groups are built on taxonomy terms.
For example, we will build a type of material called “group”, which will be a container, similar to what happened in OG version D6.
The next thing we need to do is determine which types of entities will belong to groups. We can use existing content types.
Group content is not limited to the essence of the node or the type of content. Other entity types may belong to a group. The available entities are limited only by the modules installed on the site. For example, if a meda-module is installed on the site, then the media entity may be included in the group.
Users are other, special content types of group entities. They join the group and are also “group membership” content, but in addition they have a number of properties and users can have roles and permissions to interact with the group.
Any type of entity can belong to a group. In fact, the group itself may belong to another group. This allows you to combine groups, creating subgroups.
Having built in our minds a diagram of how entities will interact with themselves, we can proceed to constructing this on the site, by downloading and activating the OG module. OGs depend on the Entity API module, so we also need it. (comment from the translator: “clean installation” requires modules: CTools, entityrefference, views bulk operations and views)
The D6 OG version was a monolithic module and practically gave everything out of the box to create a group. In the D7 version, we went the other way. Each task has its own module with its own highly specialized tasks. Part of the tasks carried out in separate projects.
Here are some of the projects submitted to separate modules:
Changes have also occurred within the OG core. For example, a module that came with an OG named OG Context.
OG UI is also rendered into a separate module. If you want to activate only the OG core and do not want to see anything related to OG in the administrative menu, then skip this module. The reason for this may be that all the groups you have already configured and you do not want to configure anything else.
In the version for D7, using the fields in the kernel, we use special fields to connect all these entities together. If you used the Node Refference fields before, you can recognize a familiar pattern — each entity has a field or fields that show how the entities are interconnected. To do this work, we can add OG fields to the entity, or if it is more convenient to add the Node Refference field.
So, we will start by creating a new type of content, calling it “Group”. Scroll down the page and see the “Groups” tab in which we can indicate whether this content is a group or a group's content. We need to point out that this is a group.
Next, we need to edit the existing content type or create a new one. Using the same tab “Groups” we indicate that this type is the content of the group and will be associated with the group.
After marking the content type as group content, we need to go to the “field management” screen for each content type to add OG fields to them. When we do this, we will see that we have the opportunity to choose, through the fields, which content will belong to which group. But you will not see any other special fields here. This is another one of the intricate aspects of the D7 version. You cannot fully control the fields from the “Field Manager” screen.
To add special fields to OG, we need to go to the administrative part of OG. Take a look at the administrative screen, a screenshot of which is shown below, the options are marked with numbers. This is what we need to customize the OG fields.
For example, under the admin / config / group / fields link you can see something similar to the screenshot.
Some of the fields were automatically generated when we marked the content type as a group or group content, but our group essence and group content does not have some of the fields we need. To add the remaining fields, we need to mark the entity or node in the upper selector and select the one we want to add in the lower field. The available fields are sorted by subgroups of the group and the content of the group for signaling where and what can be added. To add a field, you need to select the type of content in the upper part and the field in the lower part and click “add a field”.
If we want to have the possibility of private groups, then we can add the “group visibility” field to the group. If we want to overlap existing divisions by global roles in groups, then we need to add the “group roles and permissions” field to the “group” entity. If we want to use other external modules mentioned above, we will see options for adding fields as group content links.
Content group entities have different fields. They should be given the fields “group audience” and, possibly, “group visibility” (in order for the authors of the group to be given the opportunity to choose visibility).
Note that the “Users” entity has the same “group audience” fields as the group content. This is used to keep track of which groups which users belong to.
When all fields are set, you can choose which fields belong to which entities.
From this step, you can go back to the field management screen for the entity and you can see all the OG fields where you can sort by your own. You can check all settings. You can double-check each setting to make sure that the “group audience” fields are correct. You can also mark permission to add users or materials.
You may need to make changes to the fields presented on the field control screen. Many special OG fields have a format called “Group Subscription.” This setting allows you to generate output based on user permissions. If the user is not a member of the group, he will see a link to join the group. If the user is a member of the group, then he will be shown that he already has the role of membership.
With these settings, we can create a new group node and the node editing screen will show our OG fields. There we can choose which of these entities will be groups, whether they will be public or private, what entities they will interact with and what will be the content of the groups.
The finished node looks like this:
Now we can see the status of our group, a description of the group, links to add new content and see the existing content of the group (if there is one, of course). And the group administrator will see the tabs with editing the group and its administration, where he can manage group members and so on.
What we did is literally the germ of what can be done from OG. The resulting still develop and develop. You can return to the administration page and continue exploring all the options. For example, configure the global roles and permissions options for your groups.
Also, you can go to Views and set up special views for content and group members. And, of course, you can use Panels to glue all this together. Thus, these are only approximate possibilities of what may be in OG in the simplest configuration (you will need Features, CTools and Panels).
I mentioned above that architectural changes may occur. This is due to getting the freed OG entity in requests. The basic idea is to simplify the configuration and organization of OG and return to the templates used in D6, when the group entity is a group and the group entity ID is a group GID. We also welcome the sponsorship of Amitaibu (Amitai Burstein) this is the developer of OG.
One of the main differences between Drupal 6 and Drupal 7 versions is the development of the concept of what is a “group”. In D6, the group was a node and other nodes could be subscribed to it as the content of the group. In D7, any type of entity can be a group, and any type of entity can belong to a group.
In this article we will look at the whole architecture of OG and go all the way to build the initial group in D7
What is a group?
Take a look at the illustration below. You can see that a group consists of many different types of entities. In the center is the node itself, which is a group. The essence of the group "parent" for all who are a group.
')
Users and content are two kinds of entities that belong to a group. Each user and each part of the content joins the group with additional entities. Figuratively speaking, this is a simple entry in the table that keeps track of which entity is associated with a particular group.
In fact, in the current architecture there are two different types of entity “group. One is the type of content that you designate “group”, and the second is a special OG entity that you probably won't be implementing here. In essence, OG contains both the group itself and the group identifier (GID). This is one of the most confusing things about the OG architecture in D7. Keep in mind that GID and NID are two different things. This may change in the future, so read the links at the end of the article.
Entity group
To get started with OG, we have to decide which type of entity will be the “parent”. In D6, this has always been the type of material, but in D7 it can be any type of entity. It will still be content of several types, but it is better not to do so. One example of another way is energy.gov, where groups are built on taxonomy terms.
For example, we will build a type of material called “group”, which will be a container, similar to what happened in OG version D6.
OG Content
The next thing we need to do is determine which types of entities will belong to groups. We can use existing content types.
Group content is not limited to the essence of the node or the type of content. Other entity types may belong to a group. The available entities are limited only by the modules installed on the site. For example, if a meda-module is installed on the site, then the media entity may be included in the group.
Users are other, special content types of group entities. They join the group and are also “group membership” content, but in addition they have a number of properties and users can have roles and permissions to interact with the group.
Any type of entity can belong to a group. In fact, the group itself may belong to another group. This allows you to combine groups, creating subgroups.
Downloading and activating modules
Having built in our minds a diagram of how entities will interact with themselves, we can proceed to constructing this on the site, by downloading and activating the OG module. OGs depend on the Entity API module, so we also need it. (comment from the translator: “clean installation” requires modules: CTools, entityrefference, views bulk operations and views)
The D6 OG version was a monolithic module and practically gave everything out of the box to create a group. In the D7 version, we went the other way. Each task has its own module with its own highly specialized tasks. Part of the tasks carried out in separate projects.
Here are some of the projects submitted to separate modules:
- OG Content Links - creates a link "add content" that allows you to add content to the group
- OG Views - provides a “Group View” field that you can add to the group display. Note that this module does not require an integration view, but the situation is planned to change in the future. If you want to embed content from a view onto a group page without using Panels, you can use this field.
- OG Theme - creates a “Group theme” field that allows users to select a theme for a group.
- OG Language - allows the “Group language” field to allow users to select a language for their group.
Changes have also occurred within the OG core. For example, a module that came with an OG named OG Context.
OG UI is also rendered into a separate module. If you want to activate only the OG core and do not want to see anything related to OG in the administrative menu, then skip this module. The reason for this may be that all the groups you have already configured and you do not want to configure anything else.
Building our groups
In the version for D7, using the fields in the kernel, we use special fields to connect all these entities together. If you used the Node Refference fields before, you can recognize a familiar pattern — each entity has a field or fields that show how the entities are interconnected. To do this work, we can add OG fields to the entity, or if it is more convenient to add the Node Refference field.
So, we will start by creating a new type of content, calling it “Group”. Scroll down the page and see the “Groups” tab in which we can indicate whether this content is a group or a group's content. We need to point out that this is a group.
Next, we need to edit the existing content type or create a new one. Using the same tab “Groups” we indicate that this type is the content of the group and will be associated with the group.
After marking the content type as group content, we need to go to the “field management” screen for each content type to add OG fields to them. When we do this, we will see that we have the opportunity to choose, through the fields, which content will belong to which group. But you will not see any other special fields here. This is another one of the intricate aspects of the D7 version. You cannot fully control the fields from the “Field Manager” screen.
To add special fields to OG, we need to go to the administrative part of OG. Take a look at the administrative screen, a screenshot of which is shown below, the options are marked with numbers. This is what we need to customize the OG fields.
For example, under the admin / config / group / fields link you can see something similar to the screenshot.
Some of the fields were automatically generated when we marked the content type as a group or group content, but our group essence and group content does not have some of the fields we need. To add the remaining fields, we need to mark the entity or node in the upper selector and select the one we want to add in the lower field. The available fields are sorted by subgroups of the group and the content of the group for signaling where and what can be added. To add a field, you need to select the type of content in the upper part and the field in the lower part and click “add a field”.
If we want to have the possibility of private groups, then we can add the “group visibility” field to the group. If we want to overlap existing divisions by global roles in groups, then we need to add the “group roles and permissions” field to the “group” entity. If we want to use other external modules mentioned above, we will see options for adding fields as group content links.
Content group entities have different fields. They should be given the fields “group audience” and, possibly, “group visibility” (in order for the authors of the group to be given the opportunity to choose visibility).
Note that the “Users” entity has the same “group audience” fields as the group content. This is used to keep track of which groups which users belong to.
When all fields are set, you can choose which fields belong to which entities.
From this step, you can go back to the field management screen for the entity and you can see all the OG fields where you can sort by your own. You can check all settings. You can double-check each setting to make sure that the “group audience” fields are correct. You can also mark permission to add users or materials.
You may need to make changes to the fields presented on the field control screen. Many special OG fields have a format called “Group Subscription.” This setting allows you to generate output based on user permissions. If the user is not a member of the group, he will see a link to join the group. If the user is a member of the group, then he will be shown that he already has the role of membership.
With these settings, we can create a new group node and the node editing screen will show our OG fields. There we can choose which of these entities will be groups, whether they will be public or private, what entities they will interact with and what will be the content of the groups.
The finished node looks like this:
Now we can see the status of our group, a description of the group, links to add new content and see the existing content of the group (if there is one, of course). And the group administrator will see the tabs with editing the group and its administration, where he can manage group members and so on.
Next steps
What we did is literally the germ of what can be done from OG. The resulting still develop and develop. You can return to the administration page and continue exploring all the options. For example, configure the global roles and permissions options for your groups.
Also, you can go to Views and set up special views for content and group members. And, of course, you can use Panels to glue all this together. Thus, these are only approximate possibilities of what may be in OG in the simplest configuration (you will need Features, CTools and Panels).
I mentioned above that architectural changes may occur. This is due to getting the freed OG entity in requests. The basic idea is to simplify the configuration and organization of OG and return to the templates used in D6, when the group entity is a group and the group entity ID is a group GID. We also welcome the sponsorship of Amitaibu (Amitai Burstein) this is the developer of OG.
Source: https://habr.com/ru/post/155525/
All Articles