Bug #86895

routeEnhancer not working correct for paginate widget

Added by Jacco van der Post almost 2 years ago. Updated 8 months ago.

Status:
Closed
Priority:
Must have
Assignee:
-
Category:
Link Handling, Site Handling & Routing
Target version:
-
Start date:
2018-11-09
Due date:
% Done:

100%

TYPO3 Version:
9
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:
On Location Sprint

Description

routeEnhancers:
  CommunityPlugin:
    type: Extbase
    limitToPages: [15]
    extension: Blacommunity
    plugin: Blaforum
    routes:
    - routePath: ''
      _controller: 'Subforum::list'
    - routePath: '/{subforum_title}'
      _controller: 'Subforum::show'
      _arguments:
        'subforum_title': 'subforum'
    - routePath: '/{subforum_title}/{topic_title}/{page}'
      _controller: 'Topic::show'
      _arguments:
        'subforum_title': 'subforum'
        'topic_title': 'topic'
        'page': '@widget_0/currentPage'
    defaultController: 'Subforum::show'
    defaults:
      page: '0'
    requirements:
      page: '\d+'
    aspects:
      subforum_title:
        type: PersistedAliasMapper
        tableName: 'tx_blacommunity_domain_model_subforum'
        routeFieldName: 'slug'
      topic_title:
        type: PersistedAliasMapper
        tableName: 'tx_blacommunity_domain_model_topic'
        routeFieldName: 'slug'
      page:
        type: StaticRangeMapper
        start: '1'
        end: '1000'

Setting the defaults page on '1' or '0' has no effect, for pages 2 and further the routing works fine. On the first page '@widget_0/currentPage' cannot be found as an argument. I expected it the work as https://symfony.com/doc/current/routing/optional_placeholders.html: "By adding page to the defaults key, the {page} placeholder is no longer required. " so e.g.

URL    Route     Parameters
/blog           blog    {page} = 1
/blog/1           blog    {page} = 1
/blog/2           blog    {page} = 2

TYPO3 9.5.1.


Related issues

Related to TYPO3 Core - Bug #87436: Routing: empty 'defaults' entry does not work Closed 2019-01-15
Related to TYPO3 Core - Bug #90149: Consider Symfony route modifier Closed 2020-01-19
Related to TYPO3 Core - Bug #87731: ExtbasePluginEnhancer requirements ignored Closed 2019-02-18
Related to TYPO3 Core - Task #88686: Fix requirements in parameter Closed 2019-07-04
Related to TYPO3 Core - Bug #89641: Routing configuration with 3rd party url segments Closed 2019-11-11
Related to TYPO3 Core - Bug #90531: Requirements are not considered when an aspect is present Closed 2020-02-25
Related to TYPO3 Core - Bug #89185: Routing: requirements are not validated for PersistedAliasMapper in PluginEnhancer/ExtbasePluginEnhancer Closed 2019-09-17

Associated revisions

Revision 35d96a84 (diff)
Added by Oliver Hader 9 months ago

[BUGFIX] Ensure route defaults and requirements are considered

