🇺🇸United States @adriancotter

Thanks @awasson I had this same issue -- and indeed, I had also not installed the library. Once I got that in it started working again.

Added some documentation about how to do pulls and pushes, and some basic information about mapping which didn't seem to otherwise be present.

Hey Kristiaan, unfortunately, we've not seen any great gains with performance after the change. All of our Group users now have an Outsider or Insider role of one type or another. There are still some individual roles that some percentage of user have (hoping still to reduce one or two more individual roles).

Overall, through Blackfire profiling, comparing before the upgrade to after,

• The overall site memory use (I think the graph is an average) has gone from roughly 14-17MB to 16-20MB (comparing about a weeks worth of time). The latter might have been 1 or 2 MB higher when I first made the switch, so there might have been some gain, but it is not as clear in the graph.
• Looking at the NodeViewController information -- its gone from a 53% impact to a 72% impact (memory 36.4 to 52.5 MB)
• Our overall cache use seems to have gone up (in terms of CPU processing)

I also excluded user.group_permissions from cache as per this page:
https://www.drupal.org/docs/contributed-modules/group/turning-off-cachin... →
(we have ~300 groups averaging 2-3 active members)

We've been working to try and eliminate any other processes of concern. Obviously there's a lot to any particular site and group configuration. Our particular use of Group, custom code, there might be some other things we should be doing differently now.

If there's a better place to bring this up, or you'd prefer I start a separate ticket, please let me know. Appreciate any thoughts or additional pointers.

Ah, I figured out the answer shortly after writing this out, but hopefully it will help someone else.

You have to create another Outside role for Authenticated Users and set permissions accordingly.

If there's another way to do it, please let me know. But I appreciate the sense this makes in context of Drupal permissions themselves.

adriancotter → created an issue.

Ok, I went back to your group permissions youtube video and understood it a bit better than the last time, at least in terms of what I can do to switch up my existing set of memberships -- and see there you mention performance hit, which I totally missed. I don't think I understand why it impacts performance so much when the traffic is mostly anonymous, but I can figure out that later.
https://www.youtube.com/watch?v=xo2z8NuKEH4

All Group gets from core is "this is a node query", not "this is an article query", so Group has to run its access checks on the node types that are grouped.

As to the queries, conceptually I understand what you are saying here. I also think the queries I'm seeing in the views admin were for the admin user -- which I definitely didn't have properly set up as an outside member.
I guess I'd hope it'd be more efficient when it wasn't necessary (outside of any group context in particular) but I also know this is a complicated tool -- and appreciate all your work here.
Haste makes wastes as they say -- I should have watched the video a few more times. Thanks for being so responsive in these threads.

Those do not make it into the query unless you installed them on a group type.

That is not my experience. These views where I am seeing the query altered are looking at content that are NOT installed on a group type. Have a query below

This means you have a large amount of "individual" group roles assigned, see if you can get rid of many of these memberships in favor of synchronized roles (outsider/insider). They will drastically speed up your queries.

The list is of installed group node plugins and group IDs... I'm not sure how that relates to our member group roles. We do have about a dozen. Most people only have 1 or 2 roles assigned.

I have a very simple view that looks at the published pages of a certain article content type (sierraarticle). It is not part of group, the article content type is not installed on any group type.

This is a shortened version of the query that I see just what is added on:
The query does include any of the nodes in that first Outer Join

