Closed (fixed)
Project:
Drupal core
Version:
11.1.x-dev
Component:
language system
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
29 Feb 2024 at 18:30 UTC
Updated:
19 Jun 2025 at 02:32 UTC
Jump to comment: Most recent
Comments
Comment #2
douggreen commentedComment #4
xjmThanks for reporting this!
The merge request needs to be created against 11.x (our main development branch); it will be backported to supported versions once committed to 11.x. In some cases the easiest thing to do is close the previous merge request and create a new one against 11.x. Thanks!
Comment #7
immaculatexavier commentedComment #8
smustgrave commentedComment #10
vidorado commentedI've added test coverage.
As a bonus, it turns out that we've fixed, at least partially, a bug stated in #2980527: Domain-based language negotiation strips "destination" URL query argument, causing BigPipe error, so I have had to change a line in
BlockUiTesttoo.Comment #12
smustgrave commentedLeft 1 small comment on MR
If you are another contributor eager to jump in, please allow the previous poster at least 48 hours to respond to feedback first, so they have the opportunity to finish what they started!
Comment #13
vidorado commentedThanks! I've replied to your comment in the MR.
Comment #14
smustgrave commentedBeen about a month without additional review. Will RTBC but leaving the one thread open.
Comment #16
uri_frazierI'm not sure if this belongs here, or if there needs to be a it's own (new) issue:
I think this fix should apply to the actual domain as well, and not just the destination URL/domain.
Context:
I have a multilingual site that uses sub-domains (and domain-based language negotiation). I want admin users to be able to delete files
The "delete" link that is generated uses the English domain (e.g. website.com/file/123/delete) instead of the sub-domain (e.g. japan.website.com/file/123/delete) the user is currently logged into and clicked the original "delete" link from. So when clicking "delete", it tries to take users cross-domain to complete the process, but stops them with an "access denied" screen since they are not logged in under the English (default) domain.
This is also the same behavior/problem that occurs when trying to use the file_replace module and it's "replace" link.
Comment #20
catch@uri_frazier I think that's probably better handled in its own issue - this is already fixing the reported bug (and #2980527: Domain-based language negotiation strips "destination" URL query argument, causing BigPipe error was since closed as duplicate, so it's fixing two bug reports even if the same root cause), and it will be easier to review further changes against the new state of the code rather than changing things further here. If you could open that issue and link it back to here that would be great.
Committed/pushed to 11.x and cherry-picked to 11.1.x and 10.5.x, thanks!
Comment #22
longwaveReverted this from 10.5.x as it caused a failure in BookMultilingualTest.
Unsure if this is a problem with just the test or a problem with the patch, this wasn't spotted in 11.x because book.module has moved to contrib.
Comment #24
xjmAmending attribution.
Comment #25
xjmAnd fixing Dave's bot-eaten credit for the revert.