[Resolved] Split parametric and display form useage issues

[Author]

Posts

[Bob]

Hi Beda,
Here is the new support thread you requested that I create.

In summary the issue is related to the use of a separate parametric search form only view [wpv-form-view ...] to preselect content which is ten passed as URL parameters for display and further filtering of the selected content in a display view [wpv-view ...].

An extract of the usage scenario info posted in the other support thread follows below.

Thanks,

Bob

================================

Let's take the example where I have a parametric search view based on a taxonomy plus 1 x custom field filtering.
The parametric search view passes control to a display view to manage extraction and display of the data set.

Hence the display view must only extract those posts (data set) that have the taxonomy terms and custom field values as sent to it according to URL parameters passed by the parametric search view.

In the display view, if there is no requirement to present a taxonomy filter UI, then the taxonomy filter would logically be added to the display view using the "+ Add a filter" button.
The same might apply for the custom field filter established in the parametric search view which is also not presented in the display view UI.
So again this filter can also logically be added using the "+ Add a filter" button.
These filters will be set to use the URL parameters as defined by and passed from the search view.

However, I don't need them in the form since they are not changeable by the user in the display view and thus I do not want them to have a UI.
Yet they must remain as query filters alone in order to process the URL parameters coming from the parametric search view.

Note that the Views editor will display a warning that the above query filters are not present in the form and suggest removing them which should NOT be done.
The above scenario SHOULD work without having to add the filters to the form.

So a work around would seem to be to add the taxonomy query using the "New filter" gui.
Say I do this and simply use the defaults that the filter GUI editor offers (which is type="select" etc.)
I do the same for the custom field filter and accept the defaults
Since I do not want to present either the taxonomy or custom field controls in the display view UI we must hide the [wpv-control ...] shortcodes in the display view.
Wrapping these in a "display: none;" div or whatever will achieve this.

But that isn't then end of the story.
Because no matter if you add the taxonomy form ([wpv-control ...]) and the custom field filter we will get problems in the display view with sub-filtering.