LEFT OUTER JOIN {group_relationship_field_data} "gcfd" ON node_field_data.nid=gcfd.entity_id AND gcfd.plugin_id IN ('group_node:program_page', 'group_node:sierra_club_entity', 'group_node:sierra_club_entity_blog', 'group_node:sierra_club_entity_index_page', 'group_node:sierra_club_entity_legislation', 'group_node:sierra_club_entity_slideshow', 'group_node:webform')
LEFT OUTER JOIN {group_relationship_field_data} "gcfd_2" ON gcfd.gid=gcfd_2.gid AND gcfd_2.plugin_id='group_membership' AND gcfd_2.entity_id='1'
WHERE (("node_field_data"."status" = '1') AND ("node_field_data"."type" IN ('sierraarticle'))) AND (("gcfd"."entity_id" IS NULL) OR (("node_field_data"."status" = '0') AND ((("gcfd"."gid" IN ('28867', '629942', '489', '1983', '1992', '2001', '2030', '2041', '2042', '7505', '7891', '8435', '8633', '11805', '13483', '18307', '18776', '18835', '19019', '24185', '24532', '24857', '24871', '25041', '25353', '25370' ...

Thos numbers are the group IDs, and are repeated again for each group plugin node type.

For the moment, I have mitigated some of our problems by turning off query rewriting. But don't think I want to leave that as a permanent solution. If there's a way I can show you the setup, I'd be happy to try.

In looking further this definitely related to 3399969. So am going to make some comments in that thread.

Just upgraded to Group 2.0. So I am seeing Group add a huge group related query to many content views that we have -- whether or not it is related to group. I haven't gone back to compare this to how 1.x was working, but it does seem to be negatively effecting our site compared to 1.x.

Many of our content types are not used by group, and many views do not including any group content.
And in those views, I am seeing giant "gcfd"."gid" IN () for every group node plugin, even though they are not involved in a particular view. Our site speed is way down.

adriancotter → created an issue.

I have an error with #93 after I upgraded to 2.2.2, I am getting:
ArgumentCountError: Too few arguments to function Drupal\group\Access\GroupPermissionsHashGenerator::__construct(), 3 passed in ...web/core/lib/Drupal/Component/DependencyInjection/Container.php on line 259 and exactly 5 expected in Drupal\group\Access\GroupPermissionsHashGenerator->__construct() (line 70 of modules/contrib/group/src/Access/GroupPermissionsHashGenerator.php).

Any admin page throws an error. Group pages and related nodes also get the error. But non-group content is still viewable on the front end.

Steps to reproduce

We are still on Drupal 9.5.11
I got this after upgrading my Group module from 2.2.0 to 2.2.2
I was able to update to 2.2.1 ok

I decided to check if this patch might have an impact, when I saw the Token functions in the stack trace.
I don't immediately see where the patch might need to be tweaked.

When I took out the patch the errors went away.

Drupal\group\Access\GroupPermissionsHashGenerator->__construct(Object, Object, Object) (Line: 259)
Drupal\Component\DependencyInjection\Container->createService(Array, 'group_permission.hash_generator') (Line: 177)
Drupal\Component\DependencyInjection\Container->get('group_permission.hash_generator', 1) (Line: 434)
Drupal\Component\DependencyInjection\Container->resolveServicesAndParameters(Array) (Line: 237)
Drupal\Component\DependencyInjection\Container->createService(Array, 'cache_context.user.group_permissions') (Line: 177)
Drupal\Component\DependencyInjection\Container->get('cache_context.user.group_permissions') (Line: 223)
Drupal\Core\Cache\Context\CacheContextsManager->getService('user.group_permissions') (Line: 185)
Drupal\Core\Cache\Context\CacheContextsManager->optimizeTokens(Array) (Line: 111)
Drupal\Core\Cache\Context\CacheContextsManager->convertTokensToKeys(Array) (Line: 317)
Drupal\Core\Render\RenderCache->createCacheID(Array) (Line: 66)
Drupal\Core\Render\RenderCache->get(Array) (Line: 109)
Drupal\Core\Render\PlaceholderingRenderCache->get(Array) (Line: 77)
Drupal\Core\Render\RenderCache->get(Array) (Line: 109)
Drupal\Core\Render\PlaceholderingRenderCache->get(Array) (Line: 273)
Drupal\Core\Render\Renderer->doRender(Array) (Line: 446)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 204)
Drupal\Core\Render\Renderer->render(Array) (Line: 479)
Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1) (Line: 43)
__TwigTemplate_f60975c3bcef63585ca1e008bb6405ed->doDisplay(Array, Array) (Line: 405)
Twig\Template->displayWithErrorHandling(Array, Array) (Line: 378)
Twig\Template->display(Array) (Line: 390)
Twig\Template->render(Array) (Line: 55)
twig_render_template('themes/contrib/seven/templates/page.html.twig', Array) (Line: 384)
Drupal\Core\Theme\ThemeManager->render('page', Array) (Line: 433)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 204)
Drupal\Core\Render\Renderer->render(Array) (Line: 479)
Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1) (Line: 86)
__TwigTemplate_18e80ba8011e325cf036296dbb23f15b->doDisplay(Array, Array) (Line: 405)
Twig\Template->displayWithErrorHandling(Array, Array) (Line: 378)
Twig\Template->display(Array) (Line: 390)
Twig\Template->render(Array) (Line: 55)
twig_render_template('themes/contrib/seven/templates/classy/layout/html.html.twig', Array) (Line: 384)
Drupal\Core\Theme\ThemeManager->render('html', Array) (Line: 433)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 204)
Drupal\Core\Render\Renderer->render(Array) (Line: 162)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 580)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 163)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object)
call_user_func(Array, Object, 'kernel.view', Object) (Line: 142)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object, 'kernel.view') (Line: 174)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 81)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 44)
Drupal\redirect_after_login\RedirectMiddleware->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 718)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Seems like there might be a few different things being listed in this issue:

