Drupal 10.1: Revisions tab appears twice on Groups

Have the same issue. Drupal 10.1.6, Group 3.2.1.

Same issue with Drupal 10.1.6, Group 2.2.1

The patch #2 fixed the issue.

The patch is for 3.x -- we are using 2.x -- is there a patch for that version please.

Please read the issue description.

This patch only works on Drupal 10.1.

Drupal 10.0 is not EOL until December 13th and even then it would be up to the project owner to decide whether to apply this patch as-is, making the project incompatible with Drupal <10.1.

If you're able to provide a patch that also works on Drupal 9.5 and Drupal 10.0 then please do so.

Here is a patch that should work for all versions.

@msnassar The patch in #12 works for all versions of Drupal (9/10) or all versions of Group? We are running Group 2.x.

@SomebodySysop It should work for all Group (1/2/3) and Drupal (9/10) versions. However, you don't need it for Drupal < 10.1
Note: This is a temporary fix. It can be used until Core and Group completely switch to the generic revision UI.

I'm curious now...

Patch #2 removed the group module's link task and patch #12 removed core's link task.

Which, if either is the correct approach?

Well... here's my take on a patch. Rather than simply removing one or the other, I went with checking the local menu for duplicate "Revisions" tabs and removing all but the first.

In theory it could be applied to any past or future version of Drupal or Group, and not do anything silly. Though I've only tried it on Drupal 10.1 and Group 3.2.x

This will be fixed in the next release because that one will bump the minimum supported core version to 10.2 and therefore allow me to remove my copy of the local task.

kristiaanvandeneynde → credited seanB → .

Will go with the fix from seanB in 🐛 Duplicate revisions tab with Drupal 10.1 Closed: duplicate , so adding credit. We can take that approach now that we've bumped the minimum version to D10.2 In a world where we kept older D10 versions supported, @ulethjay's patch actually makes sense, so I wouldn't consider it a dirty hack per se.

Right, this goes green so if anyone can confirm this is working on their end, I've got the +1 I need to commit this.

seanB's patch appears identical to the one I initially attached to this issue; I took it from RichardDavies on the parent ticket: https://www.drupal.org/project/group/issues/3029908#comment-15205403 ✨ Add revisions tab on groups Fixed

Yeah, you got credit too for that. Just mentioning why I'm adding seanB to the list.

I didn't write the patch though, so make sure to credit RichardDavies -- he got to this way before anyone else :P

kristiaanvandeneynde → credited RichardDavies → .

Anyway, I've just tested the other patch and it also appears to work. Not sure what's up with the different paths between the two files but as long as they commit to the actual project identically then it's a non-issue.

I have tested this on Drupal 10.1 on Group 2.x with an actual project (and been using the patch on production for months) and it checked out fine there.

However on Drupal 10.2/Group 3.2.2 with a sandbox project I should note that applying the patch on an existing installation results in a WSOD:

In DiscoveryTrait.php line 53:

  The "group_permission" plugin does not exist. Valid plugin IDs for Drupal\views\Plugin\ViewsPluginManager are: perm, role, none

I have no idea if it's a "just me" issue or not, but this definitely needs more testing on latest Drupal+Group 3.2.2 to confirm that committing this won't hose existing projects. I've reinstalled several times and I get the error whether I apply or un-apply the patch after installing and setting up Groups.

Given how all tests go green I'm erring on a "just you" issue :) But thanks for bringing it up, definitely something to keep an eye on.

Just confirmed this was working on on of our installations. Committing

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

Bug still present on Group 2.x...