[solved] PW Update from 3.0.165 to 3.0.229 has changed the way Multi-language URLs work.

[iank]

Hi,  I have a site that uses Multi-language URLs and Multi-language Page names to present different language content for the same page, using a language specific URL.

After upgrading PW to version 3.0.229, the language-specific field data is only displayed if the home page has the language name (segment) specified and marked as active.    Prior to this ( version 3.0.165, I'm not sure at which version this changed), it wasn't necessary to set the home page language name and make it active. 

Instead, I could just create a specific name for a page beneath the home page (e.g. /test/ for the default language, and /test-fr/ for French), and mark that language as active just for that page, and it would work, displaying the language specific content for that page.  

The problem I have is that not all pages are translated - in fact there are just a few - and these might have different combinations of language-specific content.  One page might have default (English), French and Spanish content,  another page using the same template might have default (English), German and Dutch, for example.

Hence I don't want the whole site to have a language prefix at the root for every language - just to have language-specific names for those (few) pages that are affected.

Until now, this has worked fine, but since upgrading the site to 3.0.229, only the default (English) language content is being shown for those pages, even when accessed via their language-specific URL.   Essentially the detection of the language from the page name is now fully dependent on the home page having that language active (and hence a segment prefix) whereas before it wasn't.

Can anybody suggest a way around this?  

If I replace the core LanguageSupportPageNames module with the version from 3.0.165 then the previous behaviour is restored, but obviously that's not a very robust solution.

Thanks.
Ian.

 

[ryan]

@iank I had a look at this and it seems like it can happen if you omit homepage language segments, and are also using the PagePathHistory module. What happens is that PagePathHistory provides a shortcut for finding the page, leaving no language segments for PagePathHistory to detect the language. I don't think PagePathHistory supported multi-language URLs until 3.0.186, so maybe that's when the issue started. Though the entire URL-to-page mapping system has been rewritten since 3.0.165 via the new PagesPathFinder class, so who knows. I think maybe it's not been reported before because just about everyone is using language segments on the homepage, and I always recommend doing so, but didn't intend to require it. I've attempted a fix on the dev branch, it's just one line of code, so maybe it'll work just to modify your copy too. Do you find this fixes it there? 

https://github.com/processwire/processwire/commit/9e6b89cf9331fccb8f41ae0b1785e21c8c5d62f0

[iank]

@ryan - thanks for the quick response!  That worked perfectly. ?  I'll mark this as solved.

Much appreciated,

Ian.

P.S. For anyone interested, here's the site and the specific page that the client noticed had the issue - content in 4 languages (English, French, German, Dutch) all now rendering as expected:  https://www.traffic.org/unite-fr/