Bug #92036
closed
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 almost 4 years ago.
Updated 12 months ago.
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:
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.
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!
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.
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).
- 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
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.
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.
- Related to Bug #91878: Fatal error in pagetree 9.5.20 added
- TYPO3 Version changed from 11 to 9
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.
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
- Status changed from New to Accepted
- Parent task set to #92091
- Related to Bug #92033: "Page tree error: Got unexpected reponse" with filter - allowed memory size exhausted added
- Related to Epic #93547: Collection of problems with large sites added
- Status changed from Accepted to Closed
Hey.
I think it's ok to close here. Checked in v12: There is a loading indicator and enter works.
Also available in: Atom
PDF