Add compatibility with Group 2.x

Dylan Donkersgoed → made their first commit to this issue’s fork.

I added some logic to switch the entity machine names depending on which one is available. This seems to be all that's needed to make it work for 3.x as well.

I did some quick testing of the functionality and I see to be able to, e.g., have one user create a draft and then another user find and publish it. I tested in 3.x. I assume this would work in 2.x as well since I didn't change anything else and as I understand it the APIs are the same, but you may still want to check it yourself.

Cool!
Any chances to see it merged?

I guess the new version of the module should be created. The current version should continue to support Groups 1.x (and maybe 2.x)
The new version for Groups 3.x.

Tested this with group 2.0.0-rc2 and the patch works as expected.

This was RTBC in #12 but I don't quite understand the changes that were added in #14 where another branch was merged into this one. The work that was added there has not been reviewed yet. Maybe jrglasgow can add some commentary to the changes that where added there to aid in review?

I've created a patch without the changes from #14, I see some d10 related stuff, doesn't make any sense to me.

Just wondering when this patch will be merged? Can't wait to use it! Thanks a lot for everybody's work on it.

I tested patch #16 with Group v2.1.0. The patch wouldn't apply for me with composer, but manually applying the patch with git worked. Once applied the content moderation functional worked with my testing. Setting to RTBC.

It would be good to get the patch merged as it is not exactly easy to properly manage the module via composer when using Group 2.x and this patch from #16: https://www.drupal.org/project/gcontent_moderation/issues/3309542#commen... 💬 Is group content moderation module compatible with Groups 2.0.0-beta3? Needs work though you will most likely need to create a new branch compatible with Group 2.x.

The problem is that composer is looking into modules's composer.json for requirements before the patch is applied to switch requirements from Group 1.x to Group 2.x.

I had to use the following workaround inspired by StackOverflow: Is it possible to ignore child dependencies in Composer config? https://stackoverflow.com/a/53970732

    "repositories": [
        {
            "type": "package",
            "package": {
                "name": "custom/gcontent_moderation",
                "version": "1.0.0-beta2",
                "dist": {
                    "type": "zip",
                    "url": "https://ftp.drupal.org/files/projects/gcontent_moderation-1.0.0-beta2.zip",
                    "reference": "1.0.0-beta2"
                },
                "require": {
                    "drupal/core": "^8.8 || ^9",
                    "drupal/group": "^2.0"
                },
                "autoload": {
                    "classmap": ["."]
                }
            }
        }
    ],

I'm not sure yet about the bit:

"autoload": {
    "classmap": ["."]
}

it might need to get removed.

Tested MR #5, and it works well with Group 3.x and Drupal 9.5.x. I recommend merging this MR on a new major version (e.g. 2.x) which will be compatible with Group 2.x and 3.x. The 1.x version can still be maintained to support sites using Group 1.x.

I agree with mmenavas #20
It's hard to test and provide feedback without this being merged

Following the information from Updating your modules to Group 2.0 API "Database structure" section https://www.drupal.org/docs/contributed-modules/group/updating-your-modu... → , the group_content_field_data must be replaced with group_relationship_field_data and the current patch from #16 is missing it.

The table name must be replaced in Views sql JOIN's aliases as well, e.g. group_relationship_field_data_node_field_data . Example of such Views LEFT JOIN:

LEFT JOIN "group_relationship_field_data" "group_relationship_field_data_media_field_data" ON media_field_data.mid = group_relationship_field_data_media_field_data.entity_id AND group_relationship_field_data_media_field_data.plugin_id IN ( :views_join_condition_0__0, :views_join_condition_0__1, :views_join_condition_0__2, :views_join_condition_0__3, :views_join_condition_0__4 )

I'm attaching a patch that adds the required change on top of the patch from #16.

Following the conversation above I agree with #20:

I recommend merging this MR on a new major version (e.g. 2.x) which will be compatible with Group 2.x and 3.x

I believe it's clear this module must support (move to) Group 2.x / 3.x for the following reasons:

