Problem/Motivation

The language-country-url negotiation method excludes admin pages from outbound URL processing. This effectively makes it impossible to make use of country information on admin interfaces.

Proposed resolution

Add configuration, probably to the Language-country fallbacks form to enable/disable support on admin pages.

Issue fork language_country_negotiation-3486457

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

jamsilver created an issue. See original summary.

jamsilver opened merge request !10

jamsilver’s picture

jamsilver commented
Status: Active » Needs review
simonbaese’s picture

simonbaese
Location Berlin
commented

Hello James, thanks for the proposed changes. I was holding back on this because I haven't looked into the effects to the dynamic page cache. The concern is that we produce significantly more cache variations because of the country prefix. Do you have thoughts on that?

jamsilver’s picture

jamsilver commented

Hi Simon. A random assortment of thoughts:

If LCN is enabled, does it need to introduce a cache variation for each country?
With how it currently works: Yes. This is how the language negotiator works. Users are kept "inside" their selected language/country as they navigate around the site by maintaining a URL prefix on every link. This means every link on the page has the current country in it. URLs, links, the blocks that contain them, and all pages really do vary by country.
Why would a site builder enable Current Country Support [on admin pages]?
In general LCN module doesn't (and can't) know the answer to this question, but (ignoring URL prefixing) it seems likely only a few admin pages would "actually" vary by current country. (In my use-case, only /admin/content varies by current country).
We produce significantly more cache variations because of the country prefix
Yes. But isn't this what we want / is this really so bad? If every language-country permutation were instead defined as a core language (which seems to me the major alternative to using LCN) then there would likewise be a cache variation for each one
Not sure this is an admin-pages-only concern
(Not my use-case but..) presumably this concern about the DPC applies for sites that have authenticated traffic to front-end pages?
"Exclude admin pages" defaults to true
I think we have to assume if a Site Builder is setting this to false, they are making this choice because they "really do want" to enable Current Country support on admin pages with all that that entails. If DPC were a concern for me, I simply wouldn't activate LCN on admin pages and would build some other way to switch country in the admin UI, something that doesn't appear in every URL and doesn't force as many cache variations.
The name of language_country_negotiator module seems tied to the idea of it being a language negotiator
I don't think I would expect it to provide non "language negotiator" techniques for switching the current country. It seems enough that LCN exposes the current_country service so I can get/set it in custom ways if I wish

My overall feeling is LCN is a fairly low-level module and working with the Dynamic Page Cache typically requires advanced tuning of configuration, customisations etc. It's an advanced use case and it's not clear to me what more LCN could do to support it.

Could add something to the Project Page/README about it though.

  • simonbaese committed d64490c1 on 1.0.x authored by jamsilver 
    Issue #3486457 by jamsilver, simonbaese: Allow configuration option to...
simonbaese’s picture

simonbaese
Location Berlin
commented
Status: Needs review » Fixed

@jamsilver Thank you very much for the detailed comments.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.