I figured out how to nest the Views thanks so much for letting me know it must be done in classic editor, though I'm still having an issue with the search bar. I am trying to add a filter for data from the nested CPT in the view, but when I add the filter to the search bar, no results are being displayed when I test it. Do you know if there's something to toggle on in order for the search bar to pick up on displayed the nested views?
Thank You!
Hi,
Although, I have access to your website's admin area, for some reason I'm still not able to access the page editor screens, in the admin area properly.
Can you please share the link to the page and the details about the search filter that is not working?
I'll also need your permission to download a clone/snapshot of your website, so that I can investigate this on a different server.
regards,
Waqar
Hi,
I disabled the SG Security plugin which is the only security plugin I have, so double check and see if you can access now. If it still doesn't work, you have permission to clone or do whatever it is to help with my issue.
The link to the post with the nested view is this: hidden link
I believe my issue is a simple toggle/control somewhere I just can't seem to find it and have spent a lot of time searching. I would just like the search filter to include a front end filter option that will filter the views loop by the nested view. (For example, the single line text called "Maggid Shiurs Last Name", to enable visitors to filter by someones last name, which is currently nested).
Thanks!
Thank you for waiting.
I was able to see how the page is set up, by using your website's clone on my test server.
On the page, the main view "Shiur Directory" is set to show the "Shiur Locations" posts and the nested view "Shiurim View", is showing the "Shiurim" posts.
The example single line field "Maggid Shiurs Last Name" that you pointed out, is attached to the "Shiurim" post type and not to the "Shiur Locations" post type.
An important point to note is that the search filters in a view can only be used for the custom fields and the taxonomies, which are directly attached to the post type that is being shown through the view. The custom fields and taxonomies from the related post type can't be used for the search filters.
To overcome this, you can follow these workarounds:
1. On your page, you can create two separate and independent views with search filters. One for searching through the "Shiur Locations" post type and its search filters and the other for the "Shiurim" post type and its search filters. This way, the visitors will have the ability to use the desired search form, to view the shortlisted results.
OR
2. If you'd like to add a common search form that can show results from multiple post types, then, you'll have to make sure that all fields which need to be used for the front-end search filters, are saved with all the participating post types too.
Thanks for your response, and I understand being so busy I just wanted to know if I should always expect longer response times..
For workaround #1, is there a way to design the search on the frontend so that users won't see them as two separate entities? Meaning I don't mind doing that, I just want to ensure that it looks simple and easy, like one big group of search filters for visitors trying to find information.
For #2 which does seem like the more viable solution, you mean to say that similar to the "address" slug we discussed in the other thread, I will have to create another independent group of fields that I can stick into both CPT's and will cross reference each other, correct? If I do it this way, will there be duplicates being created each time? And will the frontend search for visitors only show the information once? Sorry I am a bit confused, I haven't used this kind of field groups across CPT's yet. I want to make sure there won't be any redundancy, both in the database and for the frontend search.
Thank You!
Thanks for writing back.
Workaround #1: Actually the two search forms should show as separate entities, because technically they'll be working separately and independently.
If you'll try to present the search filters from two separate views as one, then that will become confusing for the visitors, because they would expect the results to show based on their selection criteria as a whole across all fields, which won't be happening.
What you can do is split the page into two columns, using the grid block and add the two views with their own search form and results, in each column, as shown in the attached screenshot.
This way it will be clear for the visitors that they can either search by the search fields in view 1 or the search fields in view 2, independently, but not all fields togather.
Workaround #2: Your observation is correct and data duplicates and redundancy will be a big challenge in this approach, so personally I would not prefer it over "workaround #1".
Thanks for the response.
I am thinking, is there possibly a third workaround - where I add the "Shiurim" CPT to the main Shiur Directory View so that there are now the Shiurim & the Shiur Locations CPT's both linked to it, and if I can "filter out" displaying all of the fields from the Shiurim CPT, and just have it for this reason so that I can include in the search field this field of "Maggid Shiur's Last Name"?
If yes, how would I go about configuring this?
Thanks!
I'm afraid, this won't work.
It is correct that by including both CPTs in the view's content selection, you'll be able to add the search filter for the "Maggid Shiur's Last Name" field.
But, because this field is attached with the "Shiurim" CPT and not to the "Shiur Locations" CPT, as soon as you'll perform a search based on this field, all the posts from both these CPTs where this field has no value will automatically be excluded by the view. This means that all "Shiur Locations" CPT posts will be excluded, because none of them will have any value for this field.
It seems like I will need some custom development to get this to work the way I need (join the 2, and have 1 grouped search).
Thanks for the 2 workaround options, but I don't think either will be a viable solution for me
