🇩🇪Germany @Hydra

thx!

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

Nice, looks good

Nice thx for the review!

Nice, thx!

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

Hydra → created an issue.

poker10 → credited Hydra → .

Thx!

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

Hydra → created an issue.

@slideaway Oh you need to download the patch from the merge request. Here is some documentation on how to do this: https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-dr... → And of course you need to apply the patch to your version of layout_builder_st.

Thx for doing the testing work!

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

@volker Oh thats a lot ok config changes to enable a module^^ Maybe we can make a quick pair-review to get this through the door?

I see! It would be much nicer to download the patch into your repository. drupal.org ist not a patch hosting platform for your project. You can use relative paths in your composer.json to apply patches. This is not only more performant four your project, but also reduces the traffic for the d.o. infrastructure :)

@TheodorosPloumis You can simply download the patch file from them merge request in gitlab, see https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-dr... →

Thats what I thought as well. Thanks for updating the MR :)

Thx for your contribution @j-barnes!
The patch looks like it would fix the described bug and I will commit it.

Does it make sense to show the empty Author item or should we remove it when there is no author? I did not reproduce the issue yet, but since you already had multiple use-cases, what is your opinion?

@kopeboy Yeah The view is also broken, but this does not relate to this issue here. Feel free to open a new issue for that, I could provide a working view as well.

Thx!

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

Okay now, still a documentaiton error. When using dependency injection, the documentation example does not call the parent constructor.

Instead of:

  public function __construct(array $configuration,  $plugin_id, $plugin_definition,
    protected EntityTypeManagerInterface $entityTypeManager
  ) {}

it should be:

  public function __construct(array $configuration,  $plugin_id, $plugin_definition,
    protected EntityTypeManagerInterface $entityTypeManager
  ) {
parent::__construct(array $configuration, $plugin_id, $plugin_definition);
}

nvm - that was not the issue

Hydra → created an issue.

+1, thx @raywalters for taking this over here.

Thx @j-barnes - now I get it, was on the wrong branch there... Can you check again?

Hydra → changed the visibility of the branch 3437406-moderation-meta-published to hidden.

Hey @j-barnes, thx for the repot. I see - maybe it should be enough to keep the markup value if it exists, could you test the attached solution?

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

Hey @Rajab Natshah thanks for your Report!
I already had this issue on my list but no time to fix it yet.

Maybe you could test the attached solution, it should not only fix the issue on the delete form - but every other form which might got altered by accident as well.

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

Hey thx @Takki for taking care - was about to ask for the status today :)

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

Yeah we are checking for the EntityOwnerInterface in gin_everywhere. I am willing to commit the additional check since it does not harm anything and helps addressing your issue. Feel free opening an issue on webforms issue queue for that :)

@yobottehg I could not sleep and dived a bit deeper into the problem and found out, that the webform submission is implementing the EntityOwnerInterface interface without providing an owner key on the entity type. This results in wrong from alterations from gin_everywhere. Can you have a look at my MR to check if this helps with your issue?

Thx! This looks much more reasonable to me than before. But I think it's a vaild use case to use gin as a frontend theme as well and also in combination with forms. I would prefer a way which would allow for that.

It seems to be an issue with using t() - don't know why this is not working properly.

I think what we could do is check if the request format is html, which should always be the case when altering forms but in this case... its json or xml I guess. Not sure whats the right way :/ It does not feel like the right solution yet.

  // Make sure we are on a html request.
  // @see See https://www.drupal.org/project/gin_everywhere/issues/3432341
  if (\Drupal::request()->getRequestFormat() != 'html') {
    return;
  }

Makes sense.

This looks reasonable to me.

Ok, so setting gin as a frontend theme might cause this. Will have another look into this. Thx for the research!

Hey @yobottehg,

are you sure that this is the casue? I tried it with the default contact form provided by webforms and everything worked fine with webform_rest module, see:

Have you updated to the last version? We had a performance issue in the first version which has been fixed https://www.drupal.org/project/gin_everywhere/issues/3424026 🐛 Performance with getRouteCollection / XDebug Fixed

Thx!

@e0ipso Are there plans to add those interfaces to core? I cant find any reference to this on the related issue.

Hydra → created an issue.

Great suggestion, thx! I replaced my check with Sascha's code - it works perfectly :)

I would be happy to merge if you could give it a quick review and RTBC the issue :)

Hey! Thanks for the nice feedback!

The revision information is actually there by default. Only the status tab is added by gin_everywhere. I believe that the workflow information are also added by default, but I am not sure about that since I did not test it yet.

I think it would be a good idea to check if we are in the context of the gin theme when enhancing the forms anyways. The MR should do the trick, feedback is welcome.

Hydra → changed the visibility of the branch 3426896-fix-showing-the to hidden.

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

Thank you! Wanted to say that to you anyways, thank you for all you do for the community. I owe you something to drink :)

Since there have been no reply on my mail to brynbellomy nor on this issue, I move this issue to the "Drupal.org project ownership " queue like described in the process documentation https://www.drupal.org/docs/develop/managing-a-drupalorg-theme-module-or... →

Link to the project page: https://www.drupal.org/project/sites →

