Bug #87104
closedPageTypeSuffix removes type parameter for non mapped type values
100%
Description
Tested with 9.5.1 and 9.5.2-dev
When i use the PageTypeSuffix, all non mapped type values are removed from url. In this example "type=5" is not configurated in the sites/config.yaml.
Non mapped types should be append as query string?
PageTypeSuffix:
type: PageType
default: .html
index: 'home'
map:
.html: 0
.json: 3
With PageTypeSuffix:¶
when i try to generate a link for type = 5, the type parameter is not available in the url. (its removed)
Without PageTypeSuffix:¶
when i remove the PageTypeSuffix configuration complete, the generated urls are valid.
Files
Updated by Gerrit Code Review over 5 years ago
- Status changed from New to Under Review
Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/59060
Updated by Anja Leichsenring over 5 years ago
- Status changed from Under Review to New
Updated by Tymoteusz Motylewski almost 5 years ago
- Related to Bug #89346: sitemap.xml does not work correctly added
Updated by Tymoteusz Motylewski almost 5 years ago
- Related to Bug #87016: Seo sitemap does not note routeEnhancer on extensions added
Updated by Tymoteusz Motylewski almost 5 years ago
- Related to Bug #86835: Static route sitemap.xml is still not working on single-page tree added
Updated by Christopher Schnell almost 5 years ago
Issue still exist in 9.5.11
Another problem with this is caching. One use case might be to generate e.g. a mobile navigation via AJAX call. Previously, we would call /mobilenavigation?type=123 which is the same path from the whole site (and thus cached as one page in TYPO3). Now in 9.5 with the pagetype configured in the site configuration it is only a suffix which means that the route to the AJAX page is appended to the path of each page. So instead of mydomain.xx/mobilenavigation?type=123 we get mydomain.xx/page1/mobilenavigation.suffix, mydomain.xx/page2/mobilenavigation.suffix, mydomain.xx/page3/mobilenavigation.suffix and so on. Each of these page have to be generated and cached which is a major decreasement in performance.
Updated by hwt3 no-lastname-given over 4 years ago
Furthermore, the 'type' parameter is ignored in url resolving, when PageTypeSuffix is used but the type number is not present in the map. So calling
/home.html?type=5
shows just the standard page with type '0'
Updated by Benni Mack over 4 years ago
- Status changed from New to Needs Feedback
This should be fixed in 9.5.14 - can you verify if this is fixed?
Updated by Benni Mack over 4 years ago
- Related to Bug #88836: page type not respected under some circumstances added
Updated by Benni Mack over 4 years ago
- Related to Bug #87817: PageLinkBuilder fails adding pagetype parameter, if routeEnhancers for PageTypeSuffix is defined added
Updated by Anna Emde over 4 years ago
Benni Mack wrote:
This should be fixed in 9.5.14 - can you verify if this is fixed?
It is not fixed in 9.5.14.
Updated by Benni Mack over 4 years ago
- Status changed from Needs Feedback to Accepted
Thanks for the info
Updated by Susanne Moog over 4 years ago
- Status changed from Accepted to Needs Feedback
Can you check the comments and solution in #88836?
Please note that some of the examples here are contrary to what can be considered expected behaviour:
- if you configure .html as mapped to type=0, you cannot expect /home.html?type=5 to work, as that would contain a duplicate type definition (.html = type=0)
- however without the suffix the ?type=5 should be kept
Updated by Arne Bracht over 4 years ago
I have a similar problem. I try to use typeNum for different Layouts.
TYPO3 9.5.14
testpage = PAGE
testpage < page
testpage.typeNum = 1
testpage.config.linkVars = type
without the routeEnhancer:
PageTypeSuffix: type: PageType default: .html index: 'start' map: .html: 0 .app: 1
all links where generated with &type=1 in menu and RTE wich is perfect.
But if I set the routeEnhancer, it is possible to open every URL with test.intern/test.app and works like a charm but all links lose the type (typeNum) an switch to default .html
The Patch from #88836 doesn't work.
Updated by Stefan Isak over 4 years ago
IMHO patch from #88836 only works for configs where default is an empty string.
Whenever default is configured like `default: .html` or something, the condition will never match and therefore skips the type parameter just like before.
// If the type is > 0 but the value could not be resolved,
// the type is appended as GET argument, which can be resolved already anyway.
// This happens when the PageTypeDecorator is used, but hasn't been configured for all available types.
if ($value === '' && !empty($type)) {
return;
}
Maybe this should be
// If the type is > 0 but the value could not be resolved,
// the type is appended as GET argument, which can be resolved already anyway.
// This happens when the PageTypeDecorator is used, but hasn't been configured for all available types.
if ($value === $this->default && !empty($type)) {
return;
}
but I have no deeper understanding from all this routing stuff, so maybe there are some side effects...
Updated by Arne Bracht over 4 years ago
9.5.17 ist same problem.
routeEnhancers:
PageTypeSuffix:
type: PageType
index: 'index'
default: '.html'
map:
.html: 0
.app: 1
Without the routeEnhancers <url>.<tld>/<somepage>?type=1 work and type will be kept at every link in menu.
With the routeEnhancers .app will work for a single page when manualy enter the url, but links in menu switch back to default (.html). Same if default is an empty string. And same with suggested solution from #16
Updated by Lidia Demin about 4 years ago
Can also confirm on 9.5.17. Here is a use case for the need to override the mapped page type by GET parameter:
Configuration:
PageTypeSuffix:
type: PageType
default: '/'
index: ''
map:
'/': 0
sitemap.xml: 123456
A third-party extension uses a non-mapped page type (e.g. 99) to fetch JSON data from a current URL by grabbing the URL via JavaScript and appending the page type. The resulting URL then is something like /mypage/?type=99
. But even if I map the page type (e.g. to markers.json) it isn't recognized, because the request is appending the page type as GET parameter instead of using the mapped value (I have no influence here).
I would expect that /mypage/markers.json
is equal to /mypage/?type=99
. Both requests should be valid if type is known to the mapping.
Updated by Benni Mack almost 4 years ago
Lidia Demin wrote:
Can also confirm on 9.5.17. Here is a use case for the need to override the mapped page type by GET parameter:
Configuration:
[...]A third-party extension uses a non-mapped page type (e.g. 99) to fetch JSON data from a current URL by grabbing the URL via JavaScript and appending the page type. The resulting URL then is something like
/mypage/?type=99
. But even if I map the page type (e.g. to markers.json) it isn't recognized, because the request is appending the page type as GET parameter instead of using the mapped value (I have no influence here).I would expect that
/mypage/markers.json
is equal to/mypage/?type=99
. Both requests should be valid if type is known to the mapping.
Hey Liddy,
this works on a 9.5.20 installation for me:
I have a custom typeNum=123, which I can access with www.mydomain.com/en/mypage/?type=123
Can you please recheck (again)? sorry.
Updated by Rémy DANIEL almost 4 years ago
Hello Benni
I've just tested on TYPO3 9.5.20.
The ?type is discarded from the query string if it is not mapped.
My config:
PageTypeSuffix: type: CustomPageType default: .html index: index map: - sitemap.xml: 1533906435
Generate a link with :
{f:uri.page(pageUid: 10, pageType: 1234)}
Output :
/page-10.html
Instead of
/page-10.html?type=1234
Accessing /page-10.html?type=1234
directly does not work neither.
If I remove the PageTypeSuffix from the routing configuration, the URL is generated with the ?type parameter and I can access /page-10?type=1234
I don't know if it is desirable, but I would expect that PageTypeSuffix handles ontly mapped types and keep un-mapped type as is in the query string.
Cheers.
Updated by Peter Linzenkirchner almost 4 years ago
The same problem in TYPO3 10. If PageTypeSuffix is defined in the routeEnhancers www.mydomain.com/en/mypage/?type=123 does not work anymore. Only possibility is to define every pageType which is used the installation in the routeEnhancers:
routeEnhancers:
PageTypeSuffix:
type: PageType
default: /
index: ''
map:
/: 0
ajax.html: 87035
ajax1.html: 87036
ajax2.html: 87037
and so on. Then you can call the the pages:
www.mydomain.com/en/mypage/ajax.html
www.mydomain.com/en/mypage/ajax2.html
www.mydomain.com/en/mypage/ajax3.html
I too would expect that PageTypeSuffix handles ontly mapped types and keep un-mapped type as is in the query string.
Updated by Bernhard Eckl over 3 years ago
Same here. I can’t use direct_mail because of this bug. Has anybody a solution?
Updated by Gerrit Code Review over 3 years ago
- Status changed from Needs Feedback to Under Review
Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/68978
Updated by Gerrit Code Review over 3 years ago
Patch set 1 for branch 10.4 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/69115
Updated by Gerrit Code Review over 3 years ago
Patch set 2 for branch 10.4 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/69115
Updated by Gerrit Code Review over 3 years ago
Patch set 1 for branch 9.5 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/69116
Updated by Gerrit Code Review over 3 years ago
Patch set 2 for branch 9.5 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/69116
Updated by Gerrit Code Review over 3 years ago
Patch set 3 for branch 9.5 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/69116
Updated by Gerrit Code Review over 3 years ago
Patch set 4 for branch 9.5 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/69116
Updated by Benni Mack over 3 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset 2625d6b43001efc91fcbfa08c1ca0d416ee2ee7b.
Updated by Bernhard Eckl about 3 years ago
- Related to Bug #94244: PageTypeSuffix Enhancer buggy added
Updated by Sven Burkert about 3 years ago
This bug isn't fixed in TYPO3 version 10.4.18, is it?
I still have the problem that the type parameter is ignored.
Updated by Benni Mack about 3 years ago
Sven Burkert wrote in #note-35:
This bug isn't fixed in TYPO3 version 10.4.18, is it?
I still have the problem that the type parameter is ignored.
Can you open up a new ticket with your configuratino?