Compatibility with newer versions of Group module

Thanks for taking this on. I don't think I'll necessarily release a 3.x branch. 2.x might be enough to handle support for group v3.

The biggest difference between 2.x and 3.x is the machine name of the Group Content/Relationship entity and type. I've targeted 3.x, because, for one we need 3.x compatibility, but second because I figured it was an easier to update while manually working through the code (and can be easily search and replaced back)... I realize as I'm writing this I could have put CONSTANTS in that could be varied, there you go. I'm not sure how easy it would be to switch the machine names runtime, so it might require having two almost identical versions.

The work done so far switches most of the API, but isn't fully functional yet. I need to check if the way the access permissions don't need to be changed. I'll be working through, and maybe adding some more tests, which should hopefully be the best way to do, and understand, this.

I made some changes for group version 3, but when I want to create menu for group, it shows blank page. I think it's an access problem

> but when I want to create menu for group, it shows blank page. I think it's an access problem

It's when access is checked, but it was a mistake I made in updating the code. I'd already caught that one. But am still working through the permissions. Sorry I'm not pushing Work in Progress changes all the time, but can push something once the access checks at least in the permissions test work.

After creating a group menu link, the menu parent selector isn't visible, I don't understand where the problem comes from in the code.

https://www.drupal.org/project/menu_item_extras/issues/3282717#comment-1...
I found the solution, our project also uses the menu_item_extras module and it was causing a problem with the group_content_menu, use the code #2 of the link and the problem will be solved

The automated tests still need updating. I can't get all access testing correctly without https://git.drupalcode.org/issue/group_content_menu-3315163/-/blob/3.x/s... being called and denying access at times you'd don't want it to. Haven't got much time till Tuesday to prod it again properly.

Tests now pass. Permissions work.

It would probably be nice to tweak the appearance of content menu on the /group/{group}/content page further. Doing the trick of just returning FALSE for permissions doesn't work in group 3.x as it checks it more often, including to see if an operation is possible not just on a route. Getting rid of the canonical representation of the entity is one obvious way of helping removing confusing links/pages... but group assumes it exists, so that would require more patches... redirecting to /edit might help. Anyway, just thoughts. I think it's only that, and that's not a blocker.

Maybe starting a branch from here might help?

I'm not able to see a MR or a patch to review. But from my guessing, the work is in the 3.x branch. And if that is true, then it is missing:

• #3318592: Create permission is not honored
• #3317493: Integrate into core menus
• #3316966: Add a getter for menu manipulators on menu block
• #3313981: Node menu permission fixes

I understand that working on a moving target is _hard_. Can we get those issues merged into the mix and for now, throw up a patch or a MR to review?

Yes the 3.x branch. I couldn't really make a patch or MR as it is a new branch not something to be merged into the present Group 1.x supporting branch. Really it should be two branches and releases in the end for 2.x and 3.x

I'll have a look at those issues that have been resolved since the branch was forked.

Couldn't this module just release a version that supports v3 and v1? I have to admit I haven't tracked the release notes for v2 that closely, but I thought it was an interim version for BC and we could skip it.

For now, I'd like to see an MR against 1.x so I can track the changes. When all is done, I'll commit it as an independent branch.

I've merged 1.x and think I've fixed all issues arising.

Diff is https://git.drupalcode.org/issue/group_content_menu-3315163/-/compare/8....
I'll make a PR directly after posting this too.

I think the explanation is: Group 2.x is the same as 3.x except the machine names of the entities haven't been changed. The idea being you can upgrade from 1.x to 2.x; but stepping over to 3.x will mean migrating the entities into identical but differently named ones. So switching the 3.x supported version to 2.x would be the inverse of something like this https://git.drupalcode.org/project/ginvite/-/commit/e40daf6c51f75ffd5fca... replacing lots of relationship with content.
I guess people will want to upgrade existing sites, and they will end up on 2.x for now. I know what I'm working on at the moment is new so it's 3.x

> I'll make a PR directly after posting this too.

Or I won't because I can't. There's a MR !7 hidden at the top here that has been auto-closed. I can't re-open it. I can't make a new MR here or in gitlab. If https://git.drupalcode.org/issue/group_content_menu-3315163/-/compare/8.... doesn't help, I could make a patch out of it, or try pushing to yet another branch - suppose all my WIP commits want squashing anyway - and see if that will make it let me open a new MR?

See these Gitlab issue, hopefully it will be fixed soon:

• #3319143: Cannot create issue forks
• #3319123: "Issue fork creation failed!" after clicking "Create issue fork"

Agreed. We need 2 or 3 versions. I was hoping we could only support group 1 and group 3. Or that the version that supports v3 could also support v2. But maybe that is naive?

Please open an MR against the v1 branch for now. Don't let the absence of a v2 or v3 branch stop progress. When it is time to land the code, we can make the call _then_ which branch(s) are needed.

> Please open an MR against the v1 branch for now.

There is !7, but it's been auto closed and there's no way to re open it.

