[Closed] Search Results

[Author]

Posts

[jww]

Hi,
I have a view with Search Filters which display on a map.
The dataset has 20,000 items.
1. If you do a simple name search, it's realllllly slow to give results. My server is pretty fast and not overloaded. I'm not on shared hosting.
Is there any obvious way to speed it up?
2. If you put in the name with one letter wrong, it doesn't find it. Is there any way to control how much fuzzy logic there is for the search terms?

Thanks

[jww]

I have the Search By Name block twice, two different ways.
I don't understand the difference between the two.
One is Text Input then > compare value as a string > using this comparison "like" .
The other is Text Search Title and Content.

If want them to be able to misspell the word by a few characters, I would think the first one with "like" would have done it but it gives no result if you are off by one letter.

Is the first version giving you more control over the search results than the second one? Can you explain
1. When to use one over the other
2. How to let the user be off by a few letters but still get results
3. Give them the option for "exact match" or "close results" - let them choose?

Thanks

[Nigel]

Hi there

regarding the different search options you highlight.

One of them is for text searches of the post title and (optionally) the post content.

The other is a search filter for one of your custom fields (Airport Name).

So the two filters are searching different content.

The text search automatically uses the "LIKE" comparison.

The custom field filter lets you choose between "=" or "LIKE", which are similar but different.

Equals must be an exact match.

LIKE can be a partial match and is case insensitive, e.g. you could search "route" and it would find "Router".

Fuzzy-matching is something else altogether (maybe it would find "Router" when you searched for "rooter"), and isn't something that is available with normal WordPress queries (which Toolset is built upon).

You could try Relevanssi, though, which does include support for fuzzy matching.

And you can also use it to combine searching post titles and content with searching custom fields, too, in a single search box.

See here for more information about integrating Relevanssi with your Views searches: https://toolset.com/course-lesson/searching-texts-in-custom-fields-with-toolset-and-relevanssi/

As for the issue of speed, if your search is based on the custom field (Airport Name) then that may account for the issue. Querying posts filtered by post meta is notoriously slow, and a "good" server won't be as good as you think it is in that scenario.

So if your posts have the airport name in the post title or post content that would be a good reason to use that text search instead of filtering by the custom field.

You might find Relevanssi helps because it uses its own indexes, so I would try that.

Otherwise you could try the plugin Index WP MySQL for Speed to improve on the default table indexes that should improve filtering by post meta.

[jww]

Nigel,

I really really appreciate the level of your responses. You give me enough information to understand it. Thank you.

I do have Relevansi, so I'll look at how to integrate, thank you.

I think I misused the term fuzzy match. I was assuming "like" would do exactly what you said, case insensitive and a few letters off ok, but then why if I have it set to like does it not find Austen when Im looking for Austin? It gives me no results. And is absolutely painfully slow. It is just as slow in the text search for title/title field, and if I put in that same mispelling, it won't find it.

I thought one of Toolsets big selling points was this filtering of custom fields on maps (ie, real estate sites etc.) but being this slow on a simple search seems un-workable. I'll try the Relevanssi path but I am disheartened to see I have to go that path and that just using Toolset to do what the sales docs say it can do with custom filters is not a good user experience on a simple search.

I'll check out that plugin you mentioned.

Thanks

[jww]

I'm still stuck on this.
I have a text input search filter set to string and like, but if I type it in one letter off, it doesn't find results. If I make it a perfect match it does. How do I get it to do what you said with the Like option?

Also do you know with the same type of view and search, I have another custom post type, news items, using wp rss aggregator. Toolset views don't seem to see all of their fields, some yes but not feed name nor date published (it shows them as numbers rather than words). However, I see some Toolset documentation about it working well with WP RSS Aggregator. Can you help?

Secreenshot attached of my Like text input search settings which don't give me results with one letter off...

[jww]

Also while the results are loading, which again is painfully slow, I get this big blue box. The spinner I chose in the settings (one of the defaults) is there, but there is also a blue box behind it which doesn't look good. I tried adding a custom spinner but it didn't work. Why is this blue box showing up while it chugs through results??

[jww]

This search page was looking somewhat ok and it just went all horribly wrong. I have no idea what broke it. Good thing it's in development and not live.

I indexed with Relevanssi.
I changed a field from single line to address because the distance search wasn't working because the address field was single line not address. As soon as I did those two things, the entire page has broken.

Can you take a look? Now it says "view not found". But you can see it on the front end. You can still search. Something went totally wonky and I can't get it back. I even restored it to two hours before that happened and it still says view not found in a pink box.

I tried adding the view again below the broken one, but it doesn't show the text search input box. Something went really wrong and I just can't see what?

Can you please send a private reply box and take a look? I'm up against a deadline.

[Nigel]

Let me first clarify, if you want searches for "Austen" to find "Austin" posts then that is fuzzy logic.

