Exploring the Future of the Drupal Group Module

[00:00:05] Michael Meyers: Hey everyone. Welcome back to Tag1 Team Talks. Today we're talking about the future of the Group Module with creator and maintainer Kristiaan Van den Eynde. If you're building anything in Drupal where different people need different levels of access to different sections of your site, think teams, company departments, local chapters, membership tiers, you're probably using Group. And if you're building a platform on Drupal, one of its most powerful and popular use cases — think universities, corporations, government agencies running dozens, hundreds, even thousands of sites and microsites — you're almost certainly using it. It lets you control who sees what, who can edit what, who can manage what, and is all scoped to a specific collection of content and users, and it's relied on by some of the biggest organizations running Drupal today. I'm Michael Meyers, the managing director at Tag1, and my guest today is the creator and lead maintainer of Group, Kristiaan Van den Eynde, a senior architect and engineering leader here at Tag1, who's been iterating on this module for over 13 years, which is really amazing. He's a top Drupal core contributor, a core subsystem maintainer, and not just an amazing engineer — he's also a really great communicator who has presented at numerous DrupalCons, Dev Days, and he's got that rare ability to take the most complex and detailed subjects and make them approachable to anyone. So whatever your background, I'm confident that you'll learn a lot out of today's episode. Kristiaan, welcome and thanks for joining.

[00:01:35] Kristiaan Van den Eynde: Yeah, thank you. And thank you for that nice introduction. It's nice to be here and I'm looking forward to talking about Group and where we're going with it and to answer some of the questions that people may be having that you are going to ask today.

[00:01:51] Michael Meyers: Awesome. Yeah. Just to give people a quick overview of what we're gonna talk about — the future of Groups, right? The long awaited consolidation from the two major versions into Group 4. You're doing a major restructuring of the module ecosystem, pulling a lot of these submodules back into the core module. We're gonna talk about improvements to some pain points like the Experience Editor, which I love that you've been so open about and working so hard to address. And I'm also really excited about talking about some of the code quality issues and what it takes to maintain and sustain such a popular module at this scale. But before we get into the future of Group, I wanna talk about everyone's future with Tag1. Tag1 is the number two all time contributor to Drupal, the world's second most popular content management system. For nearly 20 years, we've been the architects of the open web, leading the creation of the software and best practices that powers millions of websites and thousands of organizations worldwide. We're your full service strategic partner, applying that same architectural expertise across technologies and throughout your organization. From discovery and design to building and scaling complex applications, we lead AI strategy and implementation, design and manage infrastructure, and architect large scale web applications across a wide range of technologies and platforms. We're trusted by industry leaders, including Sumitomo and NTT Data, the European Patent Office and the American Federation of Teachers to solve their mission critical challenges, and we build lasting solutions and relationships. Check out Tag1.com to learn more about how we can help you.

[00:03:27] Michael Meyers: All righty. So with that outta the way, Kristiaan, before we talk about the future of Groups, I have always wondered — the origin. Why did you call it Group module and not Groups module?

[00:03:42] Kristiaan Van den Eynde: Okay. So I've let it go, but at first it annoyed me tremendously that anyone coming up to me at a Con would say, "Oh yeah, I'm a fan of Groups." I'm like, okay, but it's called Group. The way that came into existence is, as you may recall, before Group existed, everyone was using a module called Organic Groups. That's a long time ago now. I'm not gonna go into the whole backstory of why I created Group. But I wanted to build this alternative with a different data structure and just basically a different vision of how I thought things like this could work. I was looking on drupal.org for available project names and I thought, let's keep it simple. What am I doing here? I'm building this entity called a Group. So let's just call it that. I tend to look at Drupal Core a lot when I build stuff. And back then I wasn't a core maintainer even. So I just looked at the node module in core — for content, if you want to create a page or an article, internally that's called a node, and the module is just called Node. So I had the same concept where I had this thing called a Group. So I thought, let's call the module Group.