Changes concerning route `defaults`:
+ defaults are mapped now (e.g. `1` <=> `one`)
+ defaults are applied now when having multiple parameters in a
route path (e.g. `{default}/{required}`
+ defaults are applied now for types `Plugin` and `Extbase`
(type `Simple` worked in most cases)
+ enforced defaults are considered now (e.g. `{!default}`
+ `Route` instances get `_appliedDefault` option set now - which
contains deflated values and still needs to be inflated manually

Changes concerning route `requirements`:
+ requirements are deflated now for being processed as Symfony routes
(resulting in requirements being correctly applied now in enhancers)
+ requirements are skipped now for parameters having corresponding
aspects defined ("aspects take precedence over requirements")

References:
+ https://symfony.com/blog/new-in-symfony-4-3-always-include-route-default-values
+ https://symfony.com/doc/4.3/routing.html#parameters-validation
+ https://symfony.com/doc/4.3/routing.html#optional-parameters

Resolves: #86895
Releases: master, 9.5
Change-Id: Ia260e407dcc657a2e7c85628da9e001d94952c37
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/62885
Tested-by: TYPO3com <>
Tested-by: Susanne Moog <>
Tested-by: Benni Mack <>
Reviewed-by: Susanne Moog <>
Reviewed-by: Benni Mack <>

Revision fd4ddf13 (diff)
Added by Oliver Hader 9 months ago

[BUGFIX] Ensure route defaults and requirements are considered

Changes concerning route `defaults`:
+ defaults are mapped now (e.g. `1` <=> `one`)
+ defaults are applied now when having multiple parameters in a
route path (e.g. `{default}/{required}`
+ defaults are applied now for types `Plugin` and `Extbase`
(type `Simple` worked in most cases)
+ enforced defaults are considered now (e.g. `{!default}`
+ `Route` instances get `_appliedDefault` option set now - which
contains deflated values and still needs to be inflated manually

Changes concerning route `requirements`:
+ requirements are deflated now for being processed as Symfony routes
(resulting in requirements being correctly applied now in enhancers)
+ requirements are skipped now for parameters having corresponding
aspects defined ("aspects take precedence over requirements")

References:
+ https://symfony.com/blog/new-in-symfony-4-3-always-include-route-default-values
+ https://symfony.com/doc/4.3/routing.html#parameters-validation
+ https://symfony.com/doc/4.3/routing.html#optional-parameters

Resolves: #86895
Releases: master, 9.5
Change-Id: Ia260e407dcc657a2e7c85628da9e001d94952c37
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/60361
Tested-by: TYPO3com <>
Tested-by: Oliver Hader <>
Reviewed-by: Oliver Hader <>

Revision 1ee7266e (diff)
Added by Christian Eßl 8 months ago

[BUGFIX] Allow slashes in enhanced routes having aspects definitions

The changes made in #86895 broke previous behaviour in page routing by
disallowing the use of the "requirements" option for a route when
aspects are present - "aspects now take precedence over requirements".

While the reasoning behind this change is valid, the requirements in
the Symfony Routing package would now always default to '[^/]++'
(every character except "/") for routes that use aspects.

Before, it was possible to manually set the requirements to '.+' to
allow slashes in an argument value.

Instead of purging requirements for variable names having an aspect
definition as well, thoese requirements are set to `.+` to relax the
default Symfony constraints on default delimiter `/` in this case.

Resolves: #90531
Resolves: #88291
Resolves: #87333
Related: #86895
Releases: master, 9.5
Change-Id: I27076aa0425d050e729db84d8e3461a329321342
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/63529
Tested-by: Oliver Hader <>
Tested-by: TYPO3com <>
Tested-by: Christian Eßl <>
Tested-by: Benni Mack <>
Reviewed-by: Oliver Hader <>
Reviewed-by: Christian Eßl <>
Reviewed-by: Benni Mack <>

Revision e98ba4a4 (diff)
Added by Christian Eßl 8 months ago

[BUGFIX] Allow slashes in enhanced routes having aspects definitions

The changes made in #86895 broke previous behaviour in page routing by
disallowing the use of the "requirements" option for a route when
aspects are present - "aspects now take precedence over requirements".

While the reasoning behind this change is valid, the requirements in
the Symfony Routing package would now always default to '[^/]++'
(every character except "/") for routes that use aspects.

Before, it was possible to manually set the requirements to '.+' to
allow slashes in an argument value.

Instead of purging requirements for variable names having an aspect
definition as well, thoese requirements are set to `.+` to relax the
default Symfony constraints on default delimiter `/` in this case.

Resolves: #90531
Resolves: #88291
Resolves: #87333
Related: #86895
Releases: master, 9.5
Change-Id: I27076aa0425d050e729db84d8e3461a329321342
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/63655
Reviewed-by: Oliver Hader <>
Reviewed-by: Benni Mack <>
Tested-by: TYPO3com <>
Tested-by: Benni Mack <>

History

#1 Updated by Jacco van der Post almost 2 years ago

Update: the first time (not page 1) I click on the pagebrowser it works, clicking then on another page of the pagebrowser also does not work.

#2 Updated by Jacco van der Post almost 2 years ago

  • Subject changed from routeEnhancer not working for page 1 of paginate widget to routeEnhancer not working correct for paginate widget

#3 Updated by Jacco van der Post almost 2 years ago

Further investigation. So I have a list of topics with links like (decoded here) :

[1.] https://mysite.test/community
?tx_blacommunity_blaforum[action]=show
&tx_blacommunity_blaforum[controller]=Topic
&tx_blacommunity_blaforum[subforum]=1
&tx_blacommunity_blaforum[topic]=90
&cHash=8f508425fc790714af77ae33d800673e

This should change the HTML link into https://mysite.test/community/subforumtitle/topictitle
It does not, when {page} is included in the routepath.

When on that page [1.], the pagebrowser shows the correct links for pages 2 and further. Clicking on for example [2.] https://mysite.test/community/subforumtitle/topictitle/2 works. However on that page [2.] the links are not correct; page 1 links back to https://mysite.test/community and the other pages show the URL with parameters as above.

When entered by hand in the browser the links do work:
https://mysite.test/community/subforumtitle/topictitle/2
https://mysite.test/community/subforumtitle/topictitle/3
etc.

But https://mysite.test/community/subforumtitle/topictitle or https://mysite.test/community/subforumtitle/topictitle/1 does not work..

Since there is no RealUrl available anymore, I hope I find a solution soon... or I might end up replacing the fluid widget by coding my own pagebrowser. Thx

#4 Updated by Vasyl Mosiychuk almost 2 years ago

I have the same problem with the pagination widget...

#5 Updated by Carsten Pohl almost 2 years ago

Vasyl Mosiychuk wrote:

I have the same problem with the pagination widget...

Same behaviour here, the pagination widget looses all the arguments which are not the widget arguments.

#6 Updated by Carsten Pohl almost 2 years ago

Carsten Pohl wrote:

Vasyl Mosiychuk wrote:

I have the same problem with the pagination widget...

Same behaviour here, the pagination widget looses all the arguments which are not the widget arguments.

The widget needs the addquerystringmethod, then the widget keeps the variables.
<f:widget.paginate configuration="{addQueryString:1, addQueryStringMethod: 'GET'">

With this configuration for the routeEnhancers i get the right pagination.

- routePath: '/{category_var}'
  _controller: 'News::list'
  _arguments:
     category_var: cat
- routePath: '/{category_var}/{page}'
  _controller: 'News::list'
  _arguments:
   category_var: cat
   page: '@widget_0/currentPage'

#7 Updated by Jacco van der Post almost 2 years ago

@Carsten, thx good find.

However there is still a problem when using 'defaults', I would expect that if it's filled in, that the argument is not necessary.
I have this problem with another parameter (not from this Fluid pagination widget).

For example both URL's should work:

/blog blog {page} = 1
/blog/1 blog {page} = 1

Since I use now another solution then the Fluid pagination widget, could you test if this works for you?

#8 Updated by Wolfgang Klinger almost 2 years ago

  • Related to Bug #87436: Routing: empty 'defaults' entry does not work added

#9 Updated by Ben Robinson over 1 year ago

The paginator link issue (page 2 to page 1) can also be solved by outsourcing the list view to an additional routeEnhancer of type "Plugin":

routeEnhancers:
  NewsDetail:
    type: Extbase
    extension: News
    plugin: Pi1
    routes:
      - { routePath: '/{news_title}', _controller: 'News::detail', _arguments: {'news_title': 'news'} }
    aspects:
      news_title:
        type: PersistedAliasMapper
        tableName: 'tx_news_domain_model_news'
        routeFieldName: 'path_segment'
  NewsList:
    type: Plugin
    routePath: '/{@widget_0/currentPage}'
    namespace: 'tx_news_pi1'
    aspects:
      '@widget_0/currentPage':
        type: StaticRangeMapper
        start: '1'
        end: '1000'

At least that worked successfully for the news extension.

#10 Updated by Gerrit Code Review over 1 year ago

  • Status changed from New to Under Review

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/+/60361

#11 Updated by Christian Hackl 11 months ago

This patch https://review.typo3.org/c/Packages/TYPO3.CMS/+/60361 doesn't work for me.
I have set type: Extbase - defaults: page: '1' - but if I go back from page 2 - the URL shows me the extension parameters (for example: domain.tld/list?tx_myext_plugin%5Baction%5D=list&tx_myext_plugin%5Bcontroller%5D=Controller&cHash=86ec23d78c357b460a441a2e2a720d0f
instead of "domain.tld/list/page-1" or "domain.tld/list"...

#12 Updated by Pascal Geldmacher 11 months ago

I've the same problem with the pagination widget. On our website we use the blog extension, which have the same problem if you go from page 2 to page 1
https:/my-page.test/blog/?tx_blog_posts%5Baction%5D=listRecentPosts&tx_blog_posts%5Bcontroller%5D=Post&cHash=cdbbbaf5a61a58771bfabda89c663f8b
and we also have the same error with our custom extension.

#13 Updated by Gerrit Code Review 10 months 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/+/60361

#14 Updated by Susanne Moog 10 months ago

  • Sprint Focus set to On Location Sprint

#15 Updated by Gerrit Code Review 10 months ago

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/+/62885

#16 Updated by Gerrit Code Review 10 months ago

Patch set 2 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/+/62885

#17 Updated by Gerrit Code Review 10 months 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/+/60361

#18 Updated by Gerrit Code Review 10 months ago

Patch set 5 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/+/60361

#19 Updated by Gerrit Code Review 10 months ago

Patch set 6 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/+/60361

#20 Updated by Gerrit Code Review 10 months ago

Patch set 7 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/+/60361

#21 Updated by Gerrit Code Review 9 months ago

Patch set 8 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/+/60361

#22 Updated by Oliver Hader 9 months ago

  • Related to Bug #90149: Consider Symfony route modifier added

#23 Updated by Gerrit Code Review 9 months ago

Patch set 9 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/+/60361

#24 Updated by Gerrit Code Review 9 months ago

Patch set 10 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/+/60361

#25 Updated by Gerrit Code Review 9 months ago

Patch set 11 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/+/60361

#26 Updated by Gerrit Code Review 9 months ago

Patch set 12 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/+/60361

#27 Updated by Gerrit Code Review 9 months ago

Patch set 13 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/+/60361

#28 Updated by Gerrit Code Review 9 months ago

Patch set 14 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/+/60361

#29 Updated by Gerrit Code Review 9 months ago

Patch set 15 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/+/60361

#30 Updated by Gerrit Code Review 9 months ago

Patch set 3 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/+/62885

#31 Updated by Gerrit Code Review 9 months ago

Patch set 16 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/+/60361

#32 Updated by Gerrit Code Review 9 months ago

Patch set 4 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/+/62885

#33 Updated by Gerrit Code Review 9 months ago

Patch set 5 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/+/62885

#34 Updated by Gerrit Code Review 9 months ago

Patch set 6 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/+/62885

#35 Updated by Gerrit Code Review 9 months ago

Patch set 7 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/+/62885

#36 Updated by Oliver Hader 9 months ago

  • Related to Bug #87731: ExtbasePluginEnhancer requirements ignored added

#37 Updated by Oliver Hader 9 months ago

  • Related to Task #88686: Fix requirements in parameter added

#38 Updated by Gerrit Code Review 9 months ago

Patch set 17 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/+/60361

#39 Updated by Oliver Hader 9 months ago

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

#40 Updated by Oliver Hader 9 months ago

  • Related to Bug #89641: Routing configuration with 3rd party url segments added

#41 Updated by Felix Nagel 8 months ago

Can somebody help me how to configure the pagination in order to have same URL for /list/ and /list/page/1 when on list page or page 1? I assumed this ticket would solve my "duplicate content / same page but different URL" problem but in TYPO3 9.l5.14 its still present. Any ideas?

#42 Updated by Ben Robinson 8 months ago

Felix Nagel wrote:

Can somebody help me how to configure the pagination in order to have same URL for /list/ and /list/page/1? I assumed this ticket would solve my "duplicate content / same page but different URL" problem but in TYPO3 9.l5.14 its still present. Any ideas?

Does my above example not work for you to solve duplicate content for page 1?

#43 Updated by Felix Nagel 8 months ago

Does my above example not work for you to solve duplicate content for page 1?

No, same issue. Plain list page and page 1 have the same content but different URLs.

Anyway, this should just work out of the box with the Extbase type, shouldn't it?

#44 Updated by Christian Hackl 8 months ago

I have a problem, too.

"OneListPlugin" works as expected (on page 0 respectively 1 it doesn't show the "seite-1" part, but "TwoListPlugin" does not.

TwoListPlugin:
- shows me "domain.tld/seite-3/type-0/area" instead of "domain.tld/seite-3/type-0/area-0" // which is also incorrect because i don't want "type-0" or "area-0"
- if i go back to page 0 respectively 1 than it gives me 404 and a url like "domain.tld/seite-0/type-0/area" instead of "domain.tld/type-0/area-0"

if I set the widget_0 ('{page-label}-{page}') to the end of the URL in the YAML config, like:

      - { routePath: '/{type-label}-{type}/{area-label}-{area}/{page-label}-{page}', _controller: 'Job::list', _arguments: {'page': '@widget_0/currentPage', 'type': 'types', 'area': 'areas'} }

then gives me on click on page 2 a url like: "domain.tld/type-0/area-0/seite-2".
If I click on page 1 I get a URL like: "domain.tld/type-0/area-0/seite" so without "-0" or "-1" or something.

What do I expect?
I would expect that if no arguments (page, types, areas) are set (i.e. 0), they won't appear in the URL at all - just like with "OneListPlugin".
And if I click back, i.e. on page 0 respectively 1 then, of course, the argument "page-0" should not appear in the URL.

  OneListPlugin:
    type: Extbase
    extension: ExtName
    plugin: PluginOne
    defaultController: 'One::list'
    routes:
      - { routePath: '/{page-label}-{page}', _controller: 'One::list', _arguments: {'page': '@widget_0/currentPage'} }
    defaults:
      page: ''
    requirements:
      page: '\d+'
    aspects:
      page: { type: StaticRangeMapper, start: '1', end: '100' }
      page-label: { type: LocaleModifier, default: 'page', localeMap: [{ locale: 'en_.*', value: 'page' }, { locale: 'de_.*', value: 'seite' }] }

  ### not working:
  TwoListPlugin:
    type: Extbase
    extension: ExtName
    plugin: PluginTwo
    defaultController: 'Two::list'
    routes:
      - { routePath: '/{page-label}-{page}/{type-label}{type}/{area-label}{area}', _controller: 'Two::list', _arguments: {'page': '@widget_0/currentPage', 'type': 'types', 'area': 'areas'} }
    defaults:
      page: ''
      type: ''
      area: ''
    requirements:
      page: '\d+' 
      type: '\d+'
      area: '\d+'
    aspects:
      page: { type: StaticRangeMapper, start: '1', end: '100' }
      page-label: { type: LocaleModifier, default: 'page', localeMap: [{ locale: 'en_.*', value: 'page' }, { locale: 'de_.*', value: 'seite' }] }
      type-label: { type: LocaleModifier, default: 'type-', localeMap: [] }
      area-label: { type: LocaleModifier, default: 'area-', localeMap: [] }

----
Edit:
forget to mention: I want to filter (html/fluid form) the pagination, these are the 2 values "types" and "areas".
This works fine so far - just not with the right URL...

#45 Updated by Stefan P 8 months ago

Now that requirements are not considered when an aspect is present a whole of our sites did break.

I have a customly programmed aspect (used in the ExtbasePluginEnhancer) which considered slashes and resolved the URL by itself (by exploding the slashes and finding the correct uid of the dataset). To make this work I did set the requirements to .* (because teh default requirement [^/]++ forbids slashes). We did this to have arbitrarily deep category trees which are represented in the url.

This change totally breaks this, because I can not set the requiements anymore. What is the solution for me here?

#46 Updated by Oliver Bartsch 8 months ago

  • Related to Bug #90531: Requirements are not considered when an aspect is present added

#47 Updated by Benni Mack 8 months ago

  • Status changed from Resolved to Closed

#48 Updated by Oliver Hader 8 months ago

  • Related to Bug #89185: Routing: requirements are not validated for PersistedAliasMapper in PluginEnhancer/ExtbasePluginEnhancer added

Also available in: Atom PDF