Let's continue...
OK so now complete this scenario adding sub-filtering in the display view using other custom field filters that are are associated with the data-set.
These filters will have a UI and thus would be added using the "New filter" GUI button.
Let's set them as "select" types for what are simply text fields.
We also set display "format=%%NAME%% (%%COUNT%%)", "auto_fill=wpcf-..." and an "auto_fill_default=" for the select (let's say "All").
So additional [wpv-control ...] shortcodes and query filters would be added to the display view according to the details we provided to the GUI editor.
The default query relationship is AND which is what we want.

Now we have the setup that reveals current issues with filtering...

I use my parametric search, select some taxonomy terms and hit search to pass the required data-set parameters in the URL parameters to the display view.
All looks good on the first render of the display view.
The expected data-set is found and rendered.

Next I use one of my drop downs for my sub-filtering based on the other custom field values associated with the data-set.

And this is where things go bad if we added the taxonomy [wpv-control ...] or did not.

If we added the taxonomy [wpv-control ...] the subset filtering is not what it should be.
Some of the data-set will be lost in some cases depending on which taxonomy terms were passed in.

So what's going one here???

It turns out that that taxonomy [wpv-control ...] (which when added will eliminate the Views editor warning message) is only half correct.
For this approach to work the taxonomy [wpv-control ...] MUST be set to be of type "multi-select" or "checkboxes" not "select".

Why??? It is due to the way in which the Views cache is managed which is now handled in the taxonomy rendering Walker class.
So if the Walker does not traverse the entire taxonomy (as will be the case with the "select" Walker) then things get messed up in the cache.

And the alternative scenario (if we do not add the taxonomy form [wpv-control ...] (and put up with the warning message from the Views editor) is that that things still get messed up but just in a different way.

How so???
In this second case once the display view select sub-filtering is used then filtering by taxonomy is lost (since there is no [wpv-control ...] and thus no Walker is executed for the taxonomy) and all the posts matching the display view custom field filter only will become part of the data-set of the display view.

[Beda]

1. Query Filters are added with the "+ Add filter" Button, they do not require to be added to the Filter HTML section (parametric Search)
https://toolset.com/documentation/user-guides/passing-arguments-to-views/

2. Parametric Filters added in the Filter HTML editor are automatically added to above Query filter, and if removed from the Filter HTML, they shall be removed from the above Query Filter too.

To add Query Filters (no parametric Search), again, you add them directly to the Query Section.

3. Hiding a Parametric Filter is done with the ShortCode argument [wpv-filter-start hide="true"]

4. A "search only" View does not exist.
You do approach your goal with this steps:

- Create a View, insert parametric Filters, and when you insert either the Search Widget or the View itself to a page, you choose to display only the Search form

- You will, either way, need to select a "results Page", where you have to insert the Results of this search, which is the exact same View, but this time the results only instead of the parametric Search

- If you want to "sub filter", you use a different approach, which worked in local tests, even if this is not exactly how View is designed, it is possible:

-- in your already created setup of above View which you insert once as Search, once as result, you will insert a second View to the Loop Editor (above the actual loop tags)
-- This second View is set to return all what you filter in the FIRST View by ShortCode Argument
-- This ShortCode argument (in my case a category) will listed to the Search Term you pass in the URL of the first View (in my case, wpv-category)
-- This second View holds the Additional Parametric Search
-- This will allow you to keep the parameters form the FIRST view even if you now search additionally in the SECOND view.

A summarized workflow:

1. Create View "Search Rough"
2. This holds all "rough" search (parametric) Filters and the Loop output holds what you want to present as result (post title or whatever)
3. Insert this View once as "Search form only" to a page, and the "results" to a different page (GUI will help with this)
4. Create a View "Fine Search"
5. This View holds all "fine" Parametric Searches you want, AND the Query filters for elements passed by URL from the FIRST View, but, you will set the Query Filters to listed to a ShortCode argument instead of URL parameter
6. Insert the "Fine Search" View into the "Search Rough" View above the loop and pass the ShortCode argument as in this example:

wpv-view name="fine-filters" wpvcategory="[wpv-search-term param='wpv-category']"]

Now navigate to the Search page, and perform a search (by category in my case)
This will lead to the Result Page.

There you will see the Results and the "Fine Search" View.
If you now search by "Fine", you will get the proper results (Category AND additionally fine search param terms)

I agree on the issue, that if you insert a Query Filter by URL parameter, there is a warning that this is not preset in the Filter section and that is wrong.
It must be fixed.

I will inform the DEV in this regard.

I would also like to discuss another issue, being the arguments for the wpv-control that you mentioned in the other thread.

You can you elaborate on this issue?

Thank you

[Bob]

Beda,
Please see notes below indicated as...
[Bob]===========
{comments}
==============.
Whilst I'm sure that you feel this is a simple user error problem let me assure you that I have been using Views for some time now. There were prior issues which have been annoying (like the warnings in Views editor about query filters) but the recent update to Views 1.12 broke certain aspects of how Views behaved.
The core of the issues seem to be associated with recent additions of enhanced caching which affects filtering on custom fields and taxonomy.
Adriano believes that an update of cache handling will address the custom filed sub-filtering issue he has been working on with me. This exhibits itself on my site due to the size of the database.
It was not possible to reproduce the issues in small localhost tests.

However, Adriano cannot release the revised cache code since it may break other parts of Views and thus there is more work to be done in testing before release.
He does not have an ETA for the next update release thus I cannot verify if the new code will fix multiple issues including the taxonomy issue or just the custom field issue.

Now to your remarks....

1. Query Filters are added with the "+ Add filter" Button, they do not require to be added to the Filter HTML section (parametric Search)
https://toolset.com/documentation/user-guides/passing-arguments-to-views/
[Bob] ==================
Sure I know that.
=========================

2. Parametric Filters added in the Filter HTML editor are automatically added to above Query filter, and if removed from the Filter HTML, they shall be removed from the above Query Filter too.

To add Query Filters (no parametric Search), again, you add them directly to the Query Section.
[Bob] ============
Query filters are not automatically removed just because you delete the filter html [wpv-control ...].
They are added when using "New filter" but not removed by deleting the [wpv-control]. There is no "Delete filter" button and no delete capability in the "Edit filter" UI. Thus query filters are deleted using the "delete" feature of the query filter UI.
=================

3. Hiding a Parametric Filter is done with the ShortCode argument [wpv-filter-start hide="true"]
[Bob] ================
Yes that would seem to be the obvious method. However, the hide="true" parameter causes the filter to simply return an empty string and does not execute the encapsulated shortcode (i.e do_shortcode is not called on the content).
Thus, if you use hide="true" in a taxonomy then the filter is not only hidden but it is also not executed.
From my testing and debugging this non-execution has an impact on the cache management.
Since the taxonomy Walker sub-classes are involved in cache management failing to execute the Taxonomy Walker causes issues in cache management. (see wpv-filter-embedded.php Walker_category_Checklist::__construct for further enlightenment.)
=====================

4. A "search only" View does not exist.
You do approach your goal with this steps:
[Bob] ==============
A search only view (aka form only) does exist.
The shortcode is [wpv-form-view]. You will find it in wpv.class.php starting at line 616.
This is the shortcode that is generated by the Views GUI when inserting a Form Only View.
=================

- Create a View, insert parametric Filters, and when you insert either the Search Widget or the View itself to a page, you choose to display only the Search form
[Bob]========
And this procedure will simply insert a [wpv-form-view] with a "target_id=" param.
==============

- You will, either way, need to select a "results Page", where you have to insert the Results of this search, which is the exact same View, but this time the results only instead of the parametric Search
[Bob]=======
Incorrect. The second view need not be the same view as the first view.
This is why Views passes all information through URL params so that there can be separation if required.
The Views may use different filtering (not just rough and fine of the same custom fields or just rough and fine of the taxonomy).
For instance the first view may select taxonomy and 1 custom field selection filter (let's call it CF#1).
The taxonomy and CF#1 will have filters added in HTML.
I may even have other query filtering applied in the first view which filters the data-set but has no UI.
For example I may have a query filter that selects on CPT with a certain value in a custom field.
This is an actual use case that I have on my live site where I slect only CPTs with specific custom field value.

Anyway the selection criteria from the first view (form only) will pass parameters to the second view via the URL params.
The second view takes the URL parameters passed to it from the Form Only view and applies those through query filters set to the URL param names as specified in the first view.
In other words it will have query filters set for the taxonomy and the CF#1 (and any other query only filter) based on the URL parameter names and values passed from the first View.
Taxonomy and CF#1 (and any other query only filter in the first view) are not refined in the second view.
There are no controls displayed to change the selection so there are no filters inserted into the HTML.
The second view will have it's own additional filtering for other CFs (e.g. let's call them CF#2 & CF#3).
There WILL be filters inserted into the HTML for CF#2 and CF#3

================
- If you want to "sub filter", you use a different approach, which worked in local tests, even if this is not exactly how View is designed, it is possible:

[Bob] =======================
The procedure you outline below may work but is not applicable to how I have already and wish to continue to use Views.
I have a requirement to have separate search/form view and display/render view pages.
I have a requirement to use one part of the selection process in the first View and a display sub-selection on DIFFERENT criteria in the second view.
======================================

-- in your already created setup of above View which you insert once as Search, once as result, you will insert a second View to the Loop Editor (above the actual loop tags)
-- This second View is set to return all what you filter in the FIRST View by ShortCode Argument

-- This ShortCode argument (in my case a category) will listed to the Search Term you pass in the URL of the first View (in my case, wpv-category)
-- This second View holds the Additional Parametric Search
-- This will allow you to keep the parameters form the FIRST view even if you now search additionally in the SECOND view.

A summarized workflow:

1. Create View "Search Rough"
2. This holds all "rough" search (parametric) Filters and the Loop output holds what you want to present as result (post title or whatever)
3. Insert this View once as "Search form only" to a page, and the "results" to a different page (GUI will help with this)
4. Create a View "Fine Search"
5. This View holds all "fine" Parametric Searches you want, AND the Query filters for elements passed by URL from the FIRST View, but, you will set the Query Filters to listed to a ShortCode argument instead of URL parameter
6. Insert the "Fine Search" View into the "Search Rough" View above the loop and pass the ShortCode argument as in this example:
1

wpv-view name="fine-filters" wpvcategory="[wpv-search-term param='wpv-category']"]

Now navigate to the Search page, and perform a search (by category in my case)
This will lead to the Result Page.

There you will see the Results and the "Fine Search" View.
If you now search by "Fine", you will get the proper results (Category AND additionally fine search param terms)

I agree on the issue, that if you insert a Query Filter by URL parameter, there is a warning that this is not preset in the Filter section and that is wrong.
It must be fixed.

I will inform the DEV in this regard.
[Bob] ================
At least we got that straight.
The issue is that Views counts the number of [wpv-control] appearances in the HTML and tries to match those up with the query entries.
There may not be a 1:1 relationship for the reasons I have described in great detail already above regarding incoming query filtering that has no requirement for a UI in the View.
=================================

I would also like to discuss another issue, being the arguments for the wpv-control that you mentioned in the other thread.

You can you elaborate on this issue?
[Bob] ==============
Nothing to elaborate on. I was simply highlighting that [wpv-control] does support "class=" and "style=" parameters even though the documentation does not list them and you may not have been aware of their existence.
The same goes for the "force_zero" parameter which may not be documented for certain reasons as its function is a bit "special".
However, it must have been used (or is still used) somewhere and thus really should be documented (even if listed as "deprecated - do not use" or such).
There are other issues as well.
For example [wpv-form-view ...] exists but is not documented (and it should be).
These are matters for the documentation people to address.
====================

Thank you

[Beda]

I am on it.

Sorry the immense unacceptable delay

I am discussing with DEV's and making some tests.

Thank you for the patience

[Beda]

OK, let us resume where possible.

1. Arguments like:

class="" and style="" and force_zero

I must apologize, and chapeau, you have a deep insight in Views.
DEV confirmed, this arguments exist, and are not in the GUI, DOC or intended for usage now, as they are there to support future features.
We will, at some point, add a GUI for that (style and class) but also a way to set custom structures, so you can have labels + input or input + label, for example.

So I have to apologize and (facepalm) as I did honestly not know about this.

2. wpv-form-view is not documented as a stand alone ShortCode, yes, but it is what I elaborated above, when you split a View in "Search form" and "Results"
https://toolset.com/documentation/user-guides/front-page-filters/

[wpv-form-view...] is the Search Form and[ wpv-view .... view_display="layout"] is the result of the same View.

3. If you insert a Query Filter by URL parameter, there is a warning that this is not preset in the Filter section and that is wrong.

I am discussing this.
See, after some more tests I think, it is a (surely not intuitive) side effect of the Fact that the Parametric Search is a URL parameter, and if you set the Query Filter to filter by a URL parameter and in the same time this View has also a Parametric Search, the error is displayed.

In fact it is not, if you ONLY display the "All Results" and do insert a URL parameter Query Filter.
This is only happening ( the error) when "Parametric Search" section is visible in the View (Full Custom Mode as example)

As said, I am requesting some improvements here, as it is very valid argument to filter by URL as Query AND by parametric Search for 2 different Items in the same View.

4. The procedure you outline below may work but is not applicable to how I have already and wish to continue to use Views.
I have a requirement to have separate search/form view and display/render view pages.
I have a requirement to use one part of the selection process in the first View and a display sub-selection on DIFFERENT criteria in the second view.

I can not wrap my head around your setup, I am sorry.

My suggestion is how it is to do, a View Search and its's (same views) results are either to present on the same page, or separated as illustrated.
Nested / fine grain search is not something that is supported out of the box but works with this approach.

My suggestions does use parameters in first view, other parameters in second view.

So I do not see where it lacks the features you need, and request a Module package to see what you are doing.

I need a Module (You can use the Module Manager for this) that includes the Post Types, Views and Content Templates you use.

I will then according your description that you would attach, create some dummy content and see how this is implemented to eventually suggest other approaches or raise to DEV in case I find issues

It is the fastest approach, instead of talking long time here explaining how you set up things, we can simply see this with a Module

Do you agree to this?
The reply is private where you can share a Google Drive Link to the Modules you will export.
Please if possible attach Text File with a description for me

5. - You will, either way, need to select a "results Page", where you have to insert the Results of this search, which is the exact same View, but this time the results only instead of the parametric Search
[Bob]=======
Incorrect. The second view need not be the same view as the first view.

I never said something else.
It is the same view, firstly your display SEARCH and then RESULTS.

Your can of course display another (just as I suggest) View that grabs URL parameters, which are passed from the First View.
This is exactly what I suggest, just that I do still include the result of the First View (layout)

Of course you can simply create another view, set the Query to grab Url parameters and then it's the same.
But to KEEP the URL parameters AFTER you perform a new parametric Search on the NEW (second) View, you need to grab those with the suggested above approach (wpv-view name="fine-filters" wpvcategory="[wpv-search-term param='wpv-category']"]) as otherwise the URL parameters get "cleaned" on the first parametric search submit of the second View.