[00:05:09] Kristiaan Van den Eynde: Funny side story. That name was taken on drupal.org, but it was taken by Amitai Burstein, the same guy who wrote Organic Groups. And I don't know what he was planning to do with it. It seemed like he was trying to rewrite OG or something. And then I just reached out to him and I said, hey, I'd like to take over this project namespace, nothing is happening with it. And it was like, oh yeah, sure, knock yourself out. And he gave it to me. And then I created Group, which later on surpassed Organic Groups. By the way, all the love in the world for Amitai — he is a great guy. I understand why people tend to call it Groups because a lot of them migrated from Organic Groups. But yeah, the name is Group and I think the ship has sailed. I would appreciate it if people started calling it Group because there was a reason behind calling it that.

[00:06:34] Michael Meyers: You won me over with the node argument. I've always wondered, because I always — I know why people call it Groups, but now it makes a lot of sense to me as to why you chose to do that. I think people are gonna keep annoying you and calling it Groups. I'll try not to annoy you too much today with it. And Amitai is awesome and he's got his hands full with workspaces — he's another awesome Tag1 engineer.

[00:07:45] Michael Meyers: So, back to the future — can you set the stage for everybody at a high level? You're thinking about the architecture for the newest version of Group. What are your guiding principles? What are you thinking about? How do you structure your approach to this?

[00:08:08] Kristiaan Van den Eynde: Okay. So at very first when I wrote Group, I accepted all of the feature requests. I had so many ideas. I just worked on all the things at once, right? And it became bloated, it became unmaintainable and it led to the situation where people came with even more feature requests because they saw that anything goes. And then in the later versions I tried to steer away from that and make it more mature. The people at Deeson in the UK, who I was working for at the time, they actually helped me with that because they gave me a space where I could bounce these ideas off of them and they would provide insights with their experience and challenge me. So that's how the sort of building blocks of version two and three came to be. And over time you'll see that I've tried to make it more and more mature, following industry standards more and more. As I grew as a developer, I saw more things. I started recognizing patterns. I saw things that we were doing in Core. I copied those over. Then I found that some of these things were lacking, and I improved upon them, which is how we got some systems into core, like Variation Cache and the Access Policy API. And these are like the sorts of habits that I've grown to have that I want to continue having towards the future — where I look at what I can improve and try and make these iterations where it just becomes more and more mature, more and more stable. And I keep challenging the status quo.

[00:11:55] Michael Meyers: So I know one of the biggest things that you're focusing on with the new version of Group is consolidating down to a single module. Right? So for a long time now, you've been maintaining two major versions of Group side by side. Talk me through why you chose to split this out into two modules to begin with, and some of the challenges that that created.

[00:12:27] Kristiaan Van den Eynde: Okay. So this is one of the biggest regrets from my professional career — that I went ahead with this. And in the end I still think it was the right choice, but it's caused me so much pain that if I had a time machine, I'm not sure if I would do it again. Essentially when I developed Group at first and then going into the first version for Drupal 8, and then trying to create the second version, which was a lot more mature and moved away from the concepts that I had still inherited from Drupal 7 — the only thing that you could put inside a Group was what we consider content entities: pages, articles, but it could also be a different Group. But there was a desire from the community to also be able to put configuration into Groups. That would be the configuration, for instance, of what fields should be on an article — or especially popular, the Webform module. Webform allows you to create these forms on the fly, and a lot of that is tied to configuration. You couldn't put that inside a Group at the time. So right before the release of the second version of Group, we actually had sponsorship from ANNAI out of Japan, and they wanted that functionality where you could put web forms inside of a Group. So I made that possible. But now I had this conundrum — because inside of the Group module, the thing that was representing which content belongs to which Group was called Group content. And it turns out that changing names of classes — that's not all that hard. But these pieces of code usually have what we call a machine name, and it's that specific piece of text that we put in a database. And changing that is really hard in Drupal, it turns out.

