U4-2508 - multilingual 404 pages in 6.1.2

Created by Mads Jørgensen 14 Jul 2013, 19:41:43 Updated by Sebastiaan Janssen 16 May 2016, 08:40:32

The good old structure 2082 2081

seems to be broken. Worked in all previous versions, and still the direct 2081 still seems to work

Comments

Stephan 15 Aug 2013, 11:46:02

Strange. The old NotFoundHandler has been replaced by the new ContentFinderByLegacy404 -- but both just do the following to determine the "not found" page ID:

var error404 = global::umbraco.library.GetCurrentNotFoundPageId(); var id = int.Parse(error404);

And the GetCurrentNotFoundPageId has not been changed to the best of my knowledge. I'll try to reproduce... are you using domains, by chance? Simple domains (site.com) or domains with paths (site.com/en)?


Douglas Robar 05 Nov 2014, 09:56:39

A longer discussion of this bug can be found at http://our.umbraco.org/forum/using/ui-questions/57859-Setting-up-error-pages-in-a-multilingual-site


Stephan 25 Apr 2016, 12:34:10

See my comments on Our. Could not really reproduce. Would need repro. instructions.


Douglas Robar 27 Apr 2016, 12:18:54

=To Reproduce=

Here are steps to reproduce the problem on 7.4.3. Using IIS and SQL CE:

  • Create a simple website with a content tree such as the following (please forgive my nonexistent Spanish language skills):

[CONTENT]

English

  • About
  • Not Found Spanish
  • El Abouto
  • El Not Foundo
  • In the Settings section of Umbraco, right-click on the Languages item and create a new language for Spanish (Spain).

  • In the Content section of Umbraco, right-click on the English page and choose the Culture and Hostname menu.

  • Choose en-US from the language dropdown list. Do not set any Domain. Save.

  • In the Content section of Umbraco, right-click on the Spanish page and choose the Culture and Hostname menu.

  • Choose es-ES from the language dropdown list. Do not set any Domain. Save.

  • In /web.config, stop hiding top level nodes in the urls:

  • In /config/umbracoSettings.config tell IIS to get out of the way for custom errors. Note that this step won't make any difference with either the true or false setting, but better to be safe and cover everything since it was mentioned on the Our forum thread:

<web.routing trySkipIisCustomErrors="true" internalRedirectPreservesTemplate="false" disableAlternativeTemplates="false" disableFindContentByIdPath="false" umbracoApplicationUrl=""> </web.routing>

  • In /config/umbracoSettings.config, set the global not found handler to the ID of the 'Not Found' page:

1167

It works

At this point you will get the correct English Not Found page when requesting any of these nonexistent URLs:

localhost/foo localhost/english/foo localhost/spanish/foo

This is the correct behavior with the <error404>1167</error404> entry.

Let's break it

To create multilingual 404 pages for each language in our site we need to change the error settings, giving IDs for both the English and Spanish not found pages.

  • In /config/umbracoSettings.config, set the global not found handler to the ID of the 'Not Found' page:

1 1167 1168

Again test the URLs:

localhost/foo localhost/english/foo localhost/spanish/foo

What happened

We continue to see the English non-found page (ID = 1167 in this example) for all bogus urls.

What should have happened

At least the last url should have displayed the Spanish 'El Not Foundo' page, but it didn't.


Stephan 27 Apr 2016, 16:34:21

Aha. Unfortunately, that is not how it works at the moment.

In order to pick the proper errorPage entry we need a culture. By default, the culture is the server's culture, so most probably in your case it is English. How do we get a different culture, then?

*If we have a matching ''domain'' (eg example.com) then it sets the culture. *Once we have found a node, we walk up the tree to look for ''language'' domains.

If your case we don't have a matching domain, only ''language'' domains, but we don't find a node in the first place, so we have no idea what to look for. So the culture remains English. So I would say... what you describe is the expected (technically, if not logically) behavior.

What's missing at the moment is... if localhost/spanish/path/to/foo fails, look for localhost/spanish/path/to then localhost/spanish/path then... you get my point, until we ''do'' find a node, and then starting from that node, walk up the tree to look for ''language'' domains.

In other words, at the moment we don't have any partial, or approximate, logic to find the matching part of the path. It is all or nothing. And so I guess the question is... can we implement it? Need to think about it.


Stephan 27 Apr 2016, 17:10:49

PR https://github.com/umbraco/Umbraco-CMS/pull/1246

Test/review: try to reproduce Doug's scenario. Now it should pick the proper culture.


Aleksey Gerasimov 05 May 2016, 08:37:31

@claus How soon do you plan to release an update with @zpqrtbnk fix for Umbraco 7?


Priority: Normal

Type: Bug

State: Fixed

Assignee:

Difficulty: Normal

Category: Localization

Backwards Compatible: True

Fix Submitted:

Affected versions: 6.1.2, 7.1.8, 7.4.3

Due in version: 7.5.0

Sprint: Sprint 14

Story Points:

Cycle: