The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Problem/Motivation
Open Social 6 introduced a new group type in the form of Flexible Groups. The final gap to the old group types was added in Open Social 10 with the addition of hidden flexible groups.
Flexible groups can do everything the old group types can do and better, allowing users to create groups that are outside of the normal mold. Additionally it's a lot easier to maintain a single group type built on group than it is to have multiple group types. For example in the creation of views, notifications or other extensions on top of groups.
Steps to reproduce
Proposed resolution
In a to be determined major version we will include update hooks that migrate the old group types to flexible groups. This should account for all field data (assuming this is also available on flexible groups) and group content (assuming the group content can be added to flexible groups). A proof of concept for this is currently available on GitHub.
The goal is to remove all configuration and code for these old group types in the same release as the update hook is included.
Remaining tasks
We would love to hear from the community if such a migration would cause you problems (and why) as well as gain better insight into what kind of customisations are built on top of the old group types (public_group, open_group, closed_group, and secret_group) and whether you have these customisations also available for flexible_group.
User interface changes
API changes
Any code related to public_group, open_group, closed_group, secret_group, will be removed. Open Social will only treat flexible_group as its group type and will stay out of the way from other things that may be built on the group module.
social_group will be trimmed to a module that contains common systems on top of group that can be re-used (e.g. member management) and social_group_flexible_group will contain all code specific to what is considered a "group" on an Open Social platform.
Comments
Comment #2
tt12 commentedDifferent roles will be able to create groups with different visibility settings if only flexible group remains?
Comment #3
kingdutchThanks for adding that use case! That's not currently possible so I've opened #3380962: Allow visibility settings for flexible groups to be limited to certain roles. Feel free to chime in with more info on what you'd need.
Comment #4
kingdutchComment #5
socialnicheguru commentedHow do you envision group content being handled?
Comment #6
kingdutchIn https://github.com/goalgorilla/open_social/pull/3693 we've merged the update hook that will migrate all the existing group types to Flexible Groups. This update hook will be part of the 13.0.0 release (for which we'll tag alpha/beta versions in advance).
The update hook is written in a way that looks at the different tables for the group module that we know about and will update the bundle field in the database. This means that group content will stick to the same group and have the same visibility but the group type of the group the content belongs to will change.
Our internal testing on data sets from some of our larger clients is showing that this strategy is working as expected. If you want to test this on a development environment with your own data set (so that you can see if anything is missing for your own customisations) then you can pull in the update hook by asking composer to fetch
dev-main. Do note that ourmainbranch is rapidly changing so you may run into other changes depending on what customisations you've made on top of the Open Social distribution.Comment #7
kingdutchComment #8
ronaldtebrake commentedPart of 13.0.0 (alpha1)