[00:16:09] Kristiaan Van den Eynde: I wanted to change it and I didn't want to have like two names — Group content and Group config. I wanted to have a name that represents all of the things. So I ended up going with the name Group relationship. It's a relationship between a Group and something that you put in it, whether that's content or config or perhaps in the future, something completely different. So that sounded like a future-proof name. And I wanted to go with that, but changing that name in the database — well, it was possible for the most part, but not everywhere. So what I ended up doing was I said, you know what, I'm gonna change the name wherever I can except for the few places where I can't. And that's going to be version two. So people who were on version one can go to version two and nothing will crash. But at the same time, I'm gonna release version three, which is exactly the same as version two — an exact copy, except it will have those new names also in the machine names. And that was a really dumb idea, but it worked.

[00:18:31] Michael Meyers: So tell me more about that upgrade path. If I'm on two, do I need to go to three to get to four?

[00:18:44] Kristiaan Van den Eynde: Yeah, so you do have to go to version three first, and then you can go to version four just like anyone else. So the whole point is that in the latest update hooks, the code that we write to allow you to update your software — in version three I've added some of that code that allows you to download version three on top of version two and run those updates and it will do most of the heavy lifting for you. And then there's this user manual on drupal.org that tells you exactly what to do after that, because there will be some files on your disc that you need to look through and make some changes. There will be custom code that you need to make some changes to, because I cannot predict which or what custom code you've written for your project. But all of that is written down in these documents and it has steps to follow. Nowadays, obviously most projects start with version three, and soon they will start with version four. So for them it's a non-issue. It's just for those legacy projects that keep upgrading to the latest version to have like secure software with coverage and everything. You wouldn't wanna put a junior on that — you wanna put one of your best people on that.

[00:20:30] Michael Meyers: If I am launching a new site and using Group, what module should I be using today? Should I be using three? Is four something I can start with today?

[00:20:44] Kristiaan Van den Eynde: You should be using three because the upgrade to four should be quite seamless. But if you want, you can try out four already — it's actually very stable. It's just that it's a dev release right now and that means I do still reserve the right to make drastic changes. I don't envision making them anymore because most of the roadmap that I had in mind is completed. The data architecture is the same as I want it to be. It's just some features right now, some UX polish because it's actually like 90% done, perhaps even more. So you could try starting on version four already. I probably won't blow up your project, but keep in mind that there is a chance that I still might — probably not, though.

[00:22:10] Michael Meyers: Another big change that you've made is really addressing this amazing module ecosystem that you've created. You have subGroups, Group Sites, context providers — there's a lot of modules and submodules that are part of Group. My understanding is now you want to pull some or all or a lot of that back into the main module. What's driving that decision?

[00:22:40] Kristiaan Van den Eynde: Maintenance. Really just maintenance. To give you an idea: for each update that I made for Group two or three right now, let's say I made a new release which deprecated some code — that's technical speak for functionality that would no longer be supported in the future — whenever I did that, I needed to create that for version three, then if it had any of those funky names, I needed to also create a version for two where those names are changed. Then I needed to go to my subGroup module and start implementing those changes. And do that for version two there too, because just like Group, subGroup had two versions to support both versions of Group. And I would have to do that for all of my ecosystem modules that I was maintaining. The reason that I had all of these modules out there in an ecosystem to begin with was to have them as examples — because I do not believe in privileged code. I do not believe that if I want to offer functionality from within Group that my code should have special access to do stuff. What I can do, you should be able to do. That's always been the premise of how I write my code. So by having subGroup and Group Sites as standalone modules, it's truly a testament to that fact — to show people that you can do this with Group. But it's become such a pain to maintain because now I have multiple issue queues, multiple versions. If I want to create a new release, I have to do that for all of these modules. The whole concept of bloat no longer exists on today's internet — downloading a couple of extra megabytes is no longer a hurdle. So getting all of that code back into the main module would mean that if I make these changes, I can do it all in one go.

[00:27:57] Michael Meyers: You mentioned Group Sites a couple of times there. Give me a sense of why it's such a big deal, especially for organizations that are running essentially multiple sites off of a Drupal installation.

