[Resolved] Filters Issues

[Author]

Posts

[Pete]

Hi there,

While I have set up filters for other pages, this is a new one and I'm having an issue I just can't crack.

This page: hidden link

Please see attachment.
Now it is returning only properties in Lake District however, select Pets > 'Yes'...nothing changes.
Same with 2 & 4 Guests. These test properties have different settings so we can test but no matter what we do, nothing changes on the grid to display what we are selecting.

Been trying different things for over an hour...any thoughts would be appreciated 🙂

Regards, Pete

[Beda]

This is strange, because over here, when I select YES for pet, I see one result (as opposed to the 2 results that it shows by default)
With Pet YES it will show Wishbone Luxury Lodge, without anything set it shows Wishbone Luxury Lodge and Kathryn’s Cottage

And when I select NO, It shows Kathryn’s Cottage, instead of Wishbone Luxury Lodge

So for me it seems to work fine.

Do I miss a step?

[Pete]

Hey Beda,

Thanks for picking this up for me 🙂

Ok, to further explain. The grid in question is a duplicate of our Search Results grid here:
hidden link

This works fine using all the filters, Pets, Guests, Collections.

However on the grid we mentioned: hidden link

Pets kind of works but others not.

Try...just click on New Places. All 3 stay however Lower Orchard Cabin is not checked in the backend as new?

Now try...Dog Friendly. All stay even though Kathryn's Cottage is checked as No in the backend.

Also see Collections? In the Tax Filter (attached) we have not selected Cumbria Cottages & Lake District Cottages and yet they still show in the list on the frontend. They are not reliant as the Area is only for Lake District, this selected further down.

Sorry to fire this lot at you. Still new'ish to Toolset and it still confuses me, this our first site using it...agggghhhh.

Many thanks, Pete

[Beda]

I can't confirm this yet.

While I see that the field New Places returns all results, the Field Dog Friendly does not return the Kathryn's Cottage
As well I cannot confirm to see results of Cumbria Cottages & Lake District Cottages, but I can see that you have them in the Front End as filter, while the backend clearly states it to me a Hardwired Query, so it cannot be a Front End filter (I suspect you forgot to remove the HTML Filter for that)

Related the field New places I instead suspect the value you check is not the value saved.
Sometimes, fields save for example 1 or nothing, or 1 and 0, hence you would have to query that instead of the actual value.

Could I gain access to a staging site where this is happening so I can analyze it closer?
I can then instruct how to solve it

I have activated a private reply for you to submit the details securely.

Thanks!

[Beda]

Toolset Views has 2 types of filters.

1. Query Filters (these are basically "hardcoded", means, cannot be changed in the front end, or in other words, those are not Searches for your visitors, but rules to display content that they cannot alter)
2. Front end Filters, or HTML filters, or "Search and Pagination" as it's called in the View, those are filters that the user can edit in the front end and hence change what is displayed.

Filters of #2 will always require a #1 query filter pendant (which is usually added automatically for you when you add a Front end Search of type #2), but #1 query filter will never have a #2 Front end Filter, since those are used for hardcoding the query.

Hence, if you do not want ANY front end editable filters you can simply remove everything in the section "Search and Pagination" and just leave

[wpv-filter-start hide="false"]
[wpv-filter-controls]
[/wpv-filter-controls]
[wpv-filter-end]

If you want to remove partials, then you can remove the HTML part that renders it, as an example if you remove the below HTML

<div class="form-group">
	<label class="main-label">[wpml-string context="wpv-views"]Area[/wpml-string]</label>
	[wpv-control-post-taxonomy taxonomy="area" type="radios" url_param="wpv-area" output="legacy"  class="special-radio-class" label_class="special-label-class"]
</div>

Then the front end will not show that filer.

