Document experiences for manual Group 2.x to 3.x update

Would be great to have the script posted so others can evaluate it.

Best approach would be to copy your website, remove all group related entities and uninstall group on the new copy, then update the code to 3.0.x on the new copy and finally reinstall Group and migrate your group related content from the old site to the new copy using the migrate module.

We are aware of what is said at 📌 Create official instructions for Group 2.x to 3.x migration Active . However, with all my respect, we think the best approach is having an upgrade path from major version to major version. That's what we are trying here and I would really appreaciate comments on this approach.

Hello @Tunic:

This script is a proof of concept at maybe is not working in every project.
It executes the action set in the description of this issue:

1. Renames the table "group_content__group_roles" to "group_relationship__group_roles" in the database.
2. Update configuration values: The script utilizes the "config.factory" service to update the configuration values and parameters related to the machine names "group_content", "group_content_type" and "group.content_type" replacing them with "group_relationship" and "group_relationship_type" and "group.relationship_type".
3. Rename configuration objects: Additionally, the script renames the configuration objects that were created based on the machine names.

It is a simple PHP class that I upload with the extensión txt: Helper Class →

Thanks.

Hello! A few months ago I had to perform this update on a few projects. From that experience I have created a more generic module for this task and have just published it here → . I hope it can help you, I don't know if it would work on all sites (I don't know if there are other configurations that are not being migrated properly).

Instructions on how to use it are in the module's README.md file.

Regards

@#5, #6, #7: The reason I did not provide an upgrade path is that I first had one but deemed it unsafe as there are simply too many things we cannot predict and we might leave people with a broken website.

Installing a clean v3 on a website and then migrating your v2 data into said site is always safe because your entity schema, fields, etc. are already in place and you're making sure the incoming data is correct.

You're free to use any module or code to try and upgrade directly, but please keep in mind that you might very well break your website in ways that might not immediately be apparent and therefore cause vague bug reports later on.

Thanks for your message on #8. Indeed, there are risks on using the upgrade path described here. If we do, we'll double check any bug found later to be sure it's from the module and not from the upgrade path used, we would like to have the issue queue clean of spurious errors.

I would like to ask a question. Eventually, there will be Group 4 release. Do you think it is possible there will be an upgrade path without migrating or do you think any Group 2.x site will need that copy-and-migrate upgrade path sooner or later?

#7, thanks for that link, we'll check it as well, and thanks for contributing it!

I hope that an upgrade path from v2 to v4 will be possible.

Maybe by then core has better support for this type of thing, but for now it's really hard to rename an entity type. I had an upgrade path that took care of the definitions, field definitions and views and it still broke in various ways because of how hard it is to do this properly.

The good news is that v4 is probably going to take years to land, so you'll have plenty of time to enjoy the v2/v3 API and if the time does come to move from v2 to v4, we'll hopefully have some (sponsored?) documentation and tools to help you migrate by then.

any update on the "Group Relationship" and "Group Relationship Type" entities need to be installed issue?

I'm working on our site's D9 to D10 upgrade and this error message is one of our lingering outliers.

I know this is a composer question, but I just finally got to Group 2.2 after nearly since the first effort. In reading about what it takes to go from 2.x to 3.x, I'm terrified.

Currently, my composer settings want to automatically upgrade me from Group 2.2.0 to 3.2.0. How can I change my composer settings to not allow any automatic upgrade to 3.x?

I know this probably isn't the place for this, but I expect everybody here knows how to do it.

You can stay on 2.2 for quite a long time, so don't worry too much about it. When the time is due to migrate to v3, which is when v4 comes out, I hope to have found a sponsor to help us write the documentation and perhaps helper module to assist people in making the upgrade.

Another story to share:
- Have a site with huge sitebuilding, but no content (it's not yet in production)

A drush site-install --existing-config fails because not only DB tables changed, but also a lot of config names.

What i did and encountered:
- Created a bash script that changes all names in config/sync directory (attached)
- After running that on my config, i tried drush site-install --existing-config
- That had some issues
- Of course, name changes like group_content_type_ad6738256f30d => group_relationship_type_ad6738256f30d broke the import, because "32 character limit"
- Also i had errors like "The content relationship plugin X could not be found". I cross-checked, but no idea why.
- In the end, i took the name-changed config, and deleted all content_relationship_type config. It only took 10 minutes to recreate them.

A solution #6 is pretty good for me.
I just updated it a bit:
- it's better to use regex patterns to search and replace values
- sometimes we need also to update config keys (not only values)
- it's not required to update IDs of the Relationship Types. We can keep them to prevent possible errors with IDs mentioned in #15

And of course, you need to update your custom code:
- group_content -> group_relationship
- group_content_type -> group_relationship_type

Make sure to keep an eye on 📌 Try to provide an upgrade path from 2.x.x to 3.x.x Active