Fix generating lingua.selector url to other language on HTTPS#67
Conversation
|
@Mark-H Would it make sense if we use the same method as in MODX's setup? https://github.com/modxcms/revolution/blob/0f45967ccabdf578b6461bb58fff503f85f41d22/setup/provisioner/bootstrap.php#L19-L20 |
|
On line 50 of the snippet, sure. Would make it work better on reverse proxy setups too. It still needs this fix to make sure the preg_replace works correctly, though. It might also make sense to re-evaluate this entire snippet as it's all very confusing to me. It seems that most of the complexity in the snippet stems from wanting to keep query parameters for the new URL, which I'd imagine can be done much simpler (and less prone to issues like this) by just using |
Line 208 of the
lingua.selectorsnippet has the followingpreg_replaceto generate the other language url:That's trying to find
$parseUrl['scheme'] . '://' . $parseUrl['host'] . '/' . $requestUriin$originPageUrl, to replace it with the (correct)$parseUrl['scheme'] . '://' . $parseUrl['host'] . '/' . $baseUrl . $itemUri.Because HTTPS is (transparently) served on port 443, the port is injected into
$pageURLhere in line 55 and therefore around line 175 into the subject of this replace,$originPageUrl.Because
$parseUrl['host']does not have the port, thepreg_replacefails and the user is given the current link with?lang=fooadded. While that works to switch the language, the user wants to see the proper localised url and not the current one.By not adding the port if it's 443, the preg_replace matches as expected and the right URL is returned.