Do we speak of the same here?

Otherwise a Module of this situation would help greatly to see the setup and improve where there is room for, and suggest elsewhere.

Thank you very much for your patience and understanding.

And I apologize that situation of the arguments, really my bad and un-knowledge

Thank you

[Beda]

OK; now I understand this your setup

It is actually not different then what i suggested, as far I see, unless the AJAX updates and that you cut out the Layout of the View in the First View.

Now, to close or summarize this, the problem you have is with the second View, where you have the "hidden" (getting value from first View) Searches such as the

[wpv-control taxonomy="element-tag" url_param="wpvelement-tag" type="select" hide_empty="true"]

If you remove that from the HTML Filter Editor, it will ask you to remove it as well from the Query section.
Is this correct?

Since we deal with the specific form of URL parameter Filter, Views automatically expects that you set this in a HTML (parametric) Filter and throws that error once you remove it from there.

The only way this will not happen, is when you actually do only display ALL RESULTS (not parametric Search)

This because then Views does of course not expect a Parametric Search Code.

Now, I am aware of what you mean, but I am not sure how we should solve this to provide a all over working solution.

If we do not check the equivalent of the Parametric Search in the Query Filter, it would mean, in a "normal" view, users could delete the Parametric Search and forget the Query Filter, and get unexpected results, even if the Parametric Search actually was removed.

