Product url updates on variation change may product wrong urls

Created on 12 August 2024, 4 months ago

Some time ago, Update product URL to include the selected variation ID Fixed introduced that the browser url gets changed upon a different variation is selected on the product page, so that eg. /product/123?v=12345 gets changed to /product/123?v=12346

We have now discovered on a client shop, that this does not work there anymore as expected, as semi-colons get added to the changed url, like /product/123;?v=12346;, resulting in an invalid url

Two interesting things about this:

  • We could not reproduce this neither on local dev env nor on another Commerce site of us
  • On the concerning website, this definitely worked as expected in the past - it was only unsure, since when it stopped working

A comment of myself in #3192519-16: Update product URL to include the selected variation ID reminded me, that we already encountered that problem in the past. For whatever reason, using an ordinary string concatenation, which CS checking tools will complain about, solved the problem for me in that past already. Commit https://git.drupalcode.org/project/commerce/-/commit/9c63b13db6d9fba6605... did some CS fixes and re-introduced the notation using backticks and template literals. When I revert the changed line back to the string concatenation. I do not have any idea, why this is the case, but it is so :)

The concerning website is running on Nginx 1.18.0 on Debian

🐛 Bug report
Status

Active

Version

2.0

Component

Product

Created by

🇦🇹Austria agoradesign

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @agoradesign
  • 🇮🇱Israel jsacksick

    Never experienced this... Code looks straightforward... As you can see there is no code prepending/appending ";". Is there any other JS code potentially messing with the window location? I think the previous code was reported by eslint which is why it got refactored.

  • 🇦🇹Austria agoradesign

    I also have no idea, why this may happen :( As mentioned, I've already seen this on another site long time ago, when the underlying issue wasn't even committed to Commerce, but we were using that issue's patch.

    The fact, that I can only reproduce it on this specific production environment, makes it quite tricky to debug. I haven't spotted any other suspicious code that could mess things up here.

    I mainly opened this issue, in order to have this documented and if we're lucky, other people see this too, so that they either find help for themselves or even better someone knows the reason, why the other syntax makes a difference here

    For our specific project, there's no budget to invest a lot of time in investigating this problem, as our fix/workaround is patching a single line back to its original syntax

Production build 0.71.5 2024