• The 8.x-1.x version of Group receives only Security
• Anyone using Group contrib planning future for his project will need to receive more than Security fixes.
• Though the 8.x-1.x version info file states it is compatible with Drupal 10 (https://git.drupalcode.org/project/group/-/blob/8.x-1.x/group.info.yml), the description of the project page states otherwise:
  Branch | Core support | Status
  8.x-1.x | Drupal 8 / 9 | Security fixes only
• Recently merged D10 compatibility fixes ( https://www.drupal.org/project/gcontent_moderation/issues/3297291 📌 Automated Drupal 10 compatibility fixes Fixed ) currently in dev branch 1.x-dev#46bd24592 should get release soon, is not compatible with this patch here (we will have to update it here anyway if we are not getting a separate 2.x branch (stream) for it.

I've updated the patch from #22 to include the "Automated Drupal 10 compatibility fixes" from https://www.drupal.org/project/gcontent_moderation/issues/3297291 📌 Automated Drupal 10 compatibility fixes Fixed making it possible to run gcontent_moderation with Group 2.x / 3.x on D10.

The patch is done against 1.0.0-beta2 and NOT the 1.x-dev.

Here's an update patch from #22 that is against 1.x-dev and thus D10 compatible.

The last submitted patch, 26: 3309542-26-group-2.x-compatability-update.patch, failed testing. View results →
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

Running the drush upgrade_status:analyze gcontent_moderation (using the https://www.drupal.org/project/upgrade_status → contrib to check D10 compatibility), I found:

• A.) mistake in composer.json not being valid and I fixed it, hence the new patch.
• B.) Problem with: Call to deprecated method prophesize(), but I can not fix it just easily as there's not specify how to replace the usage. Searching online I haven't found it withing reasonable time. It is not even clear if it needs to be replaced for D10 compatibility or it is just an upgrade_status bug (as mentioned in some comments I found):
  

  /gcontent_moderation/tests/src/Kernel/ContentModerationIntegr
  ationTest.php
  
  STATUS         LINE                           MESSAGE                           
  --------------------------------------------------------------------------------
  Check manually 132  Call to deprecated method prophesize() of class             
                      PHPUnit\Framework\TestCase:                                 
                      https://github.com/sebastianbergmann/phpunit/issues/4141    
  --------------------------------------------------------------------------------
  Check manually 138  Call to deprecated method prophesize() of class             
                      PHPUnit\Framework\TestCase:                                 
                      https://github.com/sebastianbergmann/phpunit/issues/4141    
  --------------------------------------------------------------------------------
  

I'm updating the MR to apply the latest patch since installing this module with the patch is rather difficult with the composer requires on 1.x-dev. Will include instructions for installing directly from the MR after I've done so.

Okay, I think that did it. Please continue development using the MR to make this easier to install, test, and track.

Also @dabbor I noticed your patch restricts to group:^2.0 but the MR was noted as working on Group 3, so I've updated it to ^2.0 || ^3.0.

To install the MR and avoid Composer yelling re: version conflicts, add the following as the first item in the repositories list in composer.json:

    "repositories": [
        {
            "name": "drupal/gcontent_moderation",
            "type": "vcs",
            "url": "https://git.drupalcode.org/issue/gcontent_moderation-3309542.git"
        },

Do not forget to remove this later should the MR make it to a stable release or you will end up downloading an old version of 1.x-dev.

Then run the following Composer command:

composer require drupal/gcontent_moderation:dev-3309542-is-group-content#6b6ddc80

Note that #6b6ddc80 is the latest commit as of this writing; if the MR updates you should update the commit to that hash after vetting it. Never require a dev branch without pinning to a commit.

FYI - until commit 1ac47612 (24 August) This fork was working for my needs for both Group 2.x and Group 3,x... Since commit 1ac47612 it is no longer working for Group 3.x so I have re-opened 📌 Make compatible with Group 3.x Active and basing the solution on this branch, but changing the entity names to match Group 3.x.

Okay, I think I see what the problem is. The latest patches seem to omit some of the logic that was added to determine whether Group is version 2 or 3.

For example, these lines

I assumed the patches were continuing work done in the MR but that doesn't seem to be the case. I'll try carefully rolling back these changes where I find them.

I should note that in some places it doesn't look like we'll be able to easily suss out Group version 2 or 3, such as configuration files here

I'm not sure if the solution should be to release two new major versions of the module targeting Group 2 and 3 separately, or to go through extra effort to use the correct tables and machine names in config.

Okay, I think that should do it. Here are all the changes between the latest version and the March commit to the MR -- the 2.x vs 3.x checks have been reinstated.

These changes technically target 3.x due to the use of group_relationship for table names in .yml files (instead of group_content per the 3.0.0 CR → ), but sites using Group 2.x should already be established and likely already using this module with config exported.

The biggest problem I see is in this .views.inc file, since I'm not sure how we're supposed to figure out which table name to use.

If this module releases separate 2.x and 3.x branches to handle the differences, then the final commit for this MR should use group_content where it's not possible to check which one is needed. Then the first and hopefully only deviating commit to 3.x would be to update them to group_relationship. The module would then otherwise follow Group's model of keeping both 2.x and 3.x identical moving forward with the exception of those few lines of code.

if anyone wants to use this module with the Group 2.x
They can use https://github.com/naveenvalecha/gcontent_moderation/tree/2.2.x

EntityTypeManager dependency was added on construct but not on create so I've added that.

Moving it to the right branch

Someone should do the manual QA and RTBC it

I have review the MR. I was able to install the module with the changes.

PR has been merged to 2.0.x
It will be rolled out in next release.

Automatically closed - issue fixed for 2 weeks with no activity.