TYPO3 Core

They convert the range into an array and yes...there is a limitation of max array elements. I have tried it with a timestamp in range:

Start: 1000000000
End: 99999999999

Which results in:

Warning: range(): The supplied range exceeds the maximum array size: start=1000000000 end=99999999999 in /Users/froemken/htdocs/test.test/temp.php on line 2

I would prefer to remove this array range strval thing.

Stefan

The reason is described in the functions doc:
"The amount of items is limited to 1000 in order to avoid brute-force scenarios and the risk of cache-flooding."

+1 for removing the complete range construct. If you have, e.g. given a range from 4000 to 6000 for postals you haven't got a chance to define this.

Maybe we can change the exception to a log entry (warning)?

Exactly, the range limitation has been added in order to avoid brute force attacks which lead to many cache entries - the StaticRangeMapper is just mitigating that to 1000, PageRouter has a similar maximum on StaticMappableAspectInterface implementations set to 10000 (for all affected mappers/aspects).

This has to been seen as alternative to know cHash which creates a signature over all arbitrary parameters in order to make the request unique and valid - thus, verification if the requested resource really exists (and triggers a new cache entry) is the primary goal here.

This could be achieved by using an additional mapper/aspect which could guarantee that, e.g.

• database lookup wether a record with a given uid exists - SELECT COUNT(uid) FROM <table> WHERE uid=<parameter> (must exist) - having 123
• database lookup wether some date representation exists - SELECT COUNT(uid) FROM <table> WHERE DATE_FORMAT(tstamp, '%Y-%m')=<parameter> (must exist) - having 2019-03

An alternative would be a mapper/aspect that is storing valid URLs in the database, like RealURL did - however that also had some side-effects on cHash and would not have worked having empty "caches" (URL not generated yet).

In general new implementations depend on their actual use case (e.g. "date and month filter", "color filter", "combination of categories", "alphabetical prefix - titles starting with 'A'", ...).

Stefan Froemken wrote:

They convert the range into an array and yes...there is a limitation of max array elements. I have tried it with a timestamp in range:

Start: 1000000000
End: 99999999999

Which results in:

Warning: range(): The supplied range exceeds the maximum array size: start=1000000000 end=99999999999 in /Users/froemken/htdocs/test.test/temp.php on line 2

I would prefer to remove this array range strval thing.

Why and what is your use case? How is the timestamp used in your scenario?

I guess there are more projects than ours that deals with more than 100k news or records that needs to get paginated. When using f:widget.paginate and nice routes we do not want to use 100 elements per page because the amount of maximum pages is limited.

For this scenario the "valid values" would be in the range of [0; count(news) % page-size] where the news amount is dynamic (adding new records) and page-size is configured in TypoScript (but could be duplicated to route configuration in case it would be the same for all news plugins on that installation).

For this case i created my own StaticNumberRangeMapper for only numeric range and do not need an array

This hardcoded limit is very annoying and makes it impossible to generate URLs for more than 25 pages in my news archive module..

+ 1 for making the range constraint optional.

Markus Pircher wrote in #note-7:

For this case i created my own StaticNumberRangeMapper for only numeric range and do not need an array

Just hit this issue. I have ~20000 posts, with 15 items per post. Results in over 1000 pages. Really annoying...

@Markus Pircher is your StaticNumberRangeMapper public?

just being curious:

20000 posts, with 15 items per post

how do you solve this from UX side? no user will click through 1000 pages

Georg Ringer wrote in #note-11:

just being curious:

20000 posts, with 15 items per post

how do you solve this from UX side? no user will click through 1000 pages

indeed, noone will click through 1000 pages.

I do have a detailed search form.
Some people change the url and set a page number (I do this regularly).
And if I ever find the time, I plan to change the paging ui to have a "+10 pages" button instead of just the "next page".

I can not delete the posts. There has to be some kind of "browse through all posts" functionality. For now, I just changed to more posts per page, but I expect to hit the same problem sometimes in the next 2 years.

Please reopen. I‘ve sent you my arguments via Slack…