Bug #86616
closed
Content of 404 page is not shown
0%
Description
I have multiple languages configured as single-tree. Now I created a 404 page in the page tree and referenced it in the Site Management module. I expected to see the content of the 404 page also with the status code 404 Not Found.
But I encountered the following issues:
- Calling /should-not-be-found: I got a redirect to the URL of the default language (/en)
- Calling /should-not-be-found/level2: The same
- Calling /en/should-not-be-found: The status code is a 404 Not Found, but the content of the page is empty, the content-length header is set to 0. (it was fixed already in an update, in 9.5.4 this case works correctly)
My site configuration (config.yaml):
rootPageId: 3
base: 'https://www.example.net/'
baseVariants:
-
base: 'http://example.ddev.local:8080/'
condition: 'applicationContext == "Development"'
-
base: 'https://staging.example.net/'
condition: 'applicationContext == "Production/Staging"'
-
base: 'http://testing.example.net/'
condition: 'applicationContext == "Testing"'
languages:
-
title: English
enabled: true
languageId: '0'
base: /en
typo3Language: default
locale: en_US.utf8
iso-639-1: en
navigationTitle: English
hreflang: en
flag: us
-
title: Deutsch
enabled: true
languageId: '1'
base: /de
typo3Language: de
locale: de_DE.utf-8
iso-639-1: de
navigationTitle: Deutsch
hreflang: de
fallbackType: strict
flag: de
errorHandling:
-
errorCode: '404'
errorHandler: Page
errorContentSource: 't3://page?uid=96'
routes:
-
route: sitemap.xml
type: uri
source: 't3://page?uid=3&type=1533906435'
The page 96 is set as visible, also both translations. I encounter this problem on my local ddev container (nginx), also on a webserver with Apache.
Updated by
Updated by Martin Reimund about 6 years ago
- Related to Bug #86260: Site error handling: Show content from page with / entry point added
Updated by Martin Reimund about 6 years ago
- Related to deleted (Bug #86260: Site error handling: Show content from page with / entry point)
Updated by Martin Reimund about 6 years ago
- Is duplicate of Bug #86260: Site error handling: Show content from page with / entry point added
Updated by Georg Ringer about 6 years ago
- Category set to Site Handling, Site Sets & Routing
- Status changed from New to Accepted
Updated by Georg Ringer about 6 years ago
- Related to Bug #86615: Static route sitemap.xml is not working on single-page tree added
Updated by Christian Kuhn almost 6 years ago
- Status changed from Accepted to Needs Feedback
Summary of your setup:
1) Your default language slug is /en (NOT /)
2) You have one further language ( /de )
a) Calling /should-not-be-found: I got a redirect to the URL of the deafult language (/en) b) Calling /should-not-be-found/level2: The same c) Calling /en/should-not-be-found: The status code is a 404 Not Found, *but the content of the page is empty*, the content-length header is set to 0.
Imho, a) and b) are correct and make sense: You call a page without any language prefix (/foo), so you are redirected to default language (/en). If you want to avoid that, change your default language setup from /en to /. If then /foo is called, content of the english 404 page is rendered for /foo.
c): You call /en/foo and get no 404 page content elements rendered. I am unable to reproduce this: My 404 page has a couple of content elements in default language, if I call /en/foo, this content is rendered. Could you please try to reproduce this on your side with current 9.5 head core branch? Maybe this has been fixed meanwhile?
Addon to c): My 404 page is localized (de translated 404 page exists and content elements are translated). If I then call /de/foo (non existing page foo in german), I do get the german 404 page content elemnets rendered. This is ok, too.
Result: a) and b) are imho as they should be, c) seems to be fixed. Do you agree?
Updated by Chris Müller almost 6 years ago
Respective a) and b):
I have to disagree. Image the following scenario: You made a relaunch with a new site structure, all pages, that are not need anymore, should show a 404 (like old news and such stuff). Instead they are redirected with 307 to the home page. If a user comes from a search engine, he is confused because he doesn't see the correct content. Search engines are confused, because they "think" the content of the original page should be left indexed. But, search engines should throw the indexed page out of the index (the content isn't available anymore). So you might insist, okay, we are making a 301 permanent redirect. So the original page is unlisted by search engines. But this is discouraged by Google [1].
Also, if a user clicks on the (original) link in a search engine, then he sees the home page, not the desired content, and leaves. I have a short click (hurray) and if this happens more the once, this is a signal to Google to rank this page down (it is not relevant, oh wonder).
Another scenario: Someone links to our page. Then the editor of the other website doesn't get noticed, that the original page doesn't exist anymore, because a 307 is okay for the link checker.
As a side effect: I don't see the "wrong" URLs in Google Search Console (it is not a 404), so I cannot make a manual permanent redirect to the correct page (if I missed it before to do that).
So TYPO3 makes an assumption (all URL not defined by a language prefix have to be temporary redirected to the home page of the default language) which is no good.
Respective c):
This bug was fixed in a 9.5 update, in 9.5.4 everything is fine. I updated the description.
[1] https://www.seroundtable.com/google-redirect-urls-home-26270.html
Updated by Christian Kuhn almost 6 years ago
Hey. Thanks for your feedback.
One solution in your case might be to skip the /en for your base path and use / for default language. If then /foo is called, you'll receive the 404 response with your english 404 content.
Another solution if your link layout changes, colud be to 301 old urls to new content urls (not just the homepage), for instance using the redirect module. This gives you better user experience and the ranking of your old page location is transferred to the new location.
If a domain+language like www.example.com/en is configured as default language, so base path www.example.com/foo is not configured (there are typo3 instances act on subpaths like www.example.com/bar for the domain part in default language, having www.example.com/bar/de for a translated page in this sub path), then i guess it's hard to guess what should be rendered: You expect to get the default language 404 page rendered in this case, however I'm not sure if that can be easily achieved in the router since that would require some guessing and chances are this may introduce unexpected side effects for possible sites in a sub-slug. I suppose a patch in this area would have to be carefully crafted and tested. I also guess it varies what people expect to happen in this case.
Updated by Riccardo De Contardi over 5 years ago
- Related to Bug #86935: Cannot fetch 404 page with simple base added
Updated by Susanne Moog over 4 years ago
- Status changed from Needs Feedback to Closed
As Christian stated before, for the pages with / (without the language prefix) there is no site configuration - that's also what the error message states: "no site configuration found" as you have not configured anything with only the /. Basically, the URLs your site config knows are always base+language (because you could have multiple sites with the same base but different language configurations). To achieve what you want, you could either use the redirects module (as stated before) or configure your webserver to redirect to your 404 page (in the default language) in anything other than base+lang+* is called (this might additionally make sense, if you were determining language differently on your old website). Third possibility would be to create another site config with a single language and a base of / using "show content from this page" pointing to the 404 page. Long story short: TYPO3 cannot automatically determine how to behave in these cases, as it would have to guess your wanted behaviour.