Thanks for writing back.
> 1. What should be the view's query filter when "verkoopstatus" is not a number but a text field f.e. "In review"?
> Would that be: The "verkoopintentie" is a "string" "like" the following "constant" "In review"?
> Is the string case sensitive?
> We can add multiple values for a number but NOT for a string???
> See the backend for hidden link
- For the text field, you'll change the comparison type from 'number' to "string".
The 'Like' operator is used when the exact value is not known so it works vaguely and can bring in unexpected results too. You should use "equal" if you're looking for a comparison with a single value, and "in" if you need to compare with multiple values.
(like I did in my example view)
And yes the 'string' is case-sensitive, which means "In review" is not equal to "In Review". This is why when you have to perform filtering operations, it is better to use option-based fields (like select) and not text input fields, where the user can add text differently. Also, filtering by 'numerical' value is much more efficient and faster than 'string' based values.
> 2. How can we delete the "filter based on the frontend search filter by Search index?"
- I see that you've already managed to edit the query filter for the search index field.
> 3. Can we keep the "filter post title, content and fields based on the frontend
> input search filter" and "filter based on the frontend search filter selection"?
> Can we keep the filters "zoeken op adres", "provincie/stad" and "algemene score",
> "development index", "liveability index", "search index"?
- You can choose to keep as many search filters or query filters as needed, but as Nigel explained in the other thread on performance, the more filters the query will have, naturally the more performance hit it will get. So, you'll have to find the right balance between the functionality and the performance.
> 4. If we visit hidden link
> no eigendommen are found.
- I do see results on the page, now.
> 5. Also we get results where the development index is below 70.
- That is expected since, in the view used on the page ( "Eigendommen - kaart met filters-copy-1633271318" ), the query filter for the development index field is using the operator "lower than or equal to".
( screenshot: hidden link )
To see the results with index value 70 and above, the operator should be "greater than or equal to", similar to how I set it in my example view.
> 6. Also BOTH below pages are SUPER slow again, while we don't filter or sort on custom fields!
> Have Nigel take a look at them to optimize urgently.
> hidden link
> hidden link
- I feel there is some confusion here about what "filtering" means. Whether you'll use filters using the front-end search fields or using the static "query filter" settings in the view's editor, the end result of the performance impact on the query to get the results will be the same.
In absence of front-end search filter fields, there will be some performance benefit, as the view will not have to do the extra processing to show the options of those search fields. But, to get the actual results, the query complexity will remain the same, no matter if you're filtering using front-end search fields or the back-end query filter.
Here is a simple example to make this more clear.
Suppose you have some "Book" posts and you create a view to show all those posts. The view's query will be simplest in this case as there is no filtering involved, so it would be the fastest.
Now, if you'll create another view to show all "Book" posts, but with some filters to include only those books which fulfill "X, Y, Z criteria", then it will be slower than the previous view, because the query complexity has increased.
This means that performance depends on the complexity of the filtering criteria and not how that filtering is added (e.g. front-end search fields or the back-end query filter).
If you'll check both the views used in these two pages, you'll see that there are 3 static query filters for the custom fields "Development index", "Status", and "Score" and 1 font-end search filter for the custom field "Liveability index".
I hope this explanation will help.
