[Resolved] Fitlering Search Results (WordPress Archive) with Relevanssi activated

[Author]

Posts

[Thomas AMX]

Hi guys,

I am trying to filter search results of the standard WordPress search.

Without Relevanssi, the filtering part works just fine, but the relevancy of the delivered items is embarrassingly poor.

After setting up Relevanssi I get the perfect order of results, but the filtering starts to act very weird.
I tried filtering by a custom taxonomy and also by a custom field. I need just 1 filter - "content type".

As far as I can tell, using a custom field is a little "better", because with taxonomies terms were randomly missing in some posts. They were inside the posts, but Toolset filter didn't see some of them. I spent half a day testing different settings.

With a custom field, at least I kind of understood what was going wrong. I did this:

 label.wpv-parametric-disabled {color: #aaa}	 

So, let's say, I have the following 'content types': "places", "books", "products" etc. They are actually multiple post types, but to make it simpler I set up a custom field for the purpose of filtering.

Then, if the 1st "book" in the loop is on page 2 of the results or later, that checkbox is not clickable and the label changes color because of the CSS. If I click on any available checkbox, AJAX updates the list and afterwards the "books" checkbox will become clickable, because it already knows that there are some "books" later on. After I refresh the page, it forgets about the "books", and the checkbox is no longer clickable.

This behaviour takes place only with Relevanssi activated. Without Relavanssi, all checkboxes are available even for content types that appear first on subsequent pages.

Is this a bug or am I missing some setting?

I don't know if it's related, but without Relevanssi I can select multiple checkboxes to filter at once.
With Relevanssi, after I check 1 checkbox, all the other ones become "disabled".

How can I filter the search results with Relevanssi on? Custom tax or custom field, I'll take anything....

Best regards
Tom

[Nigel]

Hi Tom

I'll need to set up a test site to try and reproduce what you are describing.

Before I do, though, can I check something?

I am guessing that your Views filters are set to update whenever and filter is changed so that only available options are shown.

It seems like choosing to always show all values for inputs would fix this.

Is that an option for you?

Relevanssi uses a custom query to use its search index. If you have the setting to only display available options then Views makes an ajax query which it uses to update the available filter options.

I suspect what is happening is that ajax query is not tied to the custom Relevanssi query, although, as I say, I would need to set up a test site to verify this. If that were to be the case, the developers may state that updating the filters and using Relevanssi are not compatible with each other, and it would need a feature request to implement it.

I'm just speculating here. How I proceed depends on whether you are happy to use the setting to always show all values for inputs.

[Thomas AMX]

Hello Nigel,

Yes, showing all values for inputs does force all checkboxes to appear, but I would not consider that to be a good option.
The purpose of filtering the search results would be narrowing the search results, or as some sites call it: "search within the results".

But forcing all checkboxes to appear suggests to visitors clicking on unavailable options and then the outcome is "no results found". Which is a little embarrassing if we are already searching within the results.

If we could at least show a "0" next to the label, or change the font color of empty options, that would make sense, but I guess that is not possible currently? If I show all options, I don't see any extra CSS selectors for empty options.

But perhaps that could be a kind of a workaround if there is no communication between Toolset filters and Relevanssi:
1. forcing to show all option values
2. somehow magically add a CSS selector to empty options in advance, perhaps some 'data-id-something' or whatever
3. doing {display: none} to hide the empty options

What I find interesting though, is that performing an AJAX filtering event somehow 'informs' the Toolset/Relevanssi duet that there are other options on the next pages and it will "remember" it until a page reload.

For example:

Let's say, initially the following options are shown: "books" "places" "people". The option "pages" does not show up although it should.
I select "books" and then unselect it. And then somehow the option "pages" is discovered and will stay there until a page reload.

So, perhaps it would be possible to produce a "dummy" AJAX event on initial page load so that the "invisible" options are discovered when the page is loaded?

Cheers
Tom

[Nigel]

Hi Tom

When I come to test this I can't see the issue you describe.

See my screen recording.

I have a projects post type with a status taxonomy.

On the initial page load there are a number of checkboxes not being displayed at all because no posts have the term assigned (I am using the default setting of hiding rather than disabling irrelevant checkboxes to make it clearer to see; I found the same behaviour in each case).

Normally clicking on extra terms expands the results (because the default setting of the Query Filter is to match ANY of the checked options), so I changed the setting to say that ALL terms must match, meaning we narrow down the results.

As you can see on the initial page load checkboxes are included for statuses that are not assigned to posts that appear on the first page of results and which appear only on subsequent pages of results, and when checking checkboxes, the available checkboxes update correctly to match the results.

On your site make sure that you have set up indexing correctly in the Relevanssi settings, because I cannot see the problems you describe.

[Thomas AMX]

Nigel, have you set up a View titled 'Relevant Projects'?

My issue is only with the WordPress Archive assigned to display the standard Search Results (as in a standard WordPress search box). My Views are not affected at all by Relevanssi. Views are fine.

I'm talking only about the standard search results page, where the order of results is taken over by Relevanssi.

Each post on my site can have only 1 option value for this filter (I tried a custom field and a custom tax).
Normally, if I filter only within a single taxonomy or field, all the possible checkboxes should stay visible (the relationship should be OR).

And it works exactly like this in Search Results with Relevanssi deactivated. Activating Relevanssi means I can select only 1 checkbox and the other ones disappear until I deselect the first one. ( AND/OR setting in Relevanssi should not matter, because it's for the initial search results from the index, and it doesn't make a difference anyway).

And of course the options from the next pages are not visible until an AJAX event. I tested two sites. I built the index multiple times. I will also set up a fresh and clean site to do one more test.

Cheers,
Tom

[Nigel]

Hi Tom

I just updated my site to use a custom archive for the search archive and I got the same results, it worked as I expected it to.

If your posts can only have a single taxonomy term assigned then it would be expected that when using the ALL terms must match setting that once you have checked one term filter then all the others would be disabled, because there cannot be a match of the first filter plus a second one.

If your setting is that ANY of the terms should match then the available checkboxes would be those for terms which have a post—any post—assigned, and these would not change no matter what checkboxes you checked or which page of results you navigated to.

The one gotcha I see in this is that your theme may be adding pagination controls but these are not the pagination controls you should be using, you need to insert pagination controls in the Search and Pagination section of the custom archive, and you should disable (or hide with CSS) any pagination controls that the theme adds, as these will not correspond to the filtered results of the custom archive.

Might that be the problem?

[Thomas AMX]

Yes, Nigel, I know that Toolset Filters in Archives need wpv-pagination. I use Toolset's pagination.

I have just saved the checkbox value in about 70 posts of several types.
And it's worse than I had thought. In some searches some checkbox options are missing even though posts with them are present on the first page. The same checkbox can appear in other searches with no problems. So, custom field is not really better than custom tax. Deactivating Relevanssi instantly fixes it.

"If your posts can only have a single taxonomy term assigned then it would be expected that when using the ALL terms must match setting that once you have checked one term filter then all the others would be disabled, because there cannot be a match of the first filter plus a second one."

The thing is, it works perfectly without Relevanssi. Activating Relevanssi destroys it.

Right now, in Query Filter I have "The field Content Category is a boolean that is IN the following: URL parameter wpv-wpcf-content-category.

I tried many things, I don't know which settings are correct. These ones work perfectly fine without Relevanssi.

Relevanssi doesn't index checkbox fields, so I don't know what else I can change in the settings.

Perhaps your sample is simply too small to reveal the issue?
I will test in on a fresh site. Can I send you a Duplicator or All-In-One-Migration package (or a link to download it)?

Or I can send you a private link to search results with Relevanssi activated.

[Nigel]

Hi Tom

I've only been testing with a taxonomy, not with custom fields, and I expect because of how checkboxes fields are saved in the database (as serialized arrays) it is not something that Relevanssi would be able to index.

Do please share a link to a backup, either All in One WP Migration or Duplicator packages are fine.

I'll set a private reply for that.

[Nigel]

Hi Tom

Sorry for the delay getting back to you, I've been very busy in support.

I have downloaded the copy of your site and successfully installed it locally, so I will look at it first thing in the morning and should be able to see the issue as you describe it.

[Thomas AMX]

That's great Nigel.

I've received a Sucuri alert to my email that user "tss***" is doing something on my site 127.0.0.1
It scared me at first, checked my sites for such a user, but after a moment I realized that it must have been you...
'tss***' is your username, right? ?

Cheers,
Tom

[Nigel]

Hi Tom

Yes, that would have been me.

I was able to confirm the issue you describe, which affects archives, but doesn't affect a similar View with text search and taxonomy filters added to a static page.

There was one oddity which was even without Relevanssi the results on page 2 seemed to be broken, not showing any checkboxes at all, though they were otherwise okay on different pages of results.

I passed a copy of your site with all of my findings to my colleagues to see if they can actually track down why this is happening.

I'll keep you posted.

[Thomas AMX]

Hello Nigel,

Is there any progress with this one?

I have the impression that custom taxonomies behave even more weirdly than custom fields on search results pages.

Cheers,
Tom

[Nigel]

Hi Tom

No progress yet, I'm afraid.

The issue has been escalated to the Views project, but I don't see any work on it yet.

We have a couple of major development projects which are nearing completion that are occupying most of the developers' time, and I expect a renewed focus on fixing issues such as this once these are released.

I'll be notified whenever there is progress and I'll let you know.

[Nigel]

Hi Tom

We published an update to Views yesterday which should fix this issue, if you could please update and verify.

(Note, you need to apply all available updates to Toolset plugins, not just Views.)

[Nigel]

Sorry, Tom, I spoke too soon.

Looking at the internal ticket the fix has been added to Views 2.9.1, it didn't make it into yesterday's release, and should be out next week probably.