[00:28:25] Kristiaan Van den Eynde: So out of the box, Drupal has always had this concept of multisites. And as you know, I'm trying not to offend anyone, but I'm pretty sure that no one is actively maintaining that. It's horrible. The way it works — it hasn't really been revisited in ages. It hasn't caught up with modern times at all. And I noticed that a lot of people were using Group to create multiple microsites within one website so that in a back office they could add all of the content they wanted and it would show up on one or multiple microsites. I saw this really great example of this like many years ago when I was working in the UK. We had this website for a lot of pubs, but it was all maintained by this one large brewery. Each pub would have its own look and feel, its own style, its own domain name. And they were using Group for that already — sure — but they had a lot of custom code. I wanted to make this more accessible because this is something awesome. So I set out with this concept and I created it and instantly got amazing feedback. We managed to sell the idea to one of our clients when I was working in Germany at Factorial, which was a large multinational. And their whole new web platform is built on Group Sites and it's really fast. And then we had Local Gov, based in the UK — they had a couple sessions at Dev Days outlining how they were using Group Sites and how they actually built something before they realized that Group Sites existed. And they were like, oh, this is awesome. And they actually went through the effort to move everything to Group Sites. So now we actually have a modern solution for microsites in Drupal.

[00:31:43] Kristiaan Van den Eynde: Moshe Weitzman — both he and I maintain the user system subsystem in core. And during one of these talks that we had with subsystem maintainers a couple months ago, Moshe was actually saying, why do we still have this multisite system in core? It needs to go. And he really meant: we should just bank on Group to get that part sorted. It doesn't belong in core anymore. And I fully agree with him — not because I'm the author of Group, but just because as a core maintainer, it doesn't make sense to have that in core now that we have the Access Policy API in core. Anything is possible, especially multisites. So let's just put that in Group. It leverages all of the latest technology and it allows you to just choose any sort of context in which you want to trigger which microsite is active — whether that's a domain name or part of the path in the URL or your location in the world or anything we can detect from the context of your browser session. We can use that to choose which microsite to show you. And it basically just tells the database, I know you have like a million microsites in there, but I only need this one — and the database, because of some trickery with the Access Policy API, will go, oh okay, that's fine, I just forgot that there are like 999,000 other websites out there. Which makes all of the queries really fast. So yeah, it's one of the things I'm most proud of because it's the accumulation of all of the things I've built over the past decade and it works so well together.

[00:39:24] Michael Meyers: I think one of the things that I love about you is your critical approach to things — not just what you were talking about earlier about how things are implemented in core and we should rip them out, but you're also really candid about your own code, your own product Group and what you can improve. And I know that's a big thing you're trying to address in version four. The editorial experience is probably the perfect example of that. You've been the first guy to say, yeah, it's been rough, there are clear challenges with this. Can you tell us how you're trying to address some of the workflow issues and capabilities for editors?

[00:40:22] Kristiaan Van den Eynde: Yeah, definitely. So quick backstory — trying to get content into a Group can be really annoying, depending on how you set it up. Not every piece of content that you want to put in the Group is treated similarly. So if you want to put a page or an article in a Group, you just care about that page or article being in the Group. You don't usually want to specify why or how you put that inside the Group. But alternatively, if you want to put a user in a Group, there are multiple ways to do that, but usually it's under the guise of a membership. So you want to put that user inside of a Group, but now you do care about why or how that user belongs to that Group. So we have some extra information on that relationship — for instance, which roles they should have in that Group. One user could belong to Group A with no roles, but could belong to Group B with very administrative level roles.

[00:41:48] Kristiaan Van den Eynde: Now the issue with that is that we need to show a form for that metadata. And so in the past, the best I could come up with was to create this sort of wizard where you could configure whether or not you wanted that second step to specify the metadata. So at first you would have this form to create a page, and then if we didn't get to that second step, great — you would just create that page and that would go inside the Group immediately. But sometimes if you misconfigured that, or if you did need that second step, people would end up on this form where they were supposed to specify metadata about why this article belongs to a Group. And it would confuse them because they just created an article and now they're on a second form — what's going on? And sometimes that form would even be empty because some administrators would see fields there but a regular user wouldn't. So when they got to that form it was just blank, and they had a button to click save, and then their article got added to their Group, which made no sense whatsoever. So that user experience was horrible, to say the least.

