 Okay, this is the secret life of Organic Groups, a talk that I originally called Organic Groups from FML to OMG. But since Dries set it up so well yesterday, it's now called Organic Groups, Framework or Product. And the answer is, it's both. Okay, so I'm Wayne Aker. If you don't know me, I'm an independent Drupal Consultant, developer site builder. I kind of do a little bit of everything. I'm also a trainer, I teach training classes for Drupal developers, Drupal site builders, and I maintain several modules that you can find on Drupal.org. There's contact info for me. By the way, all these slides are already posted on the page, so all sort of the links and there's gonna be some videos in the slides. You can get all those if you go to the presentation on the page on the Drupal site. All right, so the overview of this talk, I'm gonna talk about Organic Groups the product, sort of the typical use case briefly. And then I'm gonna talk about other use cases, other ways that you can use Organic Groups to do interesting functionality without writing a lot of code, without having to sort of custom build some spoke system. And those will be roughly broken up into sort of the node-based use cases and sort of other stuff that doesn't use nodes. And I'll also talk a little bit about how Organic Groups works under the hood so that you can understand sort of how those, how to build systems with Organic Groups as a framework. So first let's talk about Organic Groups the product, okay? So if you just download and install Organic Groups and you ask somebody what's it for, it's for groups of users, typically sharing node content. So how many people in here have raised their hand if you have installed Organic Groups at some point, tried it out? Okay, awesome. Because that means we can skip the basic stuff and we can see more crazy stuff, more ridiculous stuff at the end. Okay, so, but I will just run through the features for everyone. The basic features of Organic Groups the product, groups can be created by admins or users, groups can have their own roles and permissions at the group level. Admins can assign those roles to their users so it basically creates kind of a site within a site sort of at least for permissions and roles. Membership and groups can be open and moderated. Posting content to the group can be controlled by permission so you can decide that only certain types of users are allowed to post to the group. And you can, viewing content can also be restricted so basically meaning you can have private groups. All right, so I'm not gonna show these videos if somebody wants to see how to install and set up Organic Groups. There are a few videos here. Like I said, they're in the presentation page on the website. So okay, you can install Organic Groups. This one shows you how to sort of just the mechanics of joining a group, getting approved for the group, and posting some content. And then this just shows basic sort of a group page after we create sort of a little view, then we can get this group page where we have this group listing with sort of all the posts listed after it. So if you've ever done anything with Organic Groups, yours probably looked better than this because you probably didn't use Bartik and you probably did something a little fancier with maybe panels or something else to make that look a little nicer. But that's the basic product use case. All right, so this typical use case typical use it for replacement for a forum. That's a big one. Replacement for a mailing list. I actually have one client that we did this for. They had a bunch of mailing lists. We converted them over to sort of an online social network kind of system. If you are doing sort of any kind of email notifications or you want to for Organic Groups, you should take a look at the message stack which includes message, message notify, and message digest modules. Those are a good way to sort of blast out notifications and people post new content. This typical use case also covers if you're making an internet or some other sort of social network. If you want to play around with that, you can also look at Drupal Commons which is a distribution that has Organic Groups sort of does everything out of the box. All right, so that gets the product out of the way. So let's look at Organic Groups as a framework. So I'm gonna show several use cases and we'll get from sort of the ones that are kind of similar to the normal use case and we'll get sort of progressively further afield. So I think the simplest one is probably learning management systems. Learning management systems, it's kind of really the basic use case except we just changed the terminology. So instead of calling it a group, we call it a class instead of the group admin or the group manager. We call that person the teacher or the instructor, professor maybe, depending on the environment. And our group content isn't gonna be articles or discussion posts, it's gonna be probably lessons, assignments, resources and discussions. And Organic Groups is really good for this because as I mentioned, you have sort of the group level roles and permissions. So you can set it up so that you're sort of administrator users in the role, sorry, in the group have the ability to post assignments and all those sort of all your content types but maybe your members, in this case your students, if it's a learning management system can just post the discussion content. All right, so that's really simple to do. You can do that all out of the box, no coding or anything. And so if you work it up, do a little massaging on it, you can get something nice like this. Okay, so this is a little, actually a little out of date that I think this is one I built for a K-12 environment maybe four or five years ago so it's a little, design is a little dated but this sort of is a learning management system that looks kind of like Facebook, teachers, every class has a page, they post their assignments to it. They can also post updates, there's email notifications and all that good stuff. It is also sort of the student who's gonna discuss and respond to assignments through it. So at this point you might be thinking, oh great, this is one of those sort of demos where I show you just a pretty picture of, but I promise actually there'll be some excruciating detail videos coming up. So since you demanded it, we'll do one right now. I said earlier that you can do private groups with organic groups. I actually do want to show the details of that one just because it's gonna come up several times in the other use cases that we're gonna show. It's also not immediately obvious. So if you haven't done a private group, set up private groups before and you just went sort of poking around, it's not real sort of obvious like some of the other stuff. So to set up private groups, there is a module you need to use, it comes with organic groups, it's organic groups access control. So you turn that module on and sometimes the screencast guy's really slow. Okay, and then the key thing here is there's a different field sort of configuration you have to go to here under configuration OG field settings. And this is a really confusing interface. I just want to point this out because a lot of people get mixed up by this. So this interface has three pieces. This is like a form at the top. This is actually not part of the form. This down here, this actually just shows you the current status of fields that are organic groups fields on the site. And then this button is actually part of this form up here. So it sort of jumps over this other part. But it's real confusing because you click on these things and you think that they're related to the form but really they're just showing you stuff that's already in there. But so in order to create private groups, we need to add this group visibility field to our group node type. And you can see it's now displayed down there in the list of organic group fields. And then if we go to this group, we can go here and say this is a private group. And in this case, I think probably rebuild permissions. Yeah, and so now if I'm another user and I try to view this page, if I refresh, I can't see it because I'm not in the group. If I come through here, I'll sort of scrub ahead here. But if I add that user to the group and then come back and refresh it now that this user's been added, they can see not only the group but also the content posted to that group. All right, so that's pretty simple. So let's make some money. If there's sort of anything I've learned, so actually, I think that working in groups is really positioned well, take advantage of some hot emerging trends in money making. And if there's anything I've learned from the unsolicited emails that I have in my inbox, it's that info products are really hot. In this case, like on fire. As far as best I can tell, if you have an info product, it's four hours a week that you have to work and you can do it from the beach, that's what I heard. So let's sell some info products. Now luckily, because we know about organic groups, organic groups is really well positioned because organic products are also really hot right now. And they demand at least a 50% markup, so we've already got something with organic in the title. So let's make some sort of info product about organic groups. So what we're gonna do is we're gonna sell a course on organic groups. So the modules we're gonna need for this are Drupal Commerce, which is a set of modules, Commerce License and Commerce License, so G. And so in this demo, and you'll see, this is actually amazingly easy to set up with these modules. It didn't use to be this easy, but it's easy now. So just to set this up, this is a private group, this organic groups 101. It has lesson content posted to it that's showing up in a view there on the page for this group. And so now we're gonna convert this into something we can sell. So we'll need to enable the couple modules that I mentioned. I've already enabled Drupal Commerce because there's like 20 modules that you need to enable. I haven't done any configuration, but I enabled that beforehand. So I'll enable Commerce License and Commerce License, so G, and some dependencies. Okay, so now we need to go into the store and we have to do a little bit of configuration. So this license module allows you to sell, it allows your products in your commerce store to be licenses for something. Those licenses can be unlimited or they can have some limited duration. It's open so you can, the meaning of those licenses can have a lot of different, they can cause different effects on your website. But in this case, because we put the OG one on, it's gonna give you access to the group. So what we have to do is we have to turn on this license functionality for the product type. And then the second one is we're gonna have to go here to the organic groups tab and turn on the organic groups functionality for license for the product product type. And we'll create a product now to sell that course. All right, we'll give it an unlimited duration here. And we'll say that this particular product is linked to that course, that organic groups 101, thereby selecting it. So now we have the commerce product. Now for those of you who may not have worked with Drupal Commerce before, every time that you, you have to have both a product display and a product in order to actually sell something. So the product display is usually a node type. So I'm gonna create a node type, a content type called course listing. And this course listing is not gonna be the group itself. Okay, it's just like the sales pitch page, what has the add to cart form. And your product display needs to have a product reference field that links, that links this particular node to a particular product that it's selling, that it's a display for. So we'll set up that field. If you've done Drupal Commerce before, this is all standard stuff. All right, and then we'll need to add a product display for that one particular course. And we'll select the particular product. This is the one we just created in the store interface. And now we have this sort of course listing where we can purchase the course. So if I come over here, this user here is not in the course. You can see he doesn't have that, he doesn't have the Organic Groups 101. Oh, oh, so one great feature of Drupal Commerce is, by default, nobody can check out. So you have to turn on the permissions so that people can actually buy things. So notice that this user here doesn't have the Organic Groups tab, they cannot see the actual group page or any of the lessons. But they can see this course listing, so we'll add that to the cart. And now since we did set the permission, they can check out. And when they check out, notice that immediately you can see that the tabs there at the top, they've already been granted access to this course. And they can now click on it and they should have access to that and all the lessons in the course. All right, so it's just that easy actually to sell courses, which, like I said, that video is about four minutes long, so now you're ready to go join the exciting world of InfoProduct sales. Oh, one weird thing with that module, the slide. I found that it didn't work with anonymous checkouts until I added an extra rule to sort of, it didn't link properly to the correct user with anonymous checkouts in Drupal Commerce. I created a rule that fixes the problem if you go to the slides, if you actually want to do this, you can click that link down there and get the rule export. So we saw how to sell a course, and that's good. I mean, getting money from people, having people pay us for just typing stuff on our computer is pretty awesome. But what's even cooler than that is if we could get them to pay us repeatedly, like every month, pay me more money. And so this is where we can come into premium content or, let's say, website subscriptions, probably maybe it's a better way to say it. And if you Google around for how do I sell subscriptions to my website, I mean, I think pretty much every time I go to my local Drupal Meetup, somebody has that question. They always want to sell access like this. This is the typical approach. Create a subscriber role on your website. The typical one does not involve organic groups. Create a subscriber role on your website. Use a module like content access, something that can hide the view of certain content unless you have a role. So content access is a good way to do that. And then sell access to that role, which you can either do manually, which where people just pay, and then you go in and check the box on their user profile page, or with commerce license role, which is a similar module that does the same kind of thing we just saw, but it gives someone a role. This is a good approach if you have sort of a two tier system, if you have like free and premium. If that's what you have, like you are a subscriber or not, do it this way. This is probably the simplest. Now I had a client recent, well, a little while back who wanted to do something a bit more complex where they really wanted to sell subscriptions, but they had a lot of different subscriptions. And this approach gets, it doesn't work so well. So what happens is, if you try to do this and you wanna say like, well, these people are allowed to see this slice of the content, but then maybe if they want another subscription, they can see this, and then they can see this. So you end up having to create a role for every single subscription type. And it gets even worse because in their particular case, they were doing sort of like industry, you would sign up for like content about like the automotive industry, the IT industry, healthcare. And they had different editors who were allowed to post, different analysts who were allowed to post to these different libraries. So then basically for every single library, they had a subscriber role and an editor role and their permissions page, it was like even on a widescreen monitor, it was like two to three screens worth of scrolling across, which it's hard even when you have just like four or five roles, like trying to keep it straight, especially once the permission sort of scrolls off the other side is real hard. So it's also they were using something like content access, which if anybody in here has used content access, it has a lot of checkboxes like on that, on the sort of access control page. In a normal case, it has a lot of checkboxes. Think about it when you have like 25 roles, then like there's like a hundred, several hundred checkboxes on that page. So it gets to be kind of a mess in that sort of situation, but it's really clean if you use organic groups. So what we end up doing is converting over and we now keep in mind, these people who use this system don't think in terms of groups. They don't use the word groups. Nobody thinks they're in a group. None of the subscribers think they're in a group. None of the subscribers ever post anything. But what we did is we set up every content. We set each of these libraries as a group. We, the editor admin role is that sort of the person who's allowed to publish to the group. And so they could post the premium content. They were private groups. And then we sold access to the group just like I just showed you. And we didn't do this, but you could also do this with email notifications. And I even imagine that you could, like if you wanted to sell like a premium newsletter or like a series of premium newsletters, which might be a hard sell, but maybe if you were selling something like Stock Tips or something, right? Where people were willing to pay for it. Like you could have users who like go and buy things and get put in a group. They don't even look at the content on the website. They just sort of get these email notifications, but you could power all that with organic groups. So you would have people, you would post the content to different groups based on its sort of categorization. People could subscribe to those based on the system we just showed a minute ago. And so you could power all that. And I actually, I think that you could pull that off without really writing any custom code. Maybe just something to clean up the email so they look kind of nicer. That might be about it. All right, another common use case is editorial sections for the website. I think this one comes up at our local meetups pretty often too, which is I wanna allow, I have different departments, have different pages on the website, and I wanna allow some people to edit their own page, but not other people's page. I don't want them squaring with the main menu. Another case may be people have different products and there's different product owners who should be allowed to edit the pages for those products, but you don't want other people to edit them. So again, nobody in this case is thinking about groups or subscriptions necessarily, but this Organic Groups is a good solution to this problem because you can basically, every section of the website can be a group. And because Organic Groups has that nice roles and permission system at the group level, you can now decide, okay, this person's an editor, they're allowed to create pages, edit pages in the group. And one really nice thing, which I will demo here in a minute, is if you wanna give them the ability to create some menus, but not mess with your main menu, you can use a module called OGMenu to give them their own sort of submenu. So I'll blast through this one here because it's pretty typical, but so the basic setup is you would just create a content type for your section. This could be, if you were doing departments, this could be department, if you had the English department and the math department, something like that, and you wanted them to edit separately. You would set it as group, you would say that this content type functions as a group, and then you need to be able to post some things to the group, so we'll just allow people to post the basic page content type to the group, and all we have to do is come in here and turn on group content for the page. All right, and I'll skip ahead here, but basically we're gonna create a couple sections, and I'll show you sort of what this looks like at the end. Okay, so at the end we'll have a couple departments here, an English department and a math department, and I assigned a couple different users. I think the user Bob is the admin of the English department, and the user Jen is the admin of the math department, and this, yeah, and so this is user Bob. Bob can edit the English department page, and Bob can also add new pages under the English department section. Now one thing you'll notice here is, okay, so Bob has created this about the English department page, but it's not linked back here on the English department anywhere, and that's where Organic Groups Menu, the OG Menu module is really handy, so let me show you the demo of that because it seems like not everybody knows about this one. So we'll turn on the Organic Groups Menu. There is also an Organic Group Menu default links module, which allows you to set up a default set of links that show up in a section menu or a group level menu, and then under configuration, OG Menu Settings, there are some settings you can choose. You can choose how many menus a group is allowed to have, and let's see, you can, the other one is automatically create a menu for a new Organic Group, so that's a pretty handy one. For most cases, you might want to, you probably would want to turn that on. You can also choose to show, if you allow multiple menus, you can also choose to have those sort of broken out into separate blocks. I'm not gonna turn that on in this particular demo, but there are a couple other options there. So we'll allow one menu per group, and what we have to do is have, there is a block that gets created by this, and so I will put this block on the sidebar, and oh, so it doesn't show up initially, and that's because even though we selected to automatically create a menu for a group, that setting is not retroactive, so I now have to go create the menu for this English Department Group. If I had created the English Department afterwards, it would have worked automatically, and well, you can't really see it on this screen, but there is actually a new block down there. It's kind of washed out on the screen, and now here I am as Bob, this is a person who is an admin of this group, so they can come in here to this menu interface at the group level, at the section level, and they can take that page that they had posted, or that they created, and put it into the menu, and now you can see they have a nice little English Department submenu. And I'm showing it on the sidebar, depending on your theme, you could have it at the top, or some kind of strip at the top under the other menu. All right, and so this person might want to create sort of a home for this section, so they create like a home menu link, and they can do everything you can do with the normal menu interface, they can drag it around, reorder it, they can nest things under other things, works like all the sort of normal menu interface, but they're restricted to just this one at their level. So if you do this for all your different sort of subsections, then you can let your editors totally screw up their sections of the website without screwing up other people's sections of the website. All right, so I'm gonna talk in a few minutes here about everything we've seen so far has been some kind of node type as the group, and a node type as the group content. I'm gonna talk about using non-node types, entities for some of those things, but before we get there, I need to talk a little bit about how organic groups is built under the hood, so the architecture. When we talk about organic groups, we tend to use like this terminology. So we have some group, we have like the group content, and we have the users or the members of the group. However, this is not really how it looks under the hood, it's not really how it's built. It's really more like this. So in this particular example, what I'm showing here, the big node in the middle, that is your group node, and then you have nodes and users, which are linked to that by organic groups, memberships, those memberships are entities themselves. Okay, so that's why I've drawn them with a circle. And organic groups, even though out of the box, this is the easiest way to get it up and running, this is what it does out of the box. It is agnostic sort of about what the entity types at the ends of these lines are, so it can really support any entity type for the group, or any entity type for the group content. So you could do something crazy like this. And actually you can have more than one, so that's what this shows. So you could have like a commerce order as the group type, and then commerce products and comments and entity forms. Now I don't think, I can think of a good use case for doing all of this at the same time, but if you come up with it, I'd like to see it. In addition, you can get even more complex with it, because the memberships are, because they are an entity type, you can have different types of those memberships, just like you can have different content types for nodes. You can have different types. So you'll see I've colored in some of the memberships with different colors there to indicate that. Those memberships are also fieldable. So if you need to store data about the link between these two things, you can do that actually in the membership if it's not like inherent to like the node, but it's inherent to like when this node was added or when this something about its link. You can do that by fielding those OG membership nodes. And in fact that's actually done in core, or sorry, in the OG core. If you like, you know that request message when you try to join a group, that's actually just a field on the membership instead. So let's see some examples of using other entity types. Now I'm gonna admit some of these are gonna be crazy and perhaps they'll advise, but hopefully you'll learn something, perhaps not to do it, I don't know. So let's take the hypothetical situation. Let's say you're building a social network or an internet site and you're already decided that you're gonna use organic groups because you're gonna do groups. That's one feature that you want, just the standard groups. Now you've been asked to implement some kind of user follow or user friending kind of system. So the normal way, if you ask somebody, hey, how do I do user follows in Drupal? So the correct answer to that is use the user relationships module, which if you've never used user relationships, has a really slick interface. You can say I wanna create a new relationship type. It's called there's a follower and a followee or something and you can say whether the relationship is reciprocal and all sorts of stuff. So if you're sort of doing user relationships in isolation, I recommend using user relationships. It also has nice views integration and some rules integration so you can tie in with other stuff. However, let's say that you're planning to really scale this up. There's some issues and you are also going to use organic groups because user relationships will not solve your problem of I need to be able to post to groups and allow users to create groups. So why might you choose not to use organic, or sorry, use relationships? Well, first of all, it's a completely different system from organic groups. So it's a different set of database tables. It's different configuration. That means you're gonna have to export all that configuration separately for like into your features. You're gonna have to understand it yourself. It's another set of modules to keep up to date, which means it's another set of modules that when you update it could break your site. And it could be complex if you want to sort of show an integrated feed like show me all the users that I'm subscribed to and all the groups I'm subscribed to, all the posts, all both of those because that data is in multiple tables and so that makes it tricky to do it with views. The way most people get around that by the way is to use like message or something as like another entity that sort of takes the place of that, but again, that you're adding sort of an extra complexity. And in this particular scenario, you already have a way to subscribe to some feed of content, it's called organic groups. So instead of this, or actually you have this for your groups, we're gonna set up something like this, where the user themselves is also a group. I told you it'd be crazy. Okay, so I'm gonna skip this first video. This first video basically is just like setting up normal groups, we've already seen that. These groups in this particular scenario are private groups, so you can only see the content posted to them if you've been accepted as a member. So we start with that. And now let's add crazy stuff. So one, the most important thing, when you go to using non-node entities with organic groups, you don't get that nice little checkbox at the bottom, like the content types, we're just like, this is a group, this is group content. And it's really easy, and then it sort of just adds all the fields for you and kind of takes care of it. You can't do that when you want to, it's a more manual process when you want to go to other entity types. So you have to go into that interface that we saw earlier for setting up the private groups. So in the OG fields, so let me slow this down a little bit here, but up here in the, where it says bundles, you can actually select, this actually shows you all the different entity types on the system and all the bundles, so all the different subtypes under there. So we can pick the user, and then we have to pick the field we want to add, so in this case it would be the group field, and we also need to add a second group audience field to the articles, in this case articles of what we're posting to the group. I'll show you why here in a moment. So now if I go up here under content type, I'm gonna show you these fields. So there are actually two group audience fields now. One of them is going to be for linking an article to groups that it may be posted to, and one of them is going to be for linking articles to users that it's posted to. Now that could be redundant, because obviously the post already has an author. However, I can think of scenarios where it wouldn't be, like it's possible that maybe you would be like posting on this other user's timeline, like you do in Facebook, and so it might be that you somehow have permissions to post to other users as well, and that that should show through. So in this particular case, I'm gonna clean up these names because they both say group audience by default. So this first one will be groups to post to, and the target type here is node, and this is the critical thing. We need a different field when we have a different target group entity type. So this is gonna be the user to post to, and we're gonna have to switch the target type actually to user. Now if I was doing this in practice, I would probably hide that field that user to post to. I would use like a form alter or something because most of the time it could be preset. Users should post to themselves. All right, so if I log in as Pete, and I go to my account page, because I did this backwards, I have to turn Pete on as a group. I have to make Pete into a group. And then once I do that, if I log in as Bob, I can now request group membership in Pete. Now you can see that the user interface is not necessarily awesome for this. Requesting group membership in Pete doesn't make a lot of sense. And Pete here can approve the membership. He can make him an active member of himself. And let's see. Okay, now one thing here, I don't have a view or anything. So Pete's gonna create some content. But I don't have a view yet that sort of shows that content. So I'm gonna skip ahead, and like I said, you can come back and look at this video, but this is just a view that on Pete's page or on any user profile pages shows the content that's posted to the user group. Okay, so what we end up with is this, where this is Bob. He's looking at Pete's page. He can unsubscribe, or sorry, yeah, Pete's page. He can unsubscribe from Pete, and he can see all the articles from Pete. And I think, yeah, and if you're somebody else, like Jen, she's not a member of Pete, she should be able to not see it. Yeah, so there's no content in this group. Now like I said, if you choose to do this, you are gonna probably need to write your own user interface, because you're not gonna want your users to request group membership. You're gonna wanna make like a follow button. However, the underlying architecture is now really clean, because your group subscriptions are handled by the exact same system as your user subscriptions. So especially if you're writing some code, you could actually, I'm gonna show you here in views, you can create sort of one view that shows all of it. You can also, if you're doing any sort of custom code, all your stuff is in that one sort of database table. Make your queries a lot easier. You're not trying to sort of union sort of two data sets together and whatnot. So I'm not gonna show creating the whole view because it's pretty tedious, but it is here if you wanna see it at some point. But what we end up with here is I'm creating a My Post page that sort of brings all the content from everything I'm subscribed to onto a single page. So in this case, I think this is Jen. Jen is the admin of this group. So she sees the group post. Let's see, this is Pete. Pete should see just his own post because he's not a member of the group. And Bob should be able to see both. Oh, yeah, there we go. All right, so it could take a little work to smooth out the user interface, but I think if you were really trying to scale this up to a lot of users and stuff, I think in the long run, that the little elbow grease to get the user interface working would probably pay off by the simplicity of the system, the fact that you have sort of one user interface. Because think about also, if you have to do like notifications, you're gonna have to trigger off of, you know, two different systems versus one system. And sort of, and every time you make a change to that or to the notifications, you gotta worry about two different user relationships and organic groups versus this, you got sort of this one subscription system. So entity forms. So this isn't a, how many people have used entity form module before? Okay, so not that many. That's actually what I've been finding. Everybody, you should go, if you have never checked it out, go check it out. This is a separate from organic groups for a minute, but the entity form module, it's a similar module to web form. You can use it for similar use cases. However, the two important differences that it has with web form is the submissions to those forms are entities themselves. The entity form submissions. And it uses the standard field system. So instead of having, like web form has its own sort of field types and things, anything it uses, like anything you can do with a node, any special field types, you can use them with any form. So address fields, field collections, and all that kind of stuff. I actually did a talk on this at the Ann Arbor Doug a month ago, which if you're interested, you can go there, it was recorded. So that's just about entity form. Not about organic groups. But for a particular project, I wrote a module called OG entity form. Because those entity form submissions are entities, they can be group content. And so the use case that I had was, I had a social network and I needed to have a form, like a contact form on a tab on every single group page and the admins of that group should get notifications when they get submitted and they should be able to look at it in a submissions list interface, just like you would with another form. But there were hundreds of different groups and we didn't wanna create a bunch of different web forms, like one for each group. So we used this entity form, or I created this OG entity form, which I'll show you the typical use case and then we'll use it, we'll abuse it horribly to do something else. So in the typical use case, here there's four groups here on organic groups entity form integration. And then if we go here and add a contact form at the bottom, oh yeah, okay, we can say who can submit it. And then there's this organic groups tab. And we can say this is gonna function as group content. And I wanna add a tab for this particular form to the group entity page and give that tab some title. And I'll skip ahead here, this just is sort of creating a contact form. So you can see it uses the standard interface, uses the standard field interface that's like just name, email message, like a standard contact form. So now when I come back and I go to any group page, there is a contact us tab that has my form on it. Okay, and that will happen under any group. And then if I come, oh, and so yeah, there are some permissions. If I wanna allow the administrators to actually see the form submissions, and if I wanna allow, I can allow members or non-members to see the form. And now if those are set up, you can go over here and another window, hopefully. And so this is what it would look like. And so somebody can submit this contact form like we just have that one form to find one place. And somebody can fill this out. And now if we go back to the group page, this person can see those under the form submission area here for that form. All right, and that's limited per group. So every group only sees the submissions that came to theirs because what's hidden from you here is that I'm still using that same kind of group audience field that we added by hand. This module sort of does that for you, sort of installs that for you so you don't have to go through and click those buttons. But it gives you that, it's got that same field on it, group audience. It creates that organic groups membership from the submission to the group. And so it works the same way like we just saw with like posting things to a user or whatever. So this is some other entity type as group content. So it's sort of the opposite of what. So that's the standard one. And I thought, well, how could we abuse this? How could I have like a really wow demo that's like crazy? So I thought, what about verified product reviews? Because this is something people always want because Amazon has it, right? So if Amazon has it, you have to have it. So in this case, we're gonna do it. We're gonna do product display pages as the groups. We'll use the OG entity form module to accept the reviews. The verified purchases, what we're gonna do is every time somebody checks out, we're gonna add that person automatically to the product page group for all the products that they bought on that order. We're gonna loop through the line items on the order and then add them automatically, which we can do with rules when we install commerce rules extra. So this first one, I'll go through super quick. So I just have a simple store here set up with some products, all right? But right now, these products aren't groups. So we'll go in and just turn on for the product display nodes. We'll turn on, we'll make them groups. And then we'll turn on for the entity form. I've already created a review type, but I'll skip ahead here, but basically we're just going to, we'll turn on that group content for this and make it a tab, right? And so what we end up with, oh, okay, we have to make this a group. This is similar to the problem we had with Pete with the retroactive group thing. Okay, so now there's an add a review tab, okay? This is just the exact same functionality we saw a minute ago with the contact form. And I can add a review. Now, is this particular user has not purchased these fish? And this is, I'm gonna skip ahead here because right now we don't have any way to show the review, so I sort of go through creating a view to show the submissions to the web form on the product display page. And what we end up with here is, scroll ahead. Yeah, so we end up with just our product page and then we have a block at the bottom with all the reviews, it's currently only one. So how can we, now that's not doing any sort of verification. If I, even if I had purchased that, it would look the same. There's no verification yet. That's just sort of getting the basic setup. If I want to add the verification or verified reviewer, sort of notification, then we're gonna need to create a rule. And again, this rule is going to add the user automatic, when on checkout, it's gonna add the user to the product display page for every product that they bought. And don't try to copy all this down. I actually have a features export if you wanna play around with this later. So we'll create our new rule and we'll react on events completing the checkout process. We'll add a loop over all of the line items in the order. And then on every iteration of the loop, we will, it is get the referencing node from the line item. That's a really handy sort of thing that if you just use your commercial, like hey, I've never seen that. That's commercial is extra. That's why you need it to get that cool feature. So get the referencing node from the line item. And so we'll store that in a variable. And then we'll add an action. And this one I wanna pause on here. Organic groups has some really nice rules integration. So one of them is super simple, add entity to group. Okay, so it really takes a lot of the hassle out of it. And so in this case, our entity is gonna be the user. It's the user who is the order owner. And then the group is the referencing node that was on that line item. So we'll loop through all the line items even if they purchased multiple fish products. We can add them to all of them. So now we'll go here as this user and we can buy these fish. So I'll skip ahead here. This person's just gonna check out. All right, so now they've checked out. They bought those same fish. And they're gonna go back here and write a review. You can notice that they're subscribed to the group. In a practice, you would take that off obviously because you don't want people to know they're in a group that you're tracking them and whatnot. People might not like that. All right, and now when we go back, we should see both reviews there. Now they still don't say anything about verified purchase. So I'm gonna have to come back to the view that I made actually in that first video. And make it one little adjustment. And that's how I'm gonna switch from using fields to the rendered entity. And I'll choose the full content. This is the entity. This is the entity form submission. I'll choose the type of entity that we have here for the review. And then I'll refresh. Entity form verified purchase. Now you might say, hey, that seems like there's some steps missing. Yes. I've owled you yet again. Okay, so there's a step missing. The reason I switched to content is because this is where we're gonna have to write a tiny bit of code. If we can switch to content, then we can hook in with the theme system. So with the theme system, we can use a preprocess function. And so I'm not necessarily gonna go through every line of the code, but I do wanna point out, like the third there from the bottom, or second from the bottom of the actual code lines, where it says, if og is member, and it has the group, which is the product page, and it has the user, then create this new variable called verified and set it to this, whatever this message is here. And then I have overridden the entity form review template so that it looks, but right here towards the end, it looks to see if that verified variable exists, if it's empty or not, if it's not empty, then it adds that message in there. Okay, so that's how I am able to do that. So if you know a few, this is actually one of the really nice things about organic groups, versus trying to do it on your own, sort of coding something on your own, is it has some really nice utility functions like that og is member, that's really easy to use if you're coding. There's also og group and og ungroup, so if you wanna add a node to a group, it's one function call. You don't have to worry about what the entity reference field is, use entity metadata wrapper, blah, blah, blah, do all that. Nope, just og group, which is like three or four parameters, and you can add that node to the group, you can add a user to the group programmatically. Ungroup is the opposite, og is member. Og user access is, if you've ever done any of the coding, you know the user access function that basically checks permissions, og user access does the same thing, works exactly the same way at the other level. You can grant and revoke roles, really easy. So a lot of times I like to use organic groups, even if I, I know how to write it myself, if I have to, but these utility functions makes a lot of the coding easier. Sometimes, if I'm just gonna work with like sort of collections of things and link them together with entity references. Oh, one quick warning about the API, never, never, never create organic groups membership entities directly. Theoretically it should work, like you created an organic, because I told you they're entities, and if you set them up correctly with the right links on the end, they should work, but there is a cache that needs to be invalidated. And if you use og group and og ungroup functions, it handles that for you, if you create them yourself. It does not, and I can tell you because I screwed up two different sites with this problem. And the symptom you will have is, hey, users are randomly being unsubscribed from groups. Or, or after we fix that one, hey, users are randomly being resubscribed to groups that they left. That will happen, actually if those caches don't get invalidated. But basically anytime they go ahead at their profile page, change their password, or something, it will break things. All right, so I do have a features export. You can download if you really wanna see some of those rules and stuff. So real quick, we're just about out of time, some other crazy ideas. I'm just gonna throw against the wall, but not really show them, dating demos. Product update notifications. I actually think this would be a pretty good idea. If you did what I just showed, where you add the users to the groups, then let's say you were selling an e-book. It'd be super easy to send updates to about that e-book. Because it's already a way to send notifications to people about in a group. So you could send those. Marketplace site, if you wanted to have, I actually did this one. It was a wedding registry. People created their wedding page, it was a node. They created GIFs, which were commerce products, in their wedding page. And also the commerce line items that got created from those products, were also group content. And so that way we knew like, oh, these line items, we have to pay these people back their money over here, because it's linked back to their wedding page. Collaborative image galleries like Flickr has, where you can share image with a group. We could do that. A nice bonus, because OG memberships are fieldable, you could, you know how Flickr, it has that thing where like when you submit the picture, you can have like a special comment or description that goes just with that submission to the group. You could totally do that out of the box almost, just by adding a field to the membership. What if you were doing that? So summarizing up, OG framework, it's useful if you're collecting entities together, especially if you're doing sort of any user subscriptions or access control to the collection. Excellent views and rule support. Simple API, much easier than sort of working with entity references directly. And if you're gonna work without nodes, you're probably gonna have to write a little bit of UI code and consider different sort of, it's got an extensible architecture, consider different membership types and fieldables. All right, and so that's it. We're right at six o'clock, so I'll end it. If you have questions, you can come up here and ask me. Otherwise, thanks for attending. And please review the session on the session base.