Get a token of a node's parent group to create a pathauto pattern

You will need to define that token in gnode.tokes.inc. This is great candidate for a patch.

See node_token_info(), node_tokens, group_token_info() and group_tokens() for group-related tokens.

Here's a first attempt at that.

The patch exposes all group tokens for nodes. [node:group:title]/[node:title] will default to [node:title] if the node does not belong to a group. Also, taking only the first returned group, in case the node belongs to more than one.

Will look at providing tests as well.

+++ b/modules/gnode/gnode.tokens.inc
@@ -0,0 +1,59 @@
+  $group_content = array_pop($group_content_array);

Seeing as nodes can now have multiple parents, why not create a [node:group] token as an array of groups? If you configured the group_node plugin to only allow for one parent (through the UI), then you can use the tokens with the delta 0.

If you do, however, allow for multiple parents, then at least we also have tokens covering that use case.

Hmm - running group beta1 with the patch applied is allowing me to choose the tokens but they are not creating paths that include that extra information.

path pattern added:

tstories/[node:group:author]/[node:group:title]/[node:title]

what i’m actually getting is:

tstories/[node:title]

I tested by assigning an existing node to a group, then re-saving the node.
It is quite possible that the issue here is that the node is first created than assigned to the group. So the alias does not have the group context, hence the simple title.

OG solves this by having an ER field directly on the node, rather than having the extra step in the node form.

@kristiaanvandeneynde very good point re multiple parents. What should the default be? For example Node A belongs to Group 1 and Group 2, while the token is [node:group:title]/[node:title].
It is also worth noting to that from what I could find, array support only comes with the Token module, so that will need to at least come as a soft dependency.

The node is indeed saved first so the interstitial GroupContent entity can have both a node and group ID to refer to. I don't see any reason why we couldn't do something like this, though:

$node->save();
// Grab the NID
$group_content->save();

// We save the node again because blah blah...
$node->save();

@kristiaanvandeneynde very good point re multiple parents. What should the default be? For example Node A belongs to Group 1 and Group 2, while the token is [node:group:title]/[node:title].
It is also worth noting to that from what I could find, array support only comes with the Token module, so that will need to at least come as a soft dependency.

I would default to delta 0 for any non-specific token use. E.g. [node:group] returns the first group affiliation it can find. We'd need to make sure the list is consistent, though. Like, sort it by GroupContent ID so new group affiliations are appended to the list instead of inserted in there at random.

You're right about the Token module: If that is what enables list tokens, we'd need to support both scenarios (with/without Token).

Here is another patch that has a soft dependency on Token.

It has two modes, the old `[node:group]` which provides full access to the delta 0 group attributes. Plus `[node:groups]` which will concatenate all parent groups. To access a particular group label `[node:groups:value:N]` (also `[node:groups:first]`, `[node:groups:last]`)

