Bug #94585
closedSiteconfig - 404 error not triggered if routeEnhancers is configured
0%
Description
Hi guys,
We encounter a bug with the handling of invalid URLs when the routeEnhancers section is configured.
In fact, https://myDomain.com/xyz shows us the home page instead of triggering a 404 error whereas using raw URLs with an invalid id argument properly works.
Did we miss something?
base: '%env(BASE_URL)%'
baseVariants: { }
errorHandling:
- errorCode: '404'
errorHandler: Page
errorContentSource: 't3://page?uid=404'
languages:
-
title: Français
enabled: true
base: /
typo3Language: fr_CA
locale: fr_CA.UTF-8
iso-639-1: fr
navigationTitle: Français
hreflang: fr-CA
direction: ltr
flag: qc
languageId: '0'
-
title: English
enabled: true
base: /en/
typo3Language: default
locale: en_CA.UTF-8
iso-639-1: en
navigationTitle: English
hreflang: en-CA
direction: ltr
fallbackType: strict
fallbacks: '1'
flag: ca
languageId: '1'
rootPageId: 1
routeEnhancers:
News:
type: Extbase
extension: News
plugin: Pi1
routes:
- routePath: '/{news-title}'
_controller: 'News::detail'
_arguments:
news-title: news
defaultController: 'News::results'
aspects:
news-title:
type: PersistedAliasMapper
tableName: tx_news_domain_model_news
routeFieldName: path_segment
routes:
- route: robots.txt
type: staticText
content: |
User-agent: *
Allow: /
Disallow: none
- route: sitemap.xml
type: uri
source: 't3://page?uid=1&type=1533906435'
Files
Updated by Cyril Janody over 3 years ago
- Subject changed from Siteconfig - 404 error handling vs routeEnhancers to Siteconfig - 404 error not triggered if routeEnhancers is configured
Updated by Cyril Janody over 3 years ago
- Target version deleted (
next-patchlevel)
Updated by Stephan Bauer over 3 years ago
Are you shure that the 'defaultController' is correct?
I think it should be "defaultController: 'News::list'"
Did you try to limit the routeEnhancer to news pages:
limitToPages: - 108 - 95
Updated by Cyril Janody over 3 years ago
Stephan Bauer wrote in #note-3:
Are you shure that the 'defaultController' is correct?
I think it should be "defaultController: 'News::list'"Did you try to limit the routeEnhancer to news pages:
[...]
Hi,
Yes, I'm sure but you're right, by default it's News::list.
Having the limitToPages configuration doesn't help.
Thanks
Updated by Stephan Bauer about 3 years ago
Does your problem still exists?
Are you shure that 'content' in 'route: robots.txt' is correct?Im my backend generated content looks like this:
content: "User-agent: *\r\nDisallow: /typo3/\r\nDisallow: /typo3_src/\r\nAllow: /typo3/sysext/frontend/Resources/Public/*\r\n"
Maybe you should generate the config.yaml from scratch.
Updated by Philipp Lüdtke about 3 years ago
I got the same problem.
Calling https://myDomain.com/xyz does not result in a 404 error. Instead the homepage is shown.
The same behaviour on all subpages. Calling https://myDomain.com/subpage/xyz just shows https://myDomain.com/subpage.
This is an example enhancer configuration which triggers this (i only have this one active to avoid interferences with other enhancers):
PowermailPlugin:
type: Extbase
extension: Powermail
plugin: Pi1
routes:
-
routePath: '/{test}'
_controller: 'Form::form'
_arguments:
test: foo/test
My understanding is that the above configuration only gets resolved if the request includes the arguments with namespaces like this:
tx_powermail_pi1[controller]=Form
tx_powermail_pi1[action]=form
tx_powermail_pi1[foo][test]=xyz
So if the request does not match this it should trigger a 404 error.
But instead by simply calling https://myDomain.com/xyz somehow the action and controller and even the prefix foo of the arguments test magically appear and of course the configured route matches in this case:
I didnt even set a defaultController, but even in this case it should not match because the argument tx_powermail_pi1[foo][test] would not exist, right?
What am i missing here? How does typo3 resolve this?
Updated by Stephan Bauer about 3 years ago
- Related to Bug #95072: Custom aspect leads to list view on hidden elements added
Updated by Stephan Bauer about 3 years ago
It seems that I have the same problem with a custom aspect.
Updated by K Ch about 3 years ago
I can confirm that I have the same problem with Typo3 version 10.4.21. If route enhancers are disabled in configuration then everything works fine (even if we have multiple sites with many languages). If a route enhancer will be added to the configuration (news extension) then error handling doesn't work.
Updated by Benni Mack about 3 years ago
- Related to Bug #94510: SiteConfig with a config for a not available extension breaks errorHandling e. g. 404 page added
Updated by Cyril Janody over 2 years ago
- Is Regression set to Yes
Hi guys,
Any development on that issue? It's a critical one for SEO...
Thanks.
Updated by Oliver Hader about 2 years ago
- Sprint Focus set to On Location Sprint
Updated by Benni Mack about 2 years ago
- Status changed from New to Needs Feedback
Hey Philipp,
Philipp Lüdtke wrote in #note-6:
My understanding is that the above configuration only gets resolved if the request includes the arguments with namespaces like this:
tx_powermail_pi1[controller]=Form
tx_powermail_pi1[action]=form
tx_powermail_pi1[foo][test]=xyz
I think there is a misunderstanding, and your example shows this properly. The request only contains the URL. The request does not contain the arguments, but the plugin expects them, for this reason, the Extbase Enhancer fills your "www.example.com/my-page-does-not-exist" information INTO the arguments for plugin, not vice versa.
So, in the end, TYPO3 takes this URL:www.example.com/my-page-does-not-exist
and detects
- a site for www.example.com
- the best-match for the page (which is "/" = your site root)
- and the powermail argument "tx_powermail_pi1[foo][test]=my-page-does-not-exist" which then the plugin can use.
Your example with powermail actually is a good example why you should define: "limitToPages", and a prefix such as "/submit" in your "routePath: '/submit/{test}'", or alternatively you define a requirement for "test" (such as https://docs.typo3.org/m/typo3/reference-coreapi/11.5/en-us/ApiOverview/Routing/AdvancedRoutingConfiguration.html#simple-enhancer) or even better an aspect, to define your own logic what values are allowed for "{test}".
Hope that helps!
Updated by Oliver Hader about 2 years ago
I was not able to reproduce the behavior that has been mentioned in the original report (using the PersistedAliasMapper
on variable news-title
), the 404 page was shown as expected.
However when omitting an aspect mapper, routing cannot determine whether that value is actually valid (because, there's not indicator how and where to look up a record or asset). When using a mapper for the Powermail example on variable test
, 404 handling worked as well.
I've create a new issue for documenting these kind of obstacles in a new "troubleshooting" section (see #99046).
Updated by Oliver Hader about 2 years ago
- Related to Task #99046: DOCS: Routing Troubleshooting Section added
Updated by Oliver Hader about 2 years ago
- Status changed from Needs Feedback to Closed
Closing this issue. In case you thinks there's still something that needs to be changed in the core, please feel free to reopen this issue with providing details how to reproduce the issue - that includes the complete route configuration, code for potential custom aspect mappers, instruction used to generate a URL and/or the corresponding URL that lead to a misbehavior.