This patch is not hiding anything - you should resolve this on the field widget. But I am not 100% sure if I can follow you. This issue is about making terms referencable again, not more. You might have an other issue here, but feel free to describe the exact steps to reproduce your issue, maybe someone is able to help you with that (probably even in an own issue?)

@Jatin12nov did you checkout the merge request? You can simply download a patch from there if you need one by click on the "code" link on the right top corner - its a little hidden, check out the docs: https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-dr... →

Thx!

Hey thx for the report! Right, maybe we can just drop those completely. MR is very welcome, otherwise I will fix this later, thats a very helpful hint here which I will definitely fix soon :)

Hydra → created an issue.

Just wanted to drop that here as an alternative solution to the patch https://www.drupal.org/project/gin_everywhere →

Just wanted to drop that here as an alternative solution to the patch https://www.drupal.org/project/gin_everywhere →

I had a similar issue and created https://www.drupal.org/project/group_relationship_tokens → for that, maybe this could help here.

I had a similar issue and created https://www.drupal.org/project/group_relationship_tokens → for that, maybe this could help here.

I had a similar issue and created https://www.drupal.org/project/group_relationship_tokens → for that, maybe this could help here.

Hydra → created an issue.

Seems to work with group 3.

Thx @vensires for the quick response. So I would close this issue as works as designed. I created a fix for this in https://www.drupal.org/project/group_term/issues/3417876 🐛 References are broken Active

Removed the query access in the MR. This should re-add the functionality and solve the issue from https://www.drupal.org/project/group/issues/3398778 🐛 Unknown column group_relationship_field_data.tid in 'on clause Needs review

@dalin It looks to me that calling group_query_entity_query_alter in group_term_query_taxonomy_term_access_alter is the root of this problem. This has been introduced in https://www.drupal.org/project/group_term/issues/3367570 ✨ Add Group Ids to the Taxonomy Terms Fixed in order to solve some kind of permission issue when using entity_reference fields. They will give you access on all entities you have view access to, which might also be entities not part of the group. I believe this is the wrong attempt of solving this problem.

I created an issue in group_term in order to revert this change: https://www.drupal.org/project/group_term/issues/3417876 🐛 References are broken Active

Not sure how to proceed with this issue. I don't believe that this has something to do with the group implementation since the issue is caused by group_term so I would suggest closing this as won't fix - but I only tested it with the Term usecase.

The original creator reported that this happens with every view showing other entity types, so I'd like to verify if this was just a guess or another usecase we need to take in consideration first. @vensires

Hydra → created an issue.

@geek-merlin - it's a while ago I faced this issue. But as far as I can remember (and my git history tells me) we had a local task (tab) added to the group tasks which pointed to a page_manager page route. That page of course has the group context configured and used a custom condition plugin to determine the access. That condition used the group context to check for some information related to the group in order to grant or deny access. In combination with this patch, this resulted in an error on the local task access check level - kinda related to what berdir described what could happen to menu links in #5
Removing the patch and adding the event subscriber with the provided code in #20 solved that for us and solved the original issue we used the patch for in the first place.

It surly is. Haven't seen this since the D10 upgrade of the project I used this for is still tbd. So yeah thx Anybody, lets focus on the other issue. The patch works as a workaround and needs to be upgraded to the other issue anyways. So lets close this.

allright!

Nah this needs to be at least a 2.0.x or even better 3.0.x to match the related group version. This would be much clearer I think (other modules in the group eco system are also following this pattern).
If this get's merged into 1.0.x it will break compatibility with Group1 version which is still supported by the group maintainers.

A co-worker of mine will make a review of this MR soon this week and fix issues if necessary. Since we need this for a current project we can invest a little time into that and help maintaining the new branch if needed.

+1 RTBC

Still working, would be nice to see a release for that.

@graber - I don't see any other solution then making a new version without braking all group 1 version users group clone features.

I added a D9 and D10 compatible version in the MR.

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

Hey, I'd like to maintain that module because I am currently working on a project that uses a fork of this module.
I'd like to contribute my D10 version of this module and make a release, so others may use it as well.

looks good to me

I decided to add this as a MR for this module, so people can get a patch for the workaround and don't need to add the code by them self.

Took me a long road to come here. For everyone wondering where their contextual links went when using layout_builder translations with https://www.drupal.org/project/drupal/issues/2946333 📌 Allow synced Layout override Translations: translating labels and inline blocks Needs work or https://www.drupal.org/project/layout_builder_st → , the newly introduced JS in this issue removes them.

I opened an issue for that in the layout_builder_st issue queue: https://www.drupal.org/project/layout_builder_st/issues/3411037 🐛 Contextual links for translation are removed by core Active
Not sure if this is the right place either...

Just wanted to let this comment here for others who are debugging this.

Hydra → created an issue.

This is indeed a duplicate of https://www.drupal.org/project/smart_trim/issues/2901579 ✨ Allow the possibility to specify which tags to be stripped when Strip HTML checkbox is ticked. Needs review
To upgrade from this patch to the MR in 2901579

I added a second MR where I upgrade the solution to work with the non-jquery version in 2.0.x branch for everyone using this and doing an upgrade.

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

Nice, thx!