Using "LIKE" would find "New York" if you searched for "York", whereas equals would not find it (because they are not equal).

On the question of performance, the problems arising from filtering posts by custom fields is a WordPress limitation rather than a Toolset limitation: hidden link

As I mentioned before, it might improve with Relevanssi because it constructs its own database indexes.

And you can try the Index WP MYSQL for Speed plugin to create new indexes for the wp_postmeta table to speed up such queries.

Having said that, let me set a private reply to get credentials from you to see if we can see what's going wrong at the moment.

[jww]

Also please notice the weird blue box when it's searching.

[Nigel]

I can see the problem with that page where the View is reported as missing etc., but I can't account for why it would have happened, and—more importantly—I can't see how to fix it. I tried something I thought might work, but it didn't, and I don't have any other ideas. (With the switch to Gutenberg the WordPress editor has become very complex to debug.)

If you are not able to revert to a working version from a backup then I don't have any other suggestion that to delete (not just trash) the current search page and start over.

Also go to Toolset > Views and delete the View in question (Airports, with ID of 1125), as well as the extra View you added to the same page.

Start again with a new search page and a new View and new Map. Take a backup in case you need to revert to this point again.

As for the custom fields, for the map to work, or even without a map, to be able to search for posts by distance, you must have an address field (by which I mean a field of the type address, not some text field called address).

When you use Relevanssi you can combine filters. So you can have a text search as well as apply some other taxonomy or custom field filters at the same time. But! The distance filter is a special case that requires special handling internally, and I can't say for sure without trying whether the distance filter and Relevanssi-based text search will work properly together. I will try on a test site to see if I can confirm it should work.

One thing to clarify with adding Relevanssi: it only applies to text searches, even when you use it to include support for searching custom field values.

So it doesn't necessarily make sense to add all custom fields to the Relevanssi index. It only makes sense to add custom fields whose values you want to be found in text searches.

Say you had a custom field for, I don't know, height about sea level, in feet. It could be that you wanted to include a filter for height above sea level in your View, so that users could say to only show results above 5000 feet. But you almost certainly wouldn't expect users to enter a text search to find the text "5000" from the field.

And if you were to add this field to the Relevanssi index then you would just be clogging up (and slowing down) the Relevanssi index.

I'll report back on what my test shows about trying to combine Relevanssi text search and distance filtering.

[Nigel]

I did that, and unfortunately these two special cases don't play well together.

You can't combine Relevanssi (for fuzzy matching) and distance searches.

If you do then Relevanssi takes control of the query and the distance filter is ignored (so it will show results from outside the specified radius).

And while checking this I realise I've given you slightly mixed messages around using Relevanssi to improve the performance of searches involving custom fields. Yes, that might help for text searches where you want custom field values to be included in the searchable text. But that is separate to the issue of filtering by custom field values (e.g. my example of filtering by height above sea level in my last reply).

When filtering by custom fields on a large site I would recommend trying the mentioned Index WP MySQL for Speed plugin, while another thing you can do is wherever it makes sense use taxonomies rather than custom fields (taxonomy tables are optimised for such filtering).

That won't always be possible. Height above sea level makes no sense as a taxonomy. But, say you had a "priority" field with values of "low", "medium", and "high". You might implement that as a custom field, but if you intend to filter content by priority then it would be much better if "priority" were a taxonomy instead.

When you have rebuilt the page and I can edit the View if needed I'll take a look at the blue background for the waiting spinner.

[jww]

Also I know that the address field has to be an actual address field. That's what I was saying. I was told by your team that Toolset won't import into an address field, which seems ridiculous, and that the only workaround was to make it a single line field, import into it, then change it to an address field, which is what I did. I don't know if that is what broke it or what did.

[jww]

Also I can't revert to a backup without losing a full day of work. I can't do it. The one back up I could have gotten to was just about an hour after that page broke.

I'm really worried about using Toolset on a production site if something like that could have happened live on a major page of the site and we can't figure out why or how to avoid it.

[jww]

And...now on another page, in our other thread about views with Aggregator, all of my custom search block filters don't work anymore and say "this block has encountered a problem". I mean I can't keep deleting big chunks of content and pages and starting over. What if this was live? Not to mention the massive production slow down that keeps happening trying to make things work that don't. My frustration level is high and my deadline is way past.

[jww]

I trashed that page and emptied the trash.
I deleted the view from Toolset views and the second one.
I created a new page.
I tried to re-add the view but the map is still looking for the custom field "airport_address". It doesn't give me any other choices and I had deleted that field and opted instead for a different field name thinking the first was confusing things.

So:
1. It's not seeing the new address custom field.
2. It's only showing the old one which has been deleted.

I don't know how to restore that custom field name. I tried re-creating it but it says that slug has already been used, even though I deleted it. In PHP My Admin I've tried to find it to delete it there but it doesn't find it there.

So now I don't know what to do.