Previously Waqar provided us with spectacular support with the ticket below:
https://toolset.com/forums/topic/view-to-provide-counts-of-the-number-of-times-a-field-has-specific-values/
We have what he helped us set up present here using test data:
hidden link
The page displays a parent view displaying the table, and then the child view is what creates the counts for the Number of Rides Led field.
My client has asked if we can add a date range filter to this page. NOrmally, I'd consider that no problem. But on this, I'm realizing that the date filter would apply to the parent view but not the child view. So the counts provided by the child view would not be impacted by a date range filter on the parent view, unless my logic here is wrong. There is no way that I know of to add the date range filter to the child view in a way where the filter will be present on the page displaying the parent view. So I can't think of a way to allow someone viewing this page on the front end to filter by date.
Any ideas for this? Do you understand what I'm asking?
The client would like a way to see the ride counts for each year. The only other approach I can think of would be to set a date range query filter on the child view for a one year period, then clone the view every time a new year is reached, modifying the date range to show the following year each time. Then I'd set up the main view to first show a table for one year using the first child view for the counts, then set up a second table for the second year using the cloned child view for the counts for that year. Then just repeat that process for each year. So the page would then show separate tables for each year. If nothing else, I think I'd be able to do that. But I'll see what you have to say in response to this in case you have other suggestions.
Hi,
Thank you for contacting us and I'd be happy to assist.
Technically, the date range query/search filter added into the child view should work, but there are a few points to note:
1. You'll add the date range search filter in the child view, but once it's added will move the code for the search field from the 'Search and Pagination' section in the child view to the 'Search and Pagination' section in the parent view.
This is because we don't want that search field to repeat for each result from the parent view and only want it to show once.
2. Also, make sure that that view's search settings are set to update the results without the AJAX, i.e. the page should reload, once the search is performed.
I hope this helps and let me know how it goes.
regards,
Waqar
Just to make sure I'm understanding correctly. Are you saying I should start by putting the date range search filter in the child view. Then, after that is added, copy and paste the code it generates and add that to the 'Search and Pagination' section of the parent view. And then set the search settings on the parent view to update without AJAX. Is that it?
If that's all I have to do, then I'm amazed by the simplicity there compared to what my head was saying it was going to take after watching the crazy complexity of what you showed us in building the parent and child view to get those results we were going for.
Your understanding is mostly correct, except that no search settings are needed for the parent view.
Child view:
- you'll add the date field range filter as normal and adjust the search settings so that it is not using AJAX.
Parent view:
- 'Cut' the code of the search field from the child view's 'Search and Pagination' section and paste it into the 'Search and Pagination' section of the parent view.
OK, thanks for the clarification. If this works, this is definitely FAR easier than I was fearing. More after I try it.
OK, I have this done in a way that I *think* is correct, but the filter isn't working. With the test rides we have in the system, the page shows:
Ride Leader Name Number of Rides Led
Joan Toro
3
Rich Toro
4
Walk Jones
1
If you apply a filter starting today and ending one year from today, these results should change to:
Ride Leader Name Number of Rides Led
Rich Toro
1
Walk Jones
1
I'm also seeing another problem that I didn't notice before relating to the restructuring we did to create this Ride Count page. Let me know if it is better to keep that in this ticket or if I should start another ticket for that. Feel free to split this off if necessary, but it will be best if you handle it because you know exactly what you set up.
What's going on there is the Phone Number field for the Ride Contact is no longer displaying on our Rides by Date page. That field was in the Rides field group, but when we set up everything for this Ride Leader number of rides led page, I changed it to be in the Ride Leader field group. So now I'm not sure how to pull a Ride Leader field into the Ride view. I tried setting up the phone field using "A post related to the current post, set by a Types relationship" and selecting Ride Leaders (one-to-many relationship). But that didn't work. The page where this displays is here:
hidden link
To troubleshoot both these points, I'll need to see how these views are set up in the admin area.
Can you please share temporary admin login details, in reply to this message?
Note: Your next reply will be private and making a complete backup copy is recommended before sharing the access details.
Just checking in again with you on this. Understood if you're busy.
Note that the ride counts are now going to be different from what I listed above. We've now added many more rides into the system. I had the director add all the real rides for this month so he could get comfortable with the new approach. I wanted him to enter all the real rides happening now that he's also entered on our live site (not this development site). That way he'd be able to notify me of any issues he notices that I may not have seen with the rides I used for testing.
I've now found another problem with the Ride Contact field. On this page:
hidden link
We have the Ride Contact field set up as a filter. But this field is not populating with the names chosen on all the new rides our director has set up. I think the other filters are all working as expected populating with all the chosen options there (Ride Start County. Ride Start City. Ride Start Name). I know this is because of the complicated process you set up for us to make the Ride counts where I set up the separate Ride Leader content type that can be used for our Ride Contact field and the Ride Sweep field. For some reason new Ride Contacts are not getting pulled into whatever this filter is using to populate options.
I'm now fearing that we won't be able to get this because I'm seemingly entirely reliant on your help with anything we try to do with this Ride Leader/Ride Contact functionality. Sorry this is turning into something so difficult.
Just wanted to share a quick update that I'm still working on this.
Will share the detailed findings, within the next few hours. Thank you for your patience.
Thanks for your continued assistance on this. Let me know if you need me to do anything further.
Thank you for waiting, while I reviewed the updated requirements that you've shared.
The approach of using a 'Rides' post type, just to keep track of which 'rider' led which 'rides' seems like a good fit, but with the introduction of the search filters, it becomes complicated.
Thinking it through in light of this, you need a solution where all the information about an individual 'ride' is stored within the same post type.
Would you be open to the idea of dropping the 'Rider' post type, and instead adding a 'Riders' custom taxonomy to the 'Rides' post type? This way, you'll add the individual rider names as the taxonomy terms in this new taxonomy.
Any information about the individual rider (e.g. phone, email website) can be stored as term custom field with that rider/taxonomy term.
Please let me know your thoughts about this and if you have any follow-up questions.
I'm OK with any approach that works. I'd hate to see all the effort done previously go to waste because these additional needs with it do not work, but if that's how it has to be to get it to work, that's OK.
Just to clarify though, do you mean that we'd be eliminating everything done with setting up the Ride Leader content type, and then put the fields currently within that back into the Ride content type? If so, my concern with that would be how do we then get the Ride Leader Rides Led counts? Remember that the Ride Leader counts apply to the number of times a Ride Leader has been chosen as a Ride Contact or as a Ride Sweep within a Ride. So if we make the Ride Contact and the Ride Sweep fields into separate taxonomies pulling from the same group of names that can be defined twice, how do we then get the counts of the number of times each one has been chosen? The logic behind making the Ride Leader content type was to allow Views to provide the counts we wanted because I couldn't figure out how to get them when we had these fields within the Rides content type.
If we eliminate the need to have filters on this, everything else with this is working as is except for the phone field. I am going to ask my client here if it is OK to just not have any filtering before we go to the trouble of redoing all of this another way.
Can you see if there is a way to get the phone field to work with the current structure?
The problems with the current setup are:
1) Phone field does not display on our Ride Calendar views. You can use the Rides by Date view to look at that.
2) Can't get a date filter to work on the Ride Leader Number of Rides List Count Field view.
3) Ride Contact filter on Rides by Date view is not populating with Ride Leaders chosen to be Ride Contacts.
If we can just get the first problem solved that would have the current system working without filters. That may be good enough.
For this first problem, I can always bring the Ride Contact Phone field back into the Ride content type and it would work again. All that would be lost by doing that is the logic of having all the fields related to the Ride Leaders (phone, email, website) grouped together within the Ride Leader content type. Along with that, the admin will have to provide the data for those fields each time instead of having them automatically pulled through the relationship between Ride Leader and Ride when they choose a Ride Leader as the Ride Contact. That's not horrible if we have to do that. But if you can get the phone field to display with the existing structure, that would be best.
For the second problem, I can try to set up separate views for each year . That would get the director a list of the number of rides led by each Ride Leader during each year. I think that would be enough, rather than providing the ability to filter by any date range. But I don't know if that filter approach would work since the date range filter isn't working.
For the third problem, I could see if the client is OK with just eliminating the ability to filter by Ride Contact.
Hello,
Waqar is on vacation, I will take care of this ticket.
For Q1)
Since you are using one-to-many relationship between "Ride" and "Ride Leaders", you need to setup a post view:
hidden link
- Query "Ride Leaders" posts
- Filter by:
Select posts in a Ride Leaders relationship that are a related to the current post in the loop.
- In view's loop, display Ride Leader's contact phone field
Then edit the post view "Rides by Date", in section "Loop item in Rides by Date", line 5, display above post view's shortcode:
[wpv-view name="related-ride-leaders-posts"]
More helps:
https://toolset.com/course-lesson/displaying-related-posts/#displaying-many-related-items
