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

Command icon 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:

Comments

brad.bulger created an issue. See original summary.

brad.bulger’s picture

Title: compatbility with subgroup module » compatibility with subgroup module
dwkitchen’s picture

Title: compatibility with subgroup module » Change GroupContentEnabler id for compatibility with subgroup module
Category: Support request » Feature request

They are currently incompatible as GroupContentEnabler in both modules has the id subgroup

https://git.drupalcode.org/project/ggroup/-/blob/1.0.x/src/Plugin/GroupC...

This could be changed to ggroup in the ggroup module giving the subgroup module the subgroup namespace. There would be a need for a lot of DB updates though.

brad.bulger’s picture

I 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?

dwkitchen’s picture

@brad.bulger It is just the machine name, and visually in the UI for regular users, they can both be called Sub-Groups.

brad.bulger’s picture

Experimenting 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?

lobsterr’s picture

It 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.

lobsterr’s picture

It 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.

lobsterr’s picture

Status: Active » Needs review

I have provided a hook_update, which will replace configuration to make it possible to replace plugin_id. Please check.

lobsterr’s picture

Status: Needs review » Needs work

It is still broken, I need to check what else did I miss here

brad.bulger’s picture

I'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?

lobsterr’s picture

we can't install currently at the same time, so, it means I can safely run an update hook, looking by subgroup plugin id

dwkitchen’s picture

@LOBsTerr my db has ~8,000 groups - I will test running the dbup tonight and report back!

lobsterr’s picture

I 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.

dwkitchen’s picture

Title: Change GroupContentEnabler id for compatibility with subgroup module » Change GroupRelationship id for compatibility with subgroup module
Version: 1.0.0-alpha3 » 3.0.x-dev
lobsterr’s picture

Version: 3.0.x-dev » 1.0.x-dev

We 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

socialnicheguru’s picture

How about group 2.x?

catch’s picture

ggroup 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.