https://www.drupal.org/project/group_content_menu/issues/3315163#comment...
"Or I won't because I can't. There's a MR !7 hidden at the top here that has been auto-closed. I can't re-open it. I can't make a new MR here or in gitlab. If https://git.drupalcode.org/issue/group_content_menu-3315163/-/compare/8.... doesn't help, I could make a patch out of it, or try pushing to yet another branch - suppose all my WIP commits want squashing anyway - and see if that will make it let me open a new MR?"

I guess I just push it into yet another branch?

All being well 3.x-working is exactly the same as 3.x, but it allowed me to make a new MR for that.

The issue with opening a v2/v3 branch is that there is a lot of active development on the v1 branch that we don't want to loose. Right now, the v3 MR needs a re-base. Since we're basically chasing head here, let's hold off on renaming variables from $group_content => $group_relationship. Mainly to keep the merge conflicts to a minimum and make keeping the 2+ branches in sync. Really, the _minimal_ changes needed without extra noise will help. Yes, it would be nice to rename things to use the newer term, "relationship". But, let's do that in a follow-up in about 6 months after D10 is released, group v1 has a lot less installs and group v2/v3 is much more popular.

$ git merge origin/8.x-1.x 
Auto-merging group_content_menu.module
Auto-merging group_content_menu.services.yml
CONFLICT (content): Merge conflict in group_content_menu.services.yml
Auto-merging src/Controller/GroupContentMenuController.php
Auto-merging src/Plugin/Block/GroupMenuBlock.php
CONFLICT (modify/delete): src/Plugin/GroupContentMenuPermissionProvider.php deleted in HEAD and modified in origin/8.x-1.x.  Version origin/8.x-1.x of src/Plugin/GroupContentMenuPermissionProvider.php left in tree.

Hey Heddn,

Thanks for the work on group_content_menu, it's an important part of our puzzle. Just wanted to share our plans here in case it influences plans for a 3.x branch.

We're working on the LocalGov Drupal Microsites distribution, hosted over on Github (https://github.com/localgovdrupal/localgov_microsites_project) and we're looking to do a beta release soon. We've done a bunch of work to move to using Group 3.x before the beta release.

We're going to need the 3.x version of group_content_menu that Ekes has been working on. Ideally this would be on a branch here for visibility and further collaboration, but if not I guess we can continue working on the issue branch, pinning to a commit, or we could even maintain a version on GitHub if that makes more sense.

So far the menus in our various group / domain / microsites seem to be working well, but our testing continues.

We expect real world usage to start within the next couple of months.

My understanding is that the 2.x version of Group supports both namings of things, old and new, but the 3.x just the new names. As we are focussing solely on the 3.x that's where our focus is.

Let us know if/how we can help to maintain multiple versions.

Many thanks,

Finn

re #39, that's great info to have. What would you feel about a v2 branch for now? Then in ~6 months moving the v2 branch work into a v3 branch? And at that time sunset active support and backporting of features to v1/v2 branch? Something like that seems like it would give us the best of both worlds.

Or, if v2 will still support v1, don't create a new v2 branch at all right now. Just do the minimal to support both. Then in 6 months, fork a v3 branch and backport what we can to v1(v2) branch. But if it doesn't easily backport, the main focus is on improving v3 features/support. These are just a few options to put on the table. I have 4 sites that all heavily use this module. And they are all planning to upgrade to Drupal 10 and group 2/3 at some point in the next ~6 months. That's where the 6 months timeframe comes from. I imagine a lot of existing site installs will also leverage a similar upgrade path. So this seems like the smoothest upgrade path possible. While making sure the features don't diverge on the different versions of group.

Hi heddn and ekes, thanks for the work. As new projects were using Group 3.x, it's much appreciated to give them the module. Unfortunately Group Content Menu is still available for Group 1.x only

Also having the same issue with using Group V3 since starting a brand new project but would need this module as well.

> is still available for Group 1.x only
...
> would need this module as well

We're using it already. In the top level composer.json the repository is added https://github.com/localgovdrupal/localgov_microsites_project/blob/2.x/c... and excluded from coming via the normal drupal packagist source https://github.com/localgovdrupal/localgov_microsites_project/blob/2.x/c... then the 3.x branch is required https://github.com/localgovdrupal/localgov_microsites_group/blob/2.x/com...

Do use it! It's working for us. But if you do find any other bugs just report them here.

Wow, thank you ekes, will do

I have installed the module like ekes said in the #44 but I still think there should be some "official" version as well, just to be sure incase there are security updates or something else.

It seems like there is more interest in going directly to v3, instead of the interim v2. That will make it a bit harder to keep things in sync. But we can work with that. Does the v3 branch need to be rebased on v1 one last time? Let me create a v3 branch so we can do that. I'm going to intentionally skip a v2 branch (until someone decides it is needed).

OK, needs work to rebase on top of new 3.0.x branch!

The last commit on the 3.x branch (Group 3.x compatible) is merged with the latest commits from 2.x - rebase wasn't possible, and the merge had quite some conflict that manually needed fixing as I recall.

The 3.x branch from the issue fork is now merged. I think I've flagged the correct credit here. Thanks everyone for your assistance.