Group module - Error: Class Drupal\group\Entity\GroupContent not found

Okay I think I finally found the reason:

Quick node clone uses:

if (\Drupal::moduleHandler()->moduleExists('gnode')) {
      $group_contents = GroupContent::loadByEntity($node);
     [...]

in the module file.

The use statement:

use Drupal\group\Entity\GroupContent;

exists, but Group 3.x doesn't seem to have the Drupal\group\Entity\GroupContent class anymore!

So this needs an update. I see the following options:
a) Put "Quick Node Clone Group" into a submodule and define concrete version dependencies there
b) Add an if statement to check, if the class exists and thereby change the implementation
c) ...?

I try to create a patch that fix the incompatibility with Group v2 and v3.

I have push a possible solution where check when is necessary the version of module Group, and depending on the version a certain piece of code is execute with a control structure.

There is a new class, with static methods as helper.

The code has been pushed to the branch "8.x-1.x" of this force, I am not sure if it is ok use that branch.

I upload a patch file to apply the fix to text.

Thanks.

I do not know why but the test system has problems to apply the patch. I local and in our CI works and the error "fatal: git apply: bad git-diff - expected /dev/null on line 135" has no sense, so int he line 135 "dev/null" is.

I will try to fix it.

I upload a new version of the patch, only with format change.

i got the same error and the quick-node-clone-3352168-groups-v2.patch above fixed my error, thank you so much! i'm using Quick Node Clone 8.x-1.16 and Drupal 9.5.9

we're experiencing the same issue, the patch in #6 fixes it. thank you!

This is a problem for anyone using Group v2.x or Group v3.x

Group v1.x is no longer recommended.

An upgrade path exists from Group v1.x to Group v2.x.

New sites will often install Group v3.x.

Consider removing Group v1.x support entirely.

You're in a sticky situation by having this integration code but no real way to tie it to a specific version of Group. The idea of moving this integration code out into a submodule with defined dependencies and version constraints makes some sense. The current implementation uses a common method from before we had Composer support in Drupal. I understand why it was done this way, but it might be done differently now.

This is a duplicate of https://www.drupal.org/project/quick_node_clone/issues/3306677 ✨ Intercompatibility with Group module new versions Needs work .
Patch #5 from that issue fixes the problem and I think is a nicer solution than the one here in this issue. I think there needs to be some discussion about which approach is better and to close the relevant ticket.

I think this question should be closed as a duplicate in order to concentrate all efforts on one thing.

• In issue #3306677 ✨ Intercompatibility with Group module new versions Needs work , all patches are already posted as merge requests, allowing for automated testing.
• In the same patch I see the use of the extension.list.module service to determine the version of the group module, but this service is still considered internal and it may change ( #2940481 → ).