This warning is there to help to have a "clean" filter.

If we remove it, this "helper" is not there anymore.

But we can not know, how you use the View.
I mean, we can not detect if you actually use the View as you do, or as a "usual" parametric Search (URL param)

If I finally got it, can you confirm I understood the issue (I definitely understood the raffinate setup you use), then I can forward this to the DEV for analyzation.

We might come up with some additional setting, or fully dump the warning / check, but I assume this would not be the most user friendly (and working) solution.

Once you confirm, I will escalate and we will see how it proceeds.

Thank you for your patience and insight.

[Bob]

OK. Glad that the access to the dev site helped.
===========
Please send me a private message and I'll give you access to another demo site which will demonstrate further use of filtering that I have been working on.
=============
As we agreed there are issues with filter warnings etc.
However, my take on this is that Views did work in the split mode before and has wandered a little off track.
I see quite a few people in the support forum who have had issues with taxonomy filters not working after V1.12 upgrade and have to delete and re-add via the GUI to make filters work again.

My thinking is it is a good discipline for Toolset to ensure that everything will work through the split mode scenario (passing via URL params).
That way there can't be any remnant data lying around between parametric and display phases.
I'm not sure if the Toolset test plans include such a configuration?

Anyway bottom line is query filters by themselves without a [wpv-control ...] should not be treated as anomalous.
If erroneius use is of concern then when a query is added then the GUI could simply show a temporary message about "there is no matching filter - we assume you know what you are doing..."