[00:43:57] Kristiaan Van den Eynde: So now for version four, I've managed to find a lightweight alternative where you absolutely no longer have that second step. But I sort of check if there is metadata required for the relationship. And if it is required, then you will see it on the first form and it will validate properly, it will save properly. But you will never have more than one form. And if there's nothing to show, it will just show nothing. So you won't have a second step that's blank — you will just have your original form.

[00:44:37] Kristiaan Van den Eynde: The second thing is that people who have worked with Group will notice that if they want to create a page inside a Group, they do so on a custom URL — it's something like slash Group slash the ID of the Group slash content slash add slash node column page. It's a very funky URL. And it looks exactly the same as if you were to go to the regular form to add a page, but yet it's at a different URL and it behaves differently and some of the options aren't available. That was because I needed to know what Group you're trying to add this page to. But it's annoying because people who are trying to alter this form now there are like two forms and they need to make sure they change it everywhere.

[00:46:07] Kristiaan Van den Eynde: So one of the things that I'm trying to do for version four — this will not land in version 4.0, but I'm trying to get it in for version 4.1 — is this notion of context. By taking what I've built for Group Sites, which is very good at detecting what Group, what microsite we're trying to show you — what if we take that same system, we put it in the main module, and we use that so that at any point in time, you as an editor can say, I'm currently working on this microsite, or if you're not using microsite, just I'm working on this Group. And now you can go to all the regular forms anywhere. So if you want to add a page, you go to the form where people on a regular Drupal site would add a page. If you want to add a user, same story. And then Group behind the scenes knows the context that the editor is in. So the editor is currently trying to add something to, let's say, the Belgium website — and I would know that, so when they add a page I would know to put that in the Belgian Group. Imagine not having to train your users: if you want to add a page to the regular site, you have to go here, and if you want to add a page to this special section of the site, you have to go here. No — just if you want to add a page, you go there and it will just work. I think that's pretty awesome compared to what we have now.

[00:50:03] Michael Meyers: I know one of the things that you've talked about is wanting to raise PHPStan levels and code quality standards on Group over time. Could you give a little bit of backstory and then, why is it that you want to make it even better? What's your focus here?

[00:50:35] Kristiaan Van den Eynde: So for those who are unaware, PHPStan is a sort of analysis tool that looks at your code and tells you where you are or might be doing things wrong. And it has multiple levels. At the lower levels it complains about very basic things. And as you go up, it starts complaining about all the things. What this means is that you could start at the ground level and add this tool to your module, and it will tell you all the places where you're doing the very basic stuff wrong. And then you clean that up because it leads to more stable code. It also means that people who are using your code can use it in a more stable manner — they can only offer the data that your code expects and they will get data in return that your code promises it will return. And as you go up and increase the level, it will start complaining about more technical stuff.

[00:53:01] Kristiaan Van den Eynde: While Group has a lot of UI elements and does a lot of magic out of the box, in its core I've always considered it an API module — because there is so much that you can do with it with custom code behind the scenes. I want to make sure that it's an API-first module, that the code comes first and then I build a UI on top of it while calling my own API, so to speak. And this goes back to what I talked about previously — I don't like privileged code. So if I can build a form for my module and someone else can build a form too, how do we achieve that? By having a good API so that my form can call that API and someone else's form could just as similarly call my API. And I think one of the ways to keep getting better is to make sure that we grab all the old code, we clean it up, and we raise the level. And then when we write new code, it has to adhere to that higher standard. And then we raise the level again and again and again until we get close to or actually reach the highest standards. And then once you have code that adheres to that highest standard, it should be so well written and perhaps so abstract that you could look at the pieces that are doing something special, take those out of the module, and put those in core or put those into a PHP library that even non-Drupal projects can use.

[00:56:04] Michael Meyers: Is there anything that you want to cover about the future of Group that I haven't asked about?

