Bug #92036

Story #92091: PageTree related flaws TYPO3 v9.5.20/21-dev or v10.4.6/7-dev

New behaviour of page tree filter might more easily submit "monster queries" or too many queries

Added by Sybille Peters 3 months ago. Updated 3 months ago.

Status:
Accepted
Priority:
Should have
Assignee:
-
Category:
Pagetree
Target version:
-
Start date:
2020-08-17
Due date:
% Done:

0%

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

Description

The behaviour of the filter was changed in https://review.typo3.org/c/Packages/TYPO3.CMS/+/65208 to submit a query automatically after a small delay so that the query is submitted when you stop typing.

However, if you do not type fast enough, several (unnecessary) queries will be submitted.

Example

You want to filter for "abc". Since you are a slow typer, 3 queries are submitted for pages matching:

  • "a"
  • "ab"
  • "abc"

You only need the third one. Also, the result sets of the queries which are unnecessarily being submitted might be quite large for
sites with a large number of pages.

Suggestion

  • Have a minimum number of characters before the query is submitted automatically (e.g. 2 or 3)
  • force submit by pressing ENTER

For me, the pressing of ENTER which was introduced with previous patch was not a problem. In fact, I found it preferrable to current behaviour because it reduces amount of unnecessary queries and you had direct control over what was fetched.


Related issues

Related to TYPO3 Core - Bug #91878: Fatal error in pagetree 9.5.20Closed2020-07-28

Actions
Related to TYPO3 Core - Bug #92033: "Page tree error: Got unexpected reponse" with filter - allowed memory size exhaustedNew2020-08-17

Actions
#1

Updated by Andreas Fernandez 3 months ago

The only two feasible solutions are increasing the timeout (personally I wouldn't wait longer than 600ms) and require at least two characters for a query. Forcing to press the "enter" key is an absolute no-go, especially since this won't work on mobile devices!

#2

Updated by Sybille Peters 3 months ago

Hmm, not so easy. I would hate for this get changed again and make more people unhappy than before.

I had a similar use case where a search for a person is performed from external source. Here the 3 char minimum was ok (and combined with the delay it worked quite well).

For page tree, a minimum of 2 might already be a problem.

In a large site, I often get too many results for "short" search words and I would not want unnecessary retrieve operations but for small sites it may well be the other way around: you do not want these restrictions and they will be annoying.

#3

Updated by Ingo Fabbri 3 months ago

This is so ridiculous.

Folks, take a look how the OLD filter worked in v6/v7 or v8. People had no problem with that filter, so holy batman.

The old filter had a minimum of 3 characters (except digits).
The exact delay I have not measured, but it feels like approx. 1000ms. Seems more than safe to avoid too early requests. Someone may look up in the old source-code (always a good idea to do that, when one re-implements a removed feature).

#4

Updated by Sybille Peters 3 months ago

  • Description updated (diff)

Ingo, the difference to the "old" filter is that the old filter could filter client-side because the entire page tree had been fetched.

The whole point of the recent changes was to change this - so that the entire page tree is no longer fetched by default (which reduces delays and memory reasons). For this reason, the

#5

Updated by Richard Haeser 3 months ago

One small thing: Please be careful with minimum amount of characters. We need to check if the input is an integer as people are also filtering on page id.

#6

Updated by Richard Haeser 3 months ago

I personally don't have an issue with the current settings in a 150.000+ pages install. Also the queries on just 1 or 2 letters are doable in time. I think we should really take the time to check what is the wanted behaviour and have a look at the past (although the tech background was different) and what users will give as input.

We have a test with 50 editors coming up in 2 weeks. I will for sure add this question to the list.

#7

Updated by Oliver Hader 3 months ago

  • Related to Bug #91878: Fatal error in pagetree 9.5.20 added
#8

Updated by Oliver Hader 3 months ago

  • TYPO3 Version changed from 11 to 9
#9

Updated by Andreas Kiessling 3 months ago

Sybille Peters wrote:

Ingo, the difference to the "old" filter is that the old filter could filter client-side because the entire page tree had been fetched.

The whole point of the recent changes was to change this - so that the entire page tree is no longer fetched by default (which reduces delays and memory reasons). For this reason, the

Ingo was talking about the tree in 6/7/8 which did NOT fetch the whole tree, but loaded on demand and filtered serverside.
The loading of the whole pagetree was introduced with the SVG rewrite in v9.

#10

Updated by Oliver Hader 3 months ago

  • Is Regression set to Yes
#11

Updated by Oliver Hader 3 months ago

From my point of view...

  • there still should be the possibility to hit enter (currently it seems, this is only triggered on setTimeout)
  • there probably should be a corresponding icon the actually start the search (it's a "search" now, not a "filter" anymore)
  • "filtering" immediately in the past only worked because there was not async server-roundtrip → a "search" should be invoked explicitly
#12

Updated by Oliver Hader 3 months ago

  • Status changed from New to Accepted
#13

Updated by Oliver Hader 3 months ago

  • Parent task set to #92091
#14

Updated by Sybille Peters about 1 month ago

  • Related to Bug #92033: "Page tree error: Got unexpected reponse" with filter - allowed memory size exhausted added

Also available in: Atom PDF