Bug #96599
open
Slugs with and without trailing slash are considered different but will confuse URL handling in frontend
0%
Description
If pages exist with the slugs "/foobar" and "/foobar/" the checks for duplicate slugs will not change one to a slug with a trailing number.
When you request the URL domain.ext/foobar one of the pages will be accessed. If that page is disabled the frontend will produce a 404 error.
- Foobar ( slug: /foobar ) - Achive - Foobar ( slug: /foobar/ , page hidden)
In this situation domain.ext/foobar produced a 404 error. Changing the slug of the page Foobar in the root to "/foobar-test" made that page accessible. The backend allowed the slug to be renamed back to "/foobar" (the automatic slug generator created that from the page title!).
The workaround was to change the slugs of the page in the archive. This made the active page accessible again.
Updated by Jigal van Hemert about 2 years ago
Edit: One of the pages does not need to be disabled. As soon as there are pages where the slug only differs in the trailing slash the routing seems to be confused and produces a 404 error.
Updated by Georg Ringer about 2 years ago
- Status changed from New to Needs Feedback
Those 2 urls are technically different and can also be indexed differently!
What about using e.g. https://github.com/studiomitte/redirect2trailingslash
Updated by Jigal van Hemert over 1 year ago
Georg Ringer wrote in #note-2:
Those 2 urls are technically different and can also be indexed differently!
What about using e.g. https://github.com/studiomitte/redirect2trailingslash
If those are "technically different" then the routing handling of TYPO3 should be able to handle both of them correctly. It's now giving a 404 on the URL without the trailing slash.
Most users will not consider these URLs different; they will remove the trailing slash. I've tested a dozen or so websites from different TLD's and all of them accept URLs with or without trailing slash and serve the exact same page.
So, if URL handling will serve the same page with and without the trailing slash than the check for slugs should (must) also consider them as equal. If they should be considered "different" then the URL handling must serve the correct page and not produce a 404 error with one of them.
Updated by
Updated by Stefan Bürk 9 months ago
- Related to Bug #100990: Pages with trailing slash in slug are not resolved if requested uri does not contain a trailing slash added
- Related to Bug #86055: pages.slug always removes the trailing slash added
- Related to Bug #89091: Page with a slug with trailing slash results in 404 added
Updated by Stefan Bürk 9 months ago
We have now a little problem now.
There have been use-cases and patches allowing that a page ca be resolved:
- slug field without trailing slash, requested without trailing slash
- slug field without trailing slash, requested with trailing slash
- slug field with trailing slash, requested without trailing slash
- slug field with trailing slash, requested with trailing slash
In these scenarios, it was always related to "one" page. Now, this issue
describes the use case to have two dedicated pages with similar slug field
value, just differ in the the trailing slash. That means, for these the "exact"
match should rule first at all I guess.
Georg is right that "technical" this should be different things, but in the
current implementation and the "expectation" some developer/integrators/customers
have this is not "really" the case. I never really loved this double handling
regarding the ending slash.
Have to rethink here and eventually we need to create a standing concept first,
a concrete one. Otherwise, it will get really hard to get all cases which annul
each other in the one or other way.
Or whas this issue only realated to the "duplicate" detection issue and "auto-suffix"
by a numnber feature - in the way, that one of them should have been automatically be
renamed ? (Diffucult with enabled auto-redirect create than).
I linked some additional issues regarding the mentioned trailing slash workaround
handling patches.
Updated by