TYPO3 Core

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).

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.

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