• For the general access issues tabs and actions available -- this I think is related to the fact that User1 no longer has automatic access to Group content. More info here: https://www.drupal.org/project/group/issues/3315050 💬 Sitewide Administrator permissions not working Closed: works as designed

• Given SafteyPin's errors list involving gnode token, I am wondering if people are using the patch for tokens and have not updated that patch to the relevant version?
  
  https://www.drupal.org/project/group/issues/2774827 💬 Get a token of a node's parent group to create a pathauto pattern Needs work

• Regarding the views errors - I did have a couple of views that I had tweaked in 1.5 that I had to fix after updating. I think i had to fix (remove and replace) either something in the relationship or context to resolve the error. I don't have the specifics of the fix but the views were group_members and group_content_manager

I was using Group Taxonomy and the string id patch (#2797793) which has been my main source of issues. I also had group_menu and a custom module. So I am not sure I can give an easy answer to reproducing.

I have walked a lot of that back with this patch on group taxonomy below and have things mostly working (the remaining issues I think are mostly about additional customization of my own around group taxonomy and paragraphs, and other modules like quick node clone, etc). I was able to update the site most importantly.
https://www.drupal.org/project/group_taxonomy/issues/3331610 📌 Support Group 2.x Needs review

I just want to weigh in on the question of Group 2.0 and 3.0 support which didn't have a particularly clear answer above. Both 2.0 and 3.0 are currently supported Group versions and will be for some time -- or such is my understanding. I just updated from 1.0 to 2.0 for instance. The module page says:

"Note: functionality between version 2 and 3 are kept in sync. Version 3 does not have an upgrade path from version 2 or version 1 as it requires a migration."

Some of the API names have changed, as per:
https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... →

This is for Group 2.0, I think 3.0 is similar
In this case from the documentation above:
getContentPlugin becomes just getPlugin

There's some other big changes around how the plugin is created, so this change may or may not be sufficient. Otherwise, the other big change is changing class references for GroupContent to GroupRelationship.

Plugin names stay the same between 1.0 and 2.0, but 3.0's are different.

Adrian

For me the problem is in the key_value in the collection named: "file.field_storage_definitions" -- because of the use of Group Taxonomy (in one case, even where it was no longer enabled). Group taxonomy added storage definitions for entity_id and entity_id_str but they are done using a class that is of the right instance for Drupal10's purposes.

I'm still at a loss at how to fix it right now. There has been some work around it, but the patch does not seem to be working from me.
https://www.drupal.org/project/group_taxonomy/issues/3331610 📌 Support Group 2.x Needs review

Sam or safety_pin did you ever find your way around it?
Deleting the keyvalue did not work for me. Nor did deleting the specific items within the value. Not really a viable approach for production in any case.

Hey jrglasgow thanks for the work on this.
If I am reading the thread correctly... if one is updating to Drupal 10
one needs to use this patch 3331610-9-support-group-2.x.patch (or an earlier one?)

And then once updated, remove that patch and use group_taxonomy-3232198-10.patch?

I am running into the TypeError: Drupal\Core\Entity\Sql\DefaultTableMapping error that you mention in #6, but struggling to get around it...

Thanks for any advice!

With the most recent TFA update (8.x-1.4 Stable release, released 29 November 2023), our users are getting multiple emails from the email plugin, and the codes don't seem to work. The patch seemed to be applied. Is anyone else having this issue?

Thanks for explanation and suggestions @larowlan

adriancotter → created an issue.