Thanks,

Bob

[Beda]

I re-enabled a Private message

Meanwhile I have been informed that in the upcoming Views version, a underlying BUG has been found and solved.
It's about this issue.
Editing/ Adding / Deleting Filters, specifically in taxonomies, did have unexpected results, as because data was not "flushed" correctly, so probably those Taxonomy Filters that needed to be re-added, where broken due some edits in the Taxonomy Term or Filter, and not correctly flushed, causing the issue.

Anyway, we have now narrowed this down to that issue with the warning in the case of URL parameter filters as mentioned and confirmed by you above.

I will report this.

Let's now first see your other site, so we can be sure I am reporting the correct things, and have a brighter overview of all the cases.

I assure you we will take this seriously, but I can already say, it will not be solved or changed in the upcoming Views Version because this is to happen this week, and already in QA-

I apologize the delay on this.

Thank you

[Beda]

Thank you

I am analyzing this and also informing the DEV in regard

As said we are in a major QA for the next release and don't have time right now to dig in this deeply but will consider everything after release.

Please expect my infos here in the Forum

Thank you very much for your collaboration on this.

[Bob]

Thanks Beda.
Having been in the software development world for way too many years I totally understand you guys are on a release cycle and need to get the next revision out.
I also appreciate you have plenty of support tasks from users calling for your assistance.
So in between your busy day I appreciate the consideration by Toolset team of improvements to Views such as the one I have prototyped.

I've gone down the path of Toolset in the belief that it is a good solution.
If the various cache issues can be resolved I will ramp up my use such that the data-set I deploy through Views that will grow by thousands of records/CPTs each month.
Right now I have a large backlog to my image library expansion on hold pending the resolution.

Please keep me advised of developments.

Regards,

Bob

[Beda]

I thank you for your patience and understanding.

I am escalating the issues one by one.

I thank you for the patience, we will work on this issues ASAP.

Thank you

[Beda]

With the new feature of WordPress Archives now also being able to hold Parametric Searches, we do now keep manually added ?foo=bar in the URL parameters.

Still, the warning is present when you add Query Filters by URL parameter, but do not add them as parametric Search.

I will close this ticket as the major issue is solved and only the GUI issue remains.

If detailed other issues appear, please don't hesitate to open a new specific ticket.