Since you STILL will have the QUERY filter (#1) the content in that view will still be filtered by those criteria.

Note, that if your Query filters say "of those set by the URL parameter", you will NEED a Front End filter of type #2 so you can actually update the URL parameters.
Hence, if you want a hardcoded query without user input, you would have to change that to something like "Any/All of the following" and then pick the choices you want to display.

I hope that is clear, it is a bit tricky to explain this easily, what I can offer would be a call over zoom or Skype to elaborate this better, but by today this is too late (my shift is about to end).
What about a quick call next Tuesday somewhere around this (or earlier) time?

I'm available, you'd just have to mention here in the next private reply how I can best reach you with some free VOIP or other (like Skype or so) tool

I hope above does not confuse you more than clarify 🙂

[Pete]

Hi there,

You know I thought as this is all 'self contained' there would be an issue with the fact...why is the filter from another page still in the View.

Ok, I kind of get what you are saying however if as you suggest I remove everything from front end filters, this leaves nothing in the sidebar as that filter had all the radio button info.

See here: hidden link

So now we have no filters?

A Skype call on Tuesday would be cool.
That said I will probably play around with this over the weekend. I doubt I'll crack it however Toolset is crazy and I may just give up.

Appreciate your time so far 🙂

[Beda]

Can you give me your Skype ID?
You can find me under "socialcontact" Skype ID.

I will be around Tuesday and can show you around in Views, you will not want to give up on it later 🙂

I apologize that I cannot immediately solve it now, but it will be resolved next week.

[Pete]

Hi there,

Just added you to Skype. I'm Pete at Fabulous design Co.

I will rebuild the View from scratch rather than duplicating one, this I guess I should have done first 🙂

I'll update you before Tuesday and if I can't work this out I would be grateful for you time on Skype.

No problem ref the time diff and it is the weekend after all.

Enjoy the rest of your weekend and catch up next week.

Again thank you. Pete

[Beda]

Hey Pete

Did you achieve the goal?
I am here today from now until 5,5 hours from now, please ping me on Skype if you'd like to have that short introduction to Views.

You'd need to have the website we where working on here open - I would then quickly guide you thru everything with a screen sharing.

Please let me know!

[Pete]

Good morning Beba,

Hope you had a nice weekend.

Ok, I started from scratch in building the View for this page: hidden link

It works great. The view I had duplicated had its search bar on another page and I still don't really understand why remaking this changes how this works. That said clearly it does because it works great.

The only thing that wont work is selecting what shows in the side bar.

See attached - works fine on URL given, we have selected Lake District and on these 3 properties show.
On 2 other pages we have set to Cumbria and Cartmel and they work too.

However, see Collections. Ideally I would like to exclude Places with Wifi and Quirky Places, yet these still show.
I can't see why however if this isn't achievable it's not an issue? Worth an ask.

I really appreciate your offer to talk through Views for a better understanding however, I have been working with Toolset now for over 2 months and still don't understand much of what it does. I feel it's 'so' complicated, that only continuing use will make things make sense in the long run.
Support has been great in trying to explain things, some make sense, others not. I fear you talking through things will just further add to the fact Toolset is complicated and as long as I know how to make things work....that's good enough for now 🙂
Maps are the biggest issue we had with Toolset, sorted now however they were dreadful to sort.
There are many things I still wish to add, like the Compare function, however that's for another day 🙂

If you have any simple thoughts to over come the above, excluding things in Collections, then great.

Again, appreciate your time. Thank you. Pete 🙂

[Beda]

Well, simply said it should just work.

What you outline there seems a bug, meaning something is expected to work but does not.
If you uncheck those boxes, you'd expect no post appearing that has either of them selected, BUT you might see posts that has none of them selected while having any other selected.
For example, if a post is "new places" but not "wifi" it would still appear in the produced list, only if a Post has only Wifi selected, and none of the included, it would disappear from the list.

However it's not. I'll explain below

1. You have a FRONT END Filter (search and pagination) for that taxonomy "collection":

<div class="form-group">
	<label  class="main-label">[wpml-string context="wpv-views"]Collections[/wpml-string]</label>
	[wpv-control-post-taxonomy taxonomy="collection" type="radios" url_param="wpv-collection" output="legacy"  class="special-radio-class" label_class="special-label-class"]
</div>

2. You can NOT exclude any term from front end filters. Either all or none of the used terms will appear in the front end filter
3. To have the front end filter working, you must adjust the Query filter part (change it back to how it was after generating the front end filter).
This means, you should change the Query Filter for collections to:
"Set by one URL parameter"
Only then, the front end HTML filter will work.

If on the other hand, you want to show ONLY posts that have EITHER of the terms selected / but not WIFI, then you cannot use a Front end Filter and should remove it.
Hence you would remove the HTML:

<div class="form-group">
	<label  class="main-label">[wpml-string context="wpv-views"]Collections[/wpml-string]</label>
	[wpv-control-post-taxonomy taxonomy="collection" type="radios" url_param="wpv-collection" output="legacy"  class="special-radio-class" label_class="special-label-class"]
</div>

and Use the Query filter like you do in this very moment

That however will then remove what you call the "sidebar" (the front end filter) part that says "Collections" and lists all collections as radio buttons.

It's an either or choice on this issue:
Either you let users filter in the front end by ALL terms, or you choose for them - but then you can only choose in the backend

[Pete]

Hey Beba,

Ok I kind of get what you mean.

So keeping it simple...you said:
It's an either or choice on this issue:
Either you let users filter in the front end by ALL terms, or you choose for them - but then you can only choose in the backend.

Sure but you suggest I can set in the backend what to exclude? But then not if I wish to keep all other Collections in the sidebar.

To conclude, it's either have all or none? I cannot choose in the backend and maintain the other options in Collections?

If this is the case, it's odd that I can with Area.
However I am guessing this is because I have removed the HTML so giving the user no choice in Area?

Thank you. Pete

[Beda]

Let me clarify something:
Forget about the sidebar.
What you see in that "sidebar" is a Front End search.
That search will be used by your visitors.

If you want that, you cannot have a Query Filter that uses anything else but "Set by one URL parameter"
If you do not want that, you must remove the Front End search (which you see in the sidebar) for this particular filter and can then use any other filter method in the Query filter, such as "any of" or "none of".

You cannot do that with Area either. Every filter that you add to "Search and pagination" editor WILL appear in what you see as a sidebar (the front end search).
In turn, every thing that has such a search, must have a Query filter by "Set by one URL parameter", it will only be by accident if anything of that search actually works, if you mix a Front End search with anything else but that.

Now, if you remove the Front End search (what you see in the sidebar) you can then define what users will see with a different Query Filter, such as a "in" or "not in" a certain (hard coded) list of things

I Hope this makes sense!

Rule of thumb:
- if you create Search and Pagination items (Front End search, which you see in the sidebar), the query filter is always automatically added for you and should not be changed
- if you do not create Search and pagination items (Front End search, which you see in the sidebar), then you can alter Query filters freely (and should, so you can actually restrict or as we say, query the content)

[Pete]

Ok, can I ask if you have a moment.

Can you show me what you mean on: hidden link

This is view 7615.

You have admin access still from Saturday.

Simply putting it we need a filter like we have, this defined by area as we have man of these. And then options to filter.

OR, is what I have stable and works?

If you do one for example, I can see and then change to each area.

Thank you.

[Beda]

I've altered the View so it will work as you intend.

You will now only see Posts that have Collections in one of these: New Places, Dog Friendly, Family Friendly, Just for Two, Close to a Lake, Luxury Homes, Good for Groups

However, the User (visitor) will not be able to filter by Collections in the Front end.

If you want to filter by this in the front end, you need to:
1. Delete the current Query Filter for Collections
2. Insert a new Front End Filter with "New Filter" in the "Search and Pagination" section of the View
3. Save the View

That will then allow your visitors to filter by collections, but it will NOT allow you to filter only by a "few" collections, such as we did with the current solutions.