[00:56:19] Kristiaan Van den Eynde: Yeah. So very recently people have talked to me about some ideas they had, and I got really excited about them. There are two in particular. One of them is public versus private Groups. It's something that I know exists in this distribution called Open Social and I know that they've been sort of struggling with getting that to work correctly. They've managed obviously, but they've had to write a bunch of custom code. Recently, internally at Tag1, a coworker asked me how would you envision this functionality? And obviously when given a blank canvas I go nuts — that's where I have fun. So I thought, let's entertain this thought. Is this possible? Is this manageable? Would this be performant enough to make into something real? And the answer is it's actually very doable. So I gave that coworker some pointers and then I realized it actually wouldn't be that much work to do this myself and put this in the main module. If Open Social or anyone from Open Social happens to listen in, they're probably gonna get a real jump scare here because it might be coming to Group. The cool thing would be that we could just hand out two separate sets of permissions. Like if the Group is public, people from certain roles would get certain permissions, but then if the Group becomes private, they would get different sets of permissions. And with that in mind, we could have something really cool where Groups are hidden and then if you get a sort of access key or beta access, then all of a sudden that Group would be accessible to you.

[00:59:52] Kristiaan Van den Eynde: And then the other thing is something that I can see ending up in Drupal core. Currently when we build lists in Drupal, we don't have a lot of options to limit access to what you should be seeing in that list. If you take the front page of any Drupal website, you could usually see a list of articles, right? But you don't see all of the articles in the system. You don't see the ones that are still unpublished. You don't see the ones that have some sort of access control, whether that's Group or domain or any other access module. Because of a thing called query access — when we go to the database to ask for all of the articles it can show us, we actually reduce that list to the ones that we know you can see. And the key verb here is "see." We have something similar for two other operations — you can build a list of articles as an editor saying, show me the articles that I can edit or show me the articles that I can delete. And that's pretty cool. But it's very limited. I've been contacted by people who want to build these lists for stuff that resides in a Group, and they don't know how to pull that off because in Drupal we only have those three basic operations: can you view it, can you update it, can you delete it. And they wanted a list of stuff that they can put into a specific Group, or they wanted a list of users who have access to join a particular Group, or a list of Groups that they have access to join. Now I have this idea where instead of just limiting ourselves to those three verbs, we can add a piece of metadata on the query that we send to the database where we say, I'm trying to do something in the context of this Group, show me a list of things that follow those conditions. And this seems like something that I would at first build inside of Group, but then if it works really well, we should probably put that in core. It's 2026 — it really doesn't make sense that you can only retrieve lists from the database for three verbs when Drupal has evolved into a system where people want to do all sorts of things and create all sorts of lists.

[01:04:04] Kristiaan Van den Eynde: With that reality, I'm just gonna tidy up this one issue that I'm still working on and that's going to be Group 4.0. And then the other features will be 4.1, 4.2, and it will gradually become more awesome. I've had a crazy year — I'm renovating my house, I changed jobs, I started a business, I've had some health issues. 2025 has thrown a lot my way and I lost a lot of time that I wanted to spend on Group and core. But we'll have to settle for all of the stuff that I did in early 2025 plus some efforts that I've done recently, and we'll see how we go from there.

[01:04:58] Michael Meyers: It's amazing. Thank you for all your hard effort on it. I purposely didn't ask about your roadmaps and deadlines and milestones. Being a maintainer of a module like this takes a tremendous amount of work and effort on top of everything else that you have going on in your life. And people can never appreciate that enough — the sacrifices you make to make this happen. So really, your openness, your honesty, your willingness to be self-critical and critical of the platform in the hopes of making it better — sharing your insights and challenges has been really fascinating to me and hopefully really helpful to other module maintainers. I think there are some really great topics we can follow up on, and hopefully now people have a really good sense of where you're going with this and why and what's important to you. Again, thank you so much for joining me. A big thank you to all our listeners. You can check out past episodes at tag1.com/podcast. Send us your feedback about Group, about the podcast, about future topics you'd like us to cover. You can reach us at [email protected], that's TAG the number one .com. And of course, subscribe so you don't miss out on future conversations. Special thanks to Tracy Cooper and June Gregg for producing today's episode with input from Hank Vanzile and Cassey Bowden. Until next time, take care.