Skip Navigation

[Resolved] Query Filters acquisitie opportuniteiten professionele kopers

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

This topic contains 12 replies, has 4 voices.

Last updated by Waqar 7 months, 1 week ago.

Assigned support staff: Waqar.

Author
Posts
#2185679

Refer this ticket to Waqar or Nigel.

This is the page: hidden link

What Query Filters should we add specifically to limit the properties to only these required statuses:

- "status" "te koop" OR "binnenkort te koop" OR "verkoopintentie" OR "open voor een bod" WITH a development index equal or higher then 70.
OR
- "verkoopstatus" "te koop" OR "binnenkort te koop" OR "verkoopintentie" OR "open voor een bod" WITH a development index equal or higher then 70.
OR
- "status" "in review" WITH a development index equal or higher then 70.
OR
- "verkoopstatus" "in review" WITH a development index equal or higher then 70.

We won't add any search or ordering filters so the performance should be perfect.

#2186547

Waqar
Supporter

Languages: English (English )

Timezone: Asia/Karachi (GMT+05:00)

Hi,

Thank you for contacting us and I'd be happy to assist.

The way the static/fixed query filter settings work, you can join the filters for multiple custom fields using "AND", but combining them using "OR" is not supported. Also, in query filter settings, you can include a single custom field's filter only once and it can't be repeated.

For example, I've created a test page and view to show query filter settings at:
{yourwebsite.com}/wp-admin/post.php?post=157820&action=edit

Please note, how I've added the query filter for the "status" field so that it can check if the value is equal to specific numbers ( screenshot: hidden link ) and the "Development index" is a number greater than or equal to '70'.
( screenshot: hidden link )

This view's query filter, satisfies your first status statement and for others, you can create separate views as it won't be possible to incorporate them all in one.

regards,
Waqar

#2186641

Waqar,

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

2.
How can we delete the "filter based on the frontend search filter by Search index?"

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"?

#2186651

If we visit hidden link, no eigendommen are found.

#2186849

Also we get results where the development index is below 70.

#2187487

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

Can you handle this ticket with priority please.

#2187609

Waqar
Supporter

Languages: English (English )

Timezone: Asia/Karachi (GMT+05:00)

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.

#2187677

Waqar

I am SO fed up with this performance issue, to be honest.

We did everything we could to find a way to work around this CRUCIAL issue:

- Front-end filters
- Query filters
- WPSOLR
- ElasticSearch

But apparently there is just NO way to get around it.

This leads to a SUPER slow website, which has a MAJOR impact on both SEO, clients and business.

I asked Nigel in what other way (than using front-end filters) we could work around the performance issue for the search pages.

He said we could by using the static "query filter" settings in the view's editor. Now that we changed everything and spent days on it again the performance issue didn't go away, even more, it got WORSE.

You should urgently come up with a solution that DRASTICALLY improves the performance for search pages because now it is just DRAMATIC.

It IMPACTS us A LOT.

#2187909

Amit Kvint
Supporter

Hi Matthias,

My name is Amit and I am the support manager here at OnTheGoSystems.

Nigel had brought my attention to the performance issue you are experiencing with the site, after discussing with Nigel and looking at the scores of tickets we have helped you with, we decided to consult our lead developer and see if there's any viable way to help you achieve a fast searchable solution for your site, which contains about 150k properties.

I am afraid I have some bad news, it seems that we have reached the limit with what can be done using only WordPress and plugins (as powerful as they can be). In general, WordPress is a very good solution for most problems, and Toolset is a fantastic tool to enhance what WordPress can do, but for a very niche application, which needs to store lots of data per entry and needs to have possibly hundreds of thousands of entries, and also needs to be able to search efficiently among all that mountain of data, you do need a custom solution.

Toolset was not built to support that kind of niche web application, and WordPress itself has its limits when used purely like that. Specialist tools such as WPSolr can help with fairly vanilla implementations where the problem is just one of scale, but your project mixes searching across standard WordPress database tables (which WPSolr can handle) and searching across custom Toolset tables (which it cannot). The WPSolr integration isn't made by us and isn't something we can "fix", and I'm not sure it is amenable to working with custom database tables in this way.

Such a big project, whether you are developing it for a client or for yourself, needs more than just a powerful and fast server. Web performance on a site of that scale needs to be planned for at the outset and likely requires a bespoke solution designed by engineers with expertise in scalability, it is not something that general-purpose tools are expected to be adequate for.

I am sorry, I understand that is a hard bottom line to accept, but you have hit a wall with Toolset simply because it was not designed to achieve what you are trying to achieve. In support, we are not able to help you anymore with improving the performance results, as we have run out of suggestions for what else can be done in this context.

Thanks!

#2188477

Waqar
Supporter

Languages: English (English )

Timezone: Asia/Karachi (GMT+05:00)

{ticket status updated}

#2188565

Amit,

Very painful to hear after one year of development.

Why don't you communicate these restrictions openly, we could have picked a different approach from the start. I guess a lot of Toolset users are experiencing the same performance issues.

I am quite confused that you run out of options to suggest as Waqar told that you are working on an integration of ElasticSearch for views which would drastically increase the search.

Please update on this one with an ETA.

#2189531

Nigel
Supporter

Languages: English (English ) Spanish (Español )

Timezone: Europe/London (GMT+01:00)

As Amit explained we have run out of options in terms of trying to improve the performance of the site as it is currently configured. Waqar said that we have an internal ticket about working with ElasticSearch, but it is not under active development and so no ETA can be given: it may be picked up again in the future, it may not.

I'm really sorry that we can't do anything more for you regarding performance. I don't believe the discussions asking about how to set up the site mentioned the eventual scale of the site, which would have raised a red flag about these issues which have become apparent since importing all of the data.

#2189537

Waqar
Supporter

Languages: English (English )

Timezone: Asia/Karachi (GMT+05:00)

{ticket status updated}