Project

General

Profile

Actions

Bug #87104

closed

PageTypeSuffix removes type parameter for non mapped type values

Added by Steffen Mächtel about 6 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Site Handling, Site Sets & Routing
Target version:
-
Start date:
2018-12-07
Due date:
% Done:

100%

Estimated time:
TYPO3 Version:
9
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:

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

page_type_suffix.png (33.4 KB) page_type_suffix.png Steffen Mächtel, 2018-12-07 17:02
without_page_type_suffix.png (24.9 KB) without_page_type_suffix.png Steffen Mächtel, 2018-12-07 17:02
example_code.txt (931 Bytes) example_code.txt Steffen Mächtel, 2018-12-07 17:02

Related issues 6 (3 open3 closed)

Related to TYPO3 Core - Bug #89346: sitemap.xml does not work correctlyNew2019-10-04

Actions
Related to TYPO3 Core - Bug #87016: Seo sitemap does not note routeEnhancer on extensionsClosed2018-11-27

Actions
Related to TYPO3 Core - Bug #86835: Static route sitemap.xml is still not working on single-page treeNew2018-11-02

Actions
Related to TYPO3 Core - Bug #88836: page type not respected under some circumstancesClosed2019-07-24

Actions
Related to TYPO3 Core - Bug #87817: PageLinkBuilder fails adding pagetype parameter, if routeEnhancers for PageTypeSuffix is definedClosed2019-03-01

Actions
Related to TYPO3 Core - Bug #94244: PageTypeSuffix Enhancer buggyNew2021-05-31

Actions
Actions #1

Updated by Gerrit Code Review about 6 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

Actions #2

Updated by Anja Leichsenring about 6 years ago

  • Status changed from Under Review to New
Actions #3

Updated by Georg Dümmler over 5 years ago

the issue stil exists at TYPO3 9.5.8

Actions #4

Updated by Tymoteusz Motylewski about 5 years ago

  • Related to Bug #89346: sitemap.xml does not work correctly added
Actions #5

Updated by Tymoteusz Motylewski about 5 years ago

  • Related to Bug #87016: Seo sitemap does not note routeEnhancer on extensions added
Actions #6

Updated by Tymoteusz Motylewski about 5 years ago

  • Related to Bug #86835: Static route sitemap.xml is still not working on single-page tree added
Actions #7

Updated by Christopher Schnell about 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.

Actions #8

Updated by hwt3 no-lastname-given almost 5 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'

Actions #9

Updated by Benni Mack almost 5 years ago

  • Status changed from New to Needs Feedback

This should be fixed in 9.5.14 - can you verify if this is fixed?

Actions #10

Updated by Benni Mack almost 5 years ago

  • Related to Bug #88836: page type not respected under some circumstances added
Actions #11

Updated by Benni Mack almost 5 years ago

  • Related to Bug #87817: PageLinkBuilder fails adding pagetype parameter, if routeEnhancers for PageTypeSuffix is defined added
Actions #12

Updated by Anna Emde almost 5 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.

Actions #13

Updated by Benni Mack almost 5 years ago

  • Status changed from Needs Feedback to Accepted

Thanks for the info

Actions #14

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

Actions #15

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.

Actions #16

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.

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

Actions #17

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

Actions #18

Updated by Lidia Demin over 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.

Actions #19

Updated by Benni Mack over 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.

Actions #20

Updated by Rémy DANIEL over 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.

Actions #21

Updated by Peter Linzenkirchner about 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.

Actions #22

Updated by Christian Weiske almost 4 years ago

Problem exists with TYPO3 9.5.24.

Actions #23

Updated by Bernhard Eckl over 3 years ago

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

Actions #24

Updated by Henrik Elsner over 3 years ago

Same with v10 (10.4.15)

Actions #25

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

Actions #26

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

Actions #27

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

Actions #28

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

Actions #29

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

Actions #30

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

Actions #31

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

Actions #32

Updated by Benni Mack over 3 years ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100
Actions #33

Updated by Benni Mack over 3 years ago

  • Status changed from Resolved to Closed
Actions #34

Updated by Bernhard Eckl over 3 years ago

  • Related to Bug #94244: PageTypeSuffix Enhancer buggy added
Actions #35

Updated by Sven Burkert over 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.

Actions #36

Updated by Benni Mack over 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?

Actions

Also available in: Atom PDF