@dydave,
Thank you so much for looking into this. I agree that there are already a few warnings in place and that it is the site maintainers responsibility to check these. For many contributed modules this doesn't have a fatal impact as removing them as a whole from the codebase is also a decision often made by or in collaboration with a site maintainer.
As this is a submodule of a very popular contrib module i do feel that this is something that could be overlooked. As you mentioned the impact on the codebase is minimal and it could prevent fatal errors for lots of users.
Not sure how much response this will get as most people will only go to the issue queue once they indeed have encountered an issue. Let's see what happens.
The two can complement each other.
https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement/fetchP...
@dewancodes i can't accept my own merge request. It needs to be reviewed by the community and the module maintainer then chooses to merge this into develop.
ericmulder1980 → created an issue.
I see this is also addressed in the patch supplied in https://www.drupal.org/project/domain_language/issues/3388388 🐛 DomainLanguageOverrider::__construct(): Argument #1 ($current_user) must be of type AccountProxyInterface Active . If that patch is committed, this issue can be closed.
sometimes i wish i would have chosen another profession ..... re-uploading correct patch with changes to use statement.
Forgot that PHPStorm still isn't able to produce properly formatted patch files. Uploading new file.
Please review the attached patch.
ericmulder1980 → created an issue.
@strkaizer Ok, thanks for your response.
I am willing to put some time into this but as i don't consider myself the best php developer out there perhaps you can give me some pointers for the general direction on how to get this started?
The same thing applies to the Combine facets processor.
ericmulder1980 → created an issue.
Fixed some coding standards.
Also i have a question about the version the hook_update is targeting. Issue #3463291 📌 Deprecate the admin_toolbar_links_access_filter module Active mentions the Admin Toolbar Links Access Filter module is obsolute since the Drupal core issue has been fixed in version 10.2. Then, why do we target the update for 10.3 and above?
I created a new issue for this #15855693.
For people needing a patch file, see attached.
Please review the merge request.
ericmulder1980 → created an issue.
Agree with the above, this needs to be addressed in another way. Perhaps it's even best to put this in a seperate issue.
Postponing the update by adding an early return will cause issues with upcoming update, so not really an option. I think the best way to inform site maintainers about this issue is to add a status message to the admin/reports/status page. The context would be when the installed version of Drupal Core >= 10.3 and the modules are still active.
ericmulder1980 → created an issue.
Somehow a use statement fell off. New patch provided.
Well it took us 5 years to get to this point. I would suggest we first fix a broken system before we try to improve it. Currently the redirect Url in 3.x is based on the following logic. I really don't want to create a new issue for the 3.x branch so i changed the version of this issue.
- If you have view access to the Group Relationship Entity (which is configured in the Group type permissions : View individual group members) you are redirected to the Group relationship entity. This is very confusing for the actual visitors of a website that uses the Group module.
- If you have view access to the Entity related to the Group Relationship (which is the user that created the relationship) you will be redirected to the user page.
- If you have view access to the Group related to the Group Relationship (which you generally should have since you became a member) you will be redirected to the group page.
- If all else fails we will send you to the frontpage
So the default behaviour is that you will probably never be redirected to the group page. I can't really see a business case where you would not have the "View individual group members" permission OR where you don't have the permission to view your own user page. This logic works very well if you add a node or other entity relation to a group but not for group memberships.
We can turn this issue into a massive change with configurable redirect paths per group type but that will only further delay the solution of this issue. I think for now we need to make a special flow when we are adding a group membership relation. For all other entity types we can keep the logic as is.
Please check attached patch for the 3.x version.
Jean-Paul Vosmeer → credited ericmulder1980 → .
Jean-Paul Vosmeer → credited ericmulder1980 → .
Added merge request. Ready to be reviewed.
ericmulder1980 → created an issue.