Project

General

Profile

Actions

Bug #91537

closed

9.5.15+ breaks routing: Only respects the shortest matching rule

Added by Till Wimmer almost 4 years ago. Updated almost 4 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Link Handling, Site Handling & Routing
Target version:
-
Start date:
2020-05-29
Due date:
% Done:

0%

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

Description

Hi there,

since the update to 9.5.15, routing is not working correctly anymore. It also fails with 9.5.16 and 9.5.18 (9.5.17 not tested).

With migration from Typo3 V6 we had to maintain the same URL "syntax" as we had through RealURL for many years... Which I could achieve with 5.14 and before.

(See also discussion here: https://typo3.slack.com/archives/C2ZKN8P7G/p1588706756156400)

The URLs should look like this:

/.../measure/{messUid}/year/{yearUid} [/nr/{preselUid}] [/page/{pageN}]

for example

../measure/3/year/2018
 - or - 
../measure/3/year/2018/nr/234
 - or -
../measure/3/year/2018/page/2
 - or -
../measure/3/year/2018/nr/234/page/2

I.e. if a preselUid is given, the prefix /nr should be added. And /page prefix in presence of a pageN.

These rules did the trick with 9.5.14 and earlier:

    routes:
      -
        routePath: '/step3/measure/{messung}/year/{jahr}'
        _controller: 'Resultat::spitalsuche'
        _arguments:
          messung: messung
          jahr: jahr
      -
        routePath: '/step3/measure/{messung}/year/{jahr}/page/{page}'
        _controller: 'Resultat::spitalsuche'
        _arguments:
          messung: messung
          jahr: jahr
          page: currentPage
      -
        routePath: '/step3/measure/{messung}/year/{jahr}/nr/{listing}'
        _controller: 'Resultat::spitalsuche'
        _arguments:
          messung: messung
          jahr: jahr
          listing: selectedListing
      -
        routePath: '/step3/measure/{messung}/year/{jahr}/nr/{listing}/page/{page}'
        _controller: 'Resultat::spitalsuche'
        _arguments:
          messung: messung
          jahr: jahr
          listing: selectedListing
          page: currentPage
    defaultController: 'Resultat::messung'
    requirements:
      page: \d+
    aspects:
      messung:
        type: PersistedAliasMapper
        tableName: tx_anq_domain_model_messung
        routeFieldName: uid
      jahr:
        type: PersistedAliasMapper
        tableName: tx_anq_domain_model_jahr
        routeFieldName: id
      graph:
        type: PersistedAliasMapper
        tableName: tx_anq_domain_model_graph
        routeFieldName: uid
      listing:
        type: PersistedAliasMapper
        tableName: tx_anq_domain_model_listing
        routeFieldName: uid
      page:
        type: StaticRangeMapper
        start: '1'
        end: '100'

Since 9.5.15 when resolving a request URL, only the first and shortest matching route is respected:

routePath: '/step3/measure/{messung}/year/{jahr}'

The arguments currentPage and selectedListing are ignored and not available in the GET parameters.

But the URL-Builder still correctly uses all routing rules, i.e.

{f:uri.action(action:'spitalsuche', arguments:{messung:messung, jahr:jahr, currentPage:2}

produces the desired URL /measure/3/year/2018/page/2.

So the routing is definitely broken and asymmetrical...

I tried with swapping the rules, i.e. the longest one first. This also broke the URI-Builder, resulting in URLs like: /measure/27/year/2017?tx_anq_anqpublicarea[currentPage]=2&tx_anq_anqpublicarea[selectedListing}=22621&cHash=..


Related issues 1 (1 open0 closed)

Related to TYPO3 Core - Bug #91633: 9.5.19 breaks formerly working routeEnhancerUnder ReviewOliver Hader2020-06-10

Actions
Actions #1

Updated by Arne Bracht almost 4 years ago

  • Related to Bug #91633: 9.5.19 breaks formerly working routeEnhancer added
Actions #2

Updated by Oliver Hader almost 4 years ago

  • Status changed from New to Closed

Thanks for the report. That's exactly the same as in issue #91633

Actions #3

Updated by Till Wimmer almost 4 years ago

But configuration in question of bug 91633 was working with 9.5.18. This configuration here is not working since 9.5.15. And it doesn't use defaults.

So just closing it is not really a solution.

-- Update

I cloned 9.5.20-dev from Git which should have the patches... This did not solve the problem.

It's the same behavior: URIs get built correctly, but in the controller, some GET parameters are not set, i.e. not the longest possible route match is used.

-- Correction

9.5.20-dev branch did not contain this patch. I now checked out master, applied the patch.... And indeed it solved the problem!

Thank you a lot and sorry for the hassle. Will this be ported to the 9.5. branch?

Actions

Also available in: Atom PDF