Content of 404 page is not shown
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.
#8 Updated by Christian Kuhn 14 days 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?
#9 Updated by Chris Müller 13 days 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 .
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.
This bug was fixed in a 9.5 update, in 9.5.4 everything is fine. I updated the description.
#12 Updated by Christian Kuhn 13 days 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.