I see we can do $node->save() in GroupNodeFormStep2::save(), but it just does not feel right.
There must be a way to update the path alias without saving the node (e.g. using PathautoGenerator to get the new alias and then \Drupal::service('path.alias_storage')->save($entity->urlInfo()->getInternalPat‌​h(), $your_alias, $entity->language()->getId())

There must be a way to update the path alias without saving the node

Completely agree

Here is updated patch that will trigger the path alias generation after GroupContent has saved.

Having a pathauto pattern of stories/[node:group]/[node:title] deleting and recreating paths does not currently lead to path aliases being created - they just come out as node/nnnn for me.

aha! interestingly, stories/[node:group:title]/[node:title] DOES work - which does make sense and probably what I should have chosen. Still, it does show that [node:group] probably should not even be in the list?

The patch works well. However, when a node is edited there is an error

That relates to this block:

  /** @var \Drupal\group\Entity\GroupContentInterface $group_content */
  $group_content = array_pop($group_content_array);
  $group = $group_content->getGroup();
  $replacements[$tokens['group']] = $group->label();

There is no check whether there is a group key in $tokens.

Having looked into this patch, it seems to be a really nice addition but I have a few remarks:

• We're using token_render_array but that function says
  

  Do not use this function yet. Its API has not been finalized.

• I would drop the 'groups' token and make the 'group' token the multiple one. We can state that Group requires Token in order to function properly. Having 2 tokens that could do the same thing is just confusing.
• We're specifying something in gnode.tokens.inc that could be generalized in group.tokens.inc

For the latter point: We could check for installed plugins in group_token_info(), figure out what entity types they are serving and then set the parent groups token for all of those entity types.

Hoe does that sound?

As for the recalculating the path alias: That part can be removed from the patch again. Turns out we have a lot of issues that require the grouped entity to be re-saved when (un)grouped. See the patch in #2753629-4: Invalidate a node's cache tag when added/removed to/from a group.

I still need to deal with the removal of the token_render_array function but this should at least move it on a little bit. It seems it is only an addition of the gnode.tokens.inc file now.

Oh - I need to get a few things out into a generic group.tokens.inc, too.

arrrgh - this is wrong. It is no longer producing results. I though it was hence the upload.

Right - let me add back in the group token for the time being, as it was, but lose the need to specially rebuild url aliases and get rid of that error above in #16.

The question I need to answer next, is why can I do [node:group:label][node:title] but not do the same thing with groups taken? How exactly should I write it?

I'm also think we should have a [node:group:path] token, that provides the aliased path to the group (rather than the full url), seeing as the most likely use of the [node:group:***] operation is to get a path for the group.

Here's an addition to #22 that makes the URL chained so that we can do [node:group:url:path].

Under the available tokens there is [group_content:gid:entity:title] isn't that what you are looking for?

Or is this issue about adding tokens to "regular" nodes which are not declared as "group content"?

Tested the latest failing patch #26 - works fine for me!
Thanks.

There exists a module that creates post save events... it may be of use... https://www.drupal.org/project/hook_post_action

I am not sure whether this should be here:

Creating a node using https://www.drupal.org/project/auto_entitylabel

[node:group:id] [node:group:label]

Causes 2 errors:

Drupal\Core\Database\InvalidQueryException: Query condition 'group_content_field_data.entity_id IN ()' cannot be empty. in Drupal\Core\Database\Query\Condition->condition() (line 71 of /../core/lib/Drupal/Core/Database/Query/Condition.php).

Drupal\Core\Entity\EntityStorageException: Query condition 'group_content_field_data.entity_id IN ()' cannot be empty. in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 770 of /../core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

(I also reported this here https://www.drupal.org/node/2778111#comment-12021888, because I do not know what the cause may be.)

Re #30: Please don't post the same error in two separate issues. If unsure, post it in one and link to it from the other.

[node:group] is unsupported in Group 8, it's what this issue is trying to add. So your setup would obviously fail unless you applied a working patch from this issue.

Ok. I will post in the other then.

+  $group_content_array = GroupContent::loadByEntity($data['node']);
+  if (empty($group_content_array)) {
+    return [];
+  }

This does not check whether the node has been saved before, potentially causing a crash in the group content storage handler. See stack trace in this comment. I might fix that in the storage handler.

Related issue #2916907: Group content tokens for label and referenced entity

What's the status of this issue?

I tried patch in #24 and works very well.

Updating #24 to address #33

Tested this as well in our project and it works. I think performance is a bit a problem, because now it *always* loads the group content, even if there are not actually any tokens that need it. It will result in some duplicated content due to the groups/group thing, but I would suggest to move loading of the group inside the if statements about actually calling out to process the nested tokens.

Also, tests for this would be good, I'll see if we can do something about that.

Setting to needs review so that testbot runs against #37.

Ah, this seems to be actually failing on existing tests, so it should not be too hard to extend that with a node and generating the group tokens through that?

One more thing. Right now, the groups token is type array, which means you only get a bunch of generic array token suggestions in the UI. Array kind of means a list of strings, you can't do something like node:groups:first:name or so, as token isn't generic enough to be able to know what is in the array and pass it along correctly.

One option would be to do it like token.module does for multi-cardinality field tokens, where it defines a custom token type for each field type in field_token_info_alter(), and then define that as as something that has an index and each element is again token type group.

Or if we don't have a use case for that, we could just drop it for now?

The translations of the parent group aren't being picked up. The language of the parent should match the language of the child, no?

This is 36 applied against RC2 with the loading of the parent group translation added. In my testing this appears to solve the problem of generating path aliases in the appropriate language when both the parent and the child have translations.

Wrapped getTranslation() in hasTranslation() to avoid WSOD.

Patch on #40 was working with pathauto-8.x-1.2 and Drupal 8.6.3, upgrade core to 8.6.5 and pathauto-8.x-1.3

We got the following error, which was fixed by the patch identified in this Pathauto issue https://www.drupal.org/project/pathauto/issues/3003373

Error: Call to undefined method Drupal\pathauto\VerboseMessenger::addError() in Drupal\pathauto\PathautoGenerator->updateEntityAlias() (line 352 of /modules/pathauto/src/PathautoGenerator.php) #0

I don't get the error as described above and locally i'm running core 8.6.7 and pathauto 8.x-1.3 so patch is working quite well for me.

Did wrote some additional code that updates the aliases of the content under a group when the main group alias has changed.

What is the latest on this?

I am using the latest dev version of Group. Drupal core 8.7.0 and Pathauto 8.x-1.4

So far I am having no success with the any of the group content tokens, nor with this patch or anything else. It feels like I didn't get sent the memo :-)

@MrPaulDriver the patch from #41 works for me with Drupal 8.7.0, Group 8.x-1.0-rc2, and Pathauto 8.x-1.4

@wiilabby please can you say which tokens you are using?

I was not getting anywhere with generating URL alias patterns. After selecting what seemed like the correct tokens nothing would happen when updating aliases.

It turned out that was selecting Group Content for the pattern type when I should have been choosing Content instead. Silly me.

Is there a logical reason for why Group Content was the wrong pattern type for group content?

Drupal 8.7, Pathauto 8.x-1.4.

I applied the patch 41 and am able to create tokens for valid routes. However, the address bar results are not what i was expecting.

Given URL alias = /[node:group:title]/[node:title]

expected: 'mysite/groupTitle/nodeTitle'
observed: 'mysite//%5Bnode%3Agroup%3Atitle%5D/%5Bnode%3Atitle%5D'

Did I do something wrong? If the observed value is correct for this patch, is anyone aware of a patch that will give me the expected results?

I was able to apply the #41 patch via composer. Just apply it and clear all Drupal cache. It starts working immediately.

I am currently running Groups version "1.0.0-rc3", Pathauto version "1.4.0", and Drupal version "8.7.2". I would love to see this merged into code.

@bubbaF377: Here are some examples as to what I used on a project. Bear in mind that the order of the patterns relative to your other patterns can cause it to skip the pattern you want.

For Articles in a group:
/[node:group:title]/news/[node:title]

Right after that I have this for articles not in a group:
/news/[node:title]

Clients in a group:
/[node:group:title]/clients/[node:title]

Clients not in group:
/clients/[node:title]

Added a relationship to #2813405. That patch includes a [node:groups] token that could use some of the thinking from this patch.

One key issue is that a content entity can have multiple group content entities that relate it to multiple groups. So there really needs to be some notion of weight to the group content entities so that they can be compared to each other on a given content entity.

Maybe a set of tokens like:

[node:groups:0:title]
[node:groups:0:url.path]
[node:groups:1:title]
[node:groups:1:url.path]

This would make it possible to target a "primary" group as well as additional groups for things like news content that needed to get its primary group's path alias but still have relationships to other groups for appearing in the news lists for those groups.

I was able to apply the #41 patch via composer. Applied it and clear all Drupal cache. It worked right away. Thank you!

I am currently running Groups version "1.0-rc4", Pathauto version "1.4", and Drupal version "8.7.6". I too would love to see this merged into code.

So I am not sure why this wouldn't be merged in at this point. People are having success with it.

Thoughts? It has been 3 months and the needle hasn't moved.

So I am not sure why this wouldn't be merged in at this point. People are having success with it.

Thoughts? It has been 3 months and the needle hasn't moved.

A massive backlog due to me being the only active maintainer, having limited resources and having bigger fish to fry over the last few months. I'll try to go over all outstanding feature/support requests when I finally have the time to tag a full release.

I applied patch #41 and had no results. Patch #7 from #2916907 did solve this issue for me (however, I think the implementation might need some work.)

Patch in #40 worked for me.

Edited composer.json to add this to the extras section:

        "patches": {
            "drupal/group": {
                "Get token of node's parent group; https://www.drupal.org/project/group/issues/2774827 #40": "https://www.drupal.org/files/issues/2018-10-29/group_add-node-group-tokens-2774827-40.patch"
            }
        }

Then ran composer update.

Went to pathauto patterns (/admin/config/search/path/patterns), clicked Add pattern, selected "Content" for pattern type, specified the applicable content type. [node:group] was now available in tokens.

Added a lookup for the group from the group route context to fix missing node:group tokens when creating a new entity and fixed the coding standards warnings.

Fixing test. Still need test adding for node:group tokens.

Thank you very much! I can confirm patch #62 works nicely.

Thanks for the patch. Token [node:group:title] working for me via patch #62.

Tested. it works

With recent changes, #62 seems to no longer be functioning in composer. This might be merely because of line number changes. Anyone else having issues?

Sometimes a composer install after a "failed" patch will do it. I think it gets confused.

Thanks much @KarlShea. Composer was indeed confused, but eventually got it working.

Thank you. Patch #62 works fine with Group module 1.2 version and composer.

Patch #62 does not work. This is becoming quite a frustrating issue for me with this group module and we've committed to using this on a very large project that could really utilize pathauto.

Adding rerolled patch, this applies to 8.x-1.3 and (current) 8.x-1.x branch.

Another question is whether this is a valuable reroll; I have not tested it yet myself.

After clicking through a few pages of a site running group, I've discovered a call to a deprecated function - Group::urlInfo(). This is inherited via EntityInterface, and needs to be replaced by Group::toUrl(). I'm a little confused by how small this patch is now, but the patch from #62 applies cleanly to 8.x-1.3 tag, but with much fewer changes resulting. I will test the results, but I have confirmed that this method rename works if you're trying to update to D9.

Both #71 and #72 are missing the new file that was in the previous patches and are incomplete.

Also, it would make sense to keep the url case in the current position and just fix the cacheability metadata thing (and do that for edit-url too).

Sorry, the missing new file was my bad. Here's #72 with the new tokens.inc included. No other changes.

#74 Work for me.

• Drupal 8.9.9
• Group 8.x-1.3
• Pathauto 8.x-1.8

Thanks!

Attached is the edited patch to fix an issue on revisions display, where the $data['node'] can be the id of the node instead of the Node entity.

+++ b/modules/gnode/gnode.tokens.inc
@@ -0,0 +1,114 @@
+
+  if (is_numeric($data['node'])) {
+    $data['node'] = Node::load($data['node']);
+  }
+
+  if (!$data['node']->id()) {

You should include an interdiff when existing patches.

And this change should not be necessary, node must be a node object, not an ID. It is the responsibility of the code calling token replace to ensure it is passing node objects in. See #2730631: Upcast node and node_revision parameters of node revision routes, my comment #150 and others from me that explain that.

#74 Work for me.

Drupal 8.9.15
Group 8.x-1.3
Pathauto 8.x-1.8

#77 works fine with me

Has there been any progress with making this patch compatible with Group 8.x-1.4? I did not see any commits of this to @dev or 1.4. I'm still unable to get Pathauto to fire when creating group content nodes.

#77 works for me. Just what I needed! Thanks for everyone's efforts

Drupal   9.2.4
Group    8.x-1.4
Pathauto 8.x-1.8

Just a flag that I ran into a performance issue with this patch. Admittedly, it's probably a bit of an edge case.

On my site:
- A single node can be associated with many groups
- There are a lot of fields on groups, so loading is relatively expensive

The performance issue came up where, on any node token replace gnode_tokens is loading all of the group_content's for the node and all the groups, even if the token being replaced doesn't even use groups or group.

It turns out that I don't really need the functionality in this patch anymore, so just flagging here for now, but I would recommend adding checks for which token types are being replaced before doing the work of loading the groups.

Hi,

It's would be very nice to finish this.

Someone can?

what about for media? can the same thing be done to get the title of the medias parent group? i see there is an issue for this .https://www.drupal.org/project/groupmedia/issues/3008087

#77 works fine. thank you.

Drupal 9.4.5
Group 8.x-1.5
Pathauto 8.x-1.11

Changed $group->urlInfo() to $group->toUrl() in group.tokens.inc

Re-rolled patch #89 for the 3.0.x-dev version

Re-rolled patch from #90 to work with 2.0.x

I'm experiencing an issue with this. After applying the patch in #90, I create new content in a group and it seems the tokens in [node:group:*] are empty just when the content is created. If I try to recreate the path aliases, then it works. Not sure if the issue is caused for some misconfiguration but I'm still investigating.

Sharing this if someone else experienced the same or not.

I solved the issue in #95 forcing the path alias to be created in `hook_entity_presave` only for newly created entities. I'll test if this is just an issue in my environment or if I can reproduce it in the latest versions of Drupal and the contrib modules. In the meantime I'll leave the code below if someone experiences the same issue:

if ($entity->isNew()) {
      $entity->path = \Drupal::service('pathauto.generator')->updateEntityAlias($entity, 'insert');
}

#90 working on 3.x

I assume from the comments and patches this applies up to 3.x, so updating the version for visibility.

I've tested the patch from #90 on a few sites now and it seems to work really well.

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)

Created MRs for both 3.x and 2.x from the latest patches.

Applied the patch for the 2.x branch and it works well. Not moving to RTBC since I did not try the 3x branch.

pls note that for group v3.x in the subject patch the GroupContent is replaced with GroupRelationship

This patch looks exactly like what I need, but I'm new to the group module, and I'm not understanding how this patch works. I've patched the group module (3.x) with the diff from the MR and it applies cleanly, but I'm still not seeing any group tokens when I select Content as the pattern type in pathauto.

Can someone please explain it to me like I'm a 1st grader? :)

You should be able to use [node:group] tokens. I'm still using Group 2.x (MR 157), if you're on 3.x (MR 156) the MR might be wrong, but I haven't been able to test it.

Karlshea, I must be missing something. I'm running version 3.2.2, the patch from MR 156 applied cleanly, and I also have group_content_menu v3.0.3 and group_context_path_prefix v1.1.2 installed. When I go into the Pathauto configuration and select content for the pattern type, I don't have a [node:group] token in the list of available tokens. Selecting group or group relationship, there are no node tokens in the list of available tokens. What am I missing? Is there a configuration option I'm not setting?

Is node one of the available types of content in one of your groups? Tried clearing caches? Otherwise you might have to debug yourself or wait for someone running Group 3.x to chime in, I'm not sure.

I found the issue -- I don't know if this was part of it, but disabled group_contenxt_path_prefix and then enabled it again. It also looks like I was hitting the pathauto configuration page inside of the group. Once I did it at the top level, I had the token available. I had to delete an existing pattern for article and basic page, and now it's working how I expect it to. Thanks for the help!

This is exactly what I was looking for. After applying the changes in MR!156 I was able to use a node token that references the parent group. Thanks to everyone whose work made this possible!

Like @mandclu, I've tested the MR!156 in Group 3 and it works! Though I only tested it on content that belongs to one group. Next up: to see if I can create a path based on a Group Content Menu...

updating my attribution

and trying again - it’s persistent today ;-)

MR 156 is working for me as well. Any idea when this might be merged in?

I’m going to assume you didn’t mean to change the status, Dave.weiner?

I am trying to patch this to the latest version (3.3.4). I now get:

Error: Class "Drupal\group\Entity\GroupContent" not found in gnode_tokens() (line 59 of /home/myuser/domains/mydomain/public_html/web/modules/contrib/group/modules/gnode/gnode.tokens.inc).

Edit: my bad. Patched a 3.x version with the #41 which was displayed at the top and not the #93 in the comments.

Hiding the patches files as the current approach is to use MRs. There are 2 MRs that seem to solve the issue and patch from #41 looks the same as MR157.

I've tested MR156 and that provided the tokens I was looking for.

But it seems no pipelines are running? I'll rebase and see if that triggers the pipeline.

I rebased both MRs but for the 2.x I rebased on the 2.3.x so that MR needs to be changed to 2.3.x instead of 2.2.x. I'm not able to do this, anyone else have this option?

Also with the pipelines running now, there is more work to do.

@tim-diels : Due recent changes "https://git.drupalcode.org/project/group/-/merge_requests/157.patch is started to getting failed on our installed group module 2.3.1.

@dhaval_panara please do not use mr diff links in your workflow. This is very dangerous! Please read https://github.com/cweagans/composer-patches/issues/347

I've created a new MR which isolates the changes from the 2.2.x branch for the 2.3.x branch.

Since MR pathces are dangerous as mentioned, is the recommended way for now to create a patch on DO based on an existing MR?

Adding a patch for 2.3.1 MR 232

Rebased against 3.3.x, after commit `aa30540` that refactors how tokens are implement with the cool modern way!
Patch supersedes earlier patches/MRs that contained unrelated scope. This implementation is intentionally minimal and focused only on exposing a node's parent group as a token. Kernel tests included.

This patch builds on the patch from #128, and handles ungrouped nodes and allows test `NodeGroupTokenReplaceTest` to pass.

Should we organize a celebration for this issue's 10th birthday? It's coming up soon!