the issue stil exists at TYPO3 9.5.8

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.

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

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.

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.

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.

https://review.typo3.org/c/Packages/TYPO3.CMS/+/62811/2/typo3/sysext/core/Classes/Routing/Enhancer/PageTypeDecorator.php

        // 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...

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

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.

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.

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.

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.

Problem exists with TYPO3 9.5.24.

Same here. I can’t use direct_mail because of this bug. Has anybody a solution?

Same with v10 (10.4.15)

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

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

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

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

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

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

This bug isn't fixed in TYPO3 version 10.4.18, is it?
I still have the problem that the type parameter is ignored.

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?