Problem/Motivation
The subgroup and ggroup modules have different advantages. Is it possible to use both of them in the same installation?
I created a test site with both enabled, and it seemed like the only thing I could use in the UI was the subgroup module. When I uninstalled that, then the ggroup UI became available.
Trying to add subgroup to a site where I had previously used ggroup failed with fatal errors about a missing plugin, but I wasn't sure if that was related to having already created group types and groups without having had the module installed.
Issue fork ggroup-3209627
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
- ggroup-3209627
changes, plain diff MR !2
Comments
Comment #2
brad.bulger commentedComment #3
dwkitchen commentedThey are currently incompatible as
GroupContentEnablerin both modules has the idsubgrouphttps://git.drupalcode.org/project/ggroup/-/blob/1.0.x/src/Plugin/GroupC...
This could be changed to
ggroupin theggroupmodule giving thesubgroupmodule thesubgroupnamespace. There would be a need for a lot of DB updates though.Comment #4
brad.bulger commentedI can see that it would also be a puzzler for wording. If these aren't subgroups because we're using "subgroup" for the Subgroup module, what would you call them?
Comment #5
dwkitchen commented@brad.bulger It is just the machine name, and visually in the UI for regular users, they can both be called Sub-Groups.
Comment #6
brad.bulger commentedExperimenting with this, I found I needed to change the plugin_id values in a few other files to get things to work correctly in an installation of just group and ggroup. The only place I see the new plugin_id value in a database dump is in the router table. It's also in group content_type config values. What other database or config values might need to be changed?
Comment #7
lobsterr commentedIt would be quite tricky to change it, because this plugin name also used for creation of group content type. I need to check what could be done here.
Comment #8
lobsterr commentedIt looks like we can change the plugin_id, by updating content_plugin property for group_content_types using subgroup, but I can't distinguish it from Subgroup module. I assume we can accept the condition that it doesn't exist in the system, because we can't install both of them in the same time.
I will prepare an update.
Comment #10
lobsterr commentedI have provided a hook_update, which will replace configuration to make it possible to replace plugin_id. Please check.
Comment #11
lobsterr commentedIt is still broken, I need to check what else did I miss here
Comment #12
brad.bulger commentedI'm sorry, I don't understand comment #8. If you can't install both modules at the same time, what is the motivation for any change?
Comment #13
lobsterr commentedwe can't install currently at the same time, so, it means I can safely run an update hook, looking by subgroup plugin id
Comment #14
dwkitchen commented@LOBsTerr my db has ~8,000 groups - I will test running the dbup tonight and report back!
Comment #15
lobsterr commentedI have done a further investigation. They way to implement this task
1) We need to change a "content_plugin", for all group content types, which are using subgroups.
2) Rename group content type. We actually can't rename config entities. So, the only way is to recreate it, because plugin_id is used to load group content type.
3) Recreate all the fields for these config entities
And these two last steps must be carefully tested.
Comment #17
dwkitchen commentedComment #18
lobsterr commentedWe don't want to target 3.0.x branch here. As mention in another ticket 3.0.x will be already with new ID and first we will provide a migration from 1.0.x and then for other branches. This way we give opportunity to use a new plugin id already right now for new isntallations
Comment #19
socialnicheguru commentedHow about group 2.x?
Comment #20
catchggroup 2.x is incompatible with groups 3, and there's no upgrade path from ggroup 2.x to 3.x. It is probably a bit late now, but I think this change should have been made in a 4.x branch so that the plugin upgrade path could have been decoupled from the groups upgrade path.
Changing the plugin ID in a minor release of 2.x seems quite disruptive here.