Home › Toolset Professional Support › [Resolved] Setting up a date filter on a view you previously helped us set up.
This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.
Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.
Sun | Mon | Tue | Wed | Thu | Fri | Sat |
---|---|---|---|---|---|---|
- | 9:00 – 13:00 | 9:00 – 13:00 | 9:00 – 13:00 | 9:00 – 13:00 | 9:00 – 13:00 | - |
- | 14:00 – 18:00 | 14:00 – 18:00 | 14:00 – 18:00 | 14:00 – 18:00 | 14:00 – 18:00 | - |
Supporter timezone: Asia/Karachi (GMT+05:00)
This topic contains 9 replies, has 3 voices.
Last updated by Waqar 7 months, 3 weeks ago.
Assisted by: Waqar.
We have a view set up that Waqar assisted with. With that work, we set up a view within a view that would provide a page that gives the output as the number of rides led by each ride leader on our site. That view is working fine right now. But we tried to set up a front-end date range filter on here and that did not work because the date filter needed to be applied to the child view not the parent view that is displaying on the page and there was no way to make the front-end date range filter on the parent view work on the output results of the child view.
Our executive director is now having trouble with doing counts that she needs because the date range filter can't work. I told her that we can break down the output by year to get her what she needs.
So what I'm trying to do instead now is to set up an admin side filter within the child view to limit the output results to rides within a one year date range (January 1-December 31). I've duplicated our original views to have single year views for both 2023 and 2024. All that work is already done on both the parent view and the child view. I've also set up new 2023 and 2024 pages to display each single year view.
I did not change anything with the existing views that are working properly. I didn't want to touch that.
The problem I'm having is I eliminated the non-functional date-range filter on the new 2023 and 2024 child views and instead tried to set up a Query Filter. The thing here is I am unsure about how to define the filter. I tried setting it up the way that made the most sense to me, but it produced a page with no results. So I think I've set up the date field filter incorrectly.
For the 2023 one, I tried setting it up as
Start Date and Time is a DATE between DATE(01, 01, 2023), DATE(31, 12, 2023)
But my guess is the format of the datetime field requires this to be done differently.
I'm not 100% sure that how I'm setting up the filter is what is causing the failure, but I am thinking that is the most likely scenario given past issues I've had with setting up date filters. I think I recall times where you let us know that the format of this field requires a different approach.
Any assistance you can provide would be appreciated as always.
Hello. Thank you for contacting the Toolset support.
Assuming the custom date field you are using is created using Toolset Types. If this is correct - then Types date field stores the date value as Unix Timestamp.
Maybe you should try to add the Query Filter to filter the view based on the shortcode attribute but I can tell what will be the best possible solution once I review your current setup.
Can you please share problem URL where you want to apply the filters and admin access details.
*** Please make a FULL BACKUP of your database and website.***
I would also eventually need to request temporary access (WP-Admin and FTP) to your site. Preferably to a test site where the problem has been replicated if possible in order to be of better help and check if some configurations might need to be changed.
I have set the next reply to private which means only you and I have access to it.
Hi,
Thank you for sharing the access details.
Minesh is on vacation and I'll be following up on this ticket. I'm currently reviewing the details that you've shared and will perform some tests, accordingly.
Will share the findings, as soon as this testing completes.
regards,
Waqar
OK, let me know if anything else is needed. We're finally getting back to this issue that was causing difficulty when we initially set it up. It worked fine without the date filter for awhile, but now the director needs to be able to at least separate out the 2023 rides from the 2024 rides for these counts.
I have all of the structure for separating the 2023 and 2024 rides built. I just need assistance with how to define the query filter on the date field.
Thank you for waiting, while I completed, the troubleshooting around this new view.
After debugging, I was able to figure out why the new view 'Ride Leader Number of Rides List Count Field - 2023' was not showing the results, the same as the older view 'Ride Leader Number of Rides List Count Field'.
In the Toolset's custom code snippet section, there is a snippet named 'test', which converts the 'AND' operator between the custom field queries to 'OR'. This change was needed, because we wanted all rider posts where the target rider was involved either as 'Ride Contact' or as 'Ride Sweep'.
I've updated that code snippet so that it now covers both these views for this change in the operator.
The downside of this change in operator, however, is that it applies the logic to the date field filter too. We need an 'OR' operator for the two fields 'Ride Contact' and the 'Ride Sweep', but for the start date field, we need the 'AND' operator.
For a requirement like this, we may have to drop this approach of showing the count based on the results coming for the child view and instead add a custom script that evaluates how many results are visible, depending on the 'Year' value.
If you're open to this idea, I can suggest some pointers to implement a change like this,
Yikes. I should have known that this was going to be more complicated than expected. The system you set up to make this work originally had my head spinning. I thought we'd be able to just set up a back-end date range that would limit the results to only include rides within that date range.
I had not known what was in that "test" snippet, but I always left it alone assuming it did something we needed. At least I now know that it's how you created the logic necessary for Ride Leaders AND Ride Sweeps to be included in the counts for each ride. I have now changed the description of that snippet to say "Snippet for Ride Leader Ride Count views to use OR operator for Ride Leader and Ride Sweep fields to both be included in Ride count"
So help me understand the problem better here first. Is this accurate:
1) You're currently applying the OR operator to the child view which is what allows it to include both Ride Leaders *and* Ride Sweeps in the count.
2) We now need to add the date field to the query but that requires the AND operator so the only dates used will be ones that are after the start date AND before the end date specified.
3) You can't use the OR operator on one field and the AND operator on another field without an additional custom script.
4) Going the custom script route will require a complete redesign of the system that is currently working without the date filter. If so, my head is back to spinning again.
Is this accurate?
I'd rather not have to redesign the whole system because I don't have the coding skill to do that and I wouldn't want to impose on your generosity for that unless you think it is something that can be done quickly and easily and you're willing to do it for us.
Question: Can we achieve the same goal through conditionals in the output rather than with a query filter?
Giving what I'm thinking your answer will be here: I'm thinking we could limit the display of the ride titles and dates with a conditional output display, but that conditional would not work on the [wpv-found-count] display, which is what is giving us the number needed for each ride leader and is the whole point of this system. Is that correct? I'm thinking [wpv-found-count] display operates off the Query Filter. If there is a way for a conditional date range to be imposed on the [wpv-found-count] display as well, then could we go that route?
I'm seeing how you changed how the date range is defined in the query filter to use "Start Date and Time is a number between 1672513200, 1704049199". That's what I thought would be all I needed with this ticket. But I'm seeing what you're saying that the output is still including all rides because of the AND-OR situation.
Do I understand it correctly that all the 2024 rides are still displaying because they meet the criteria of starting after 1672513200 *OR* ending before 1704048188, but they would not meet the criteria of starting after 1672513200 *AND* ending before 1704048188? Is that correct?
So if that's what you're saying, do I understand it correctly that if we eliminate Ride Sweeps from the count, we will no longer need that custom snippet forcing the OR operator on this view and then the date range would work using the AND operator? If so, I can pose this to our director and tell her "You can either have a working date range filter OR you can have Ride Sweeps included in the count, but not both without a full design of how this system is set up." Does that sound right?
Thanks for writing back and your understanding about all the points that you've mentioned is correct.
( including the downside of the conditional display approach )
> I'm seeing how you changed how the date range is defined in the query filter to use "Start Date and Time is a number between 1672513200, 1704049199". That's what I thought would be all I needed with this ticket. But I'm seeing what you're saying that the output is still including all rides because of the AND-OR situation.
- Yes, that's correct. If the date filter was the only filter or the date filter and only one other custom field was involved, we will not need to change the 'AND' operator to 'OR' and it would work. But, then the count would be for only one level of participation by the rider not both.
> Do I understand it correctly that all the 2024 rides are still displaying because they meet the criteria of starting after 1672513200 *OR* ending before 1704048188, but they would not meet the criteria of starting after 1672513200 *AND* ending before 1704048188? Is that correct?
- Technically, when we specify the date range in the comparison, that part uses the 'between' operator and not the 'AND' or "OR". It is the collective operator between the custom fields query filter that is the challenge here.
> So if that's what you're saying, do I understand it correctly that if we eliminate Ride Sweeps from the count, we will no longer need that custom snippet forcing the OR operator on this view and then the date range would work using the AND operator? If so, I can pose this to our director and tell her "You can either have a working date range filter OR you can have Ride Sweeps included in the count, but not both without a full design of how this system is set up." Does that sound right?
- Again, you've got this right and dropping the 'Ride Sweeps' filter can reduce the complexity and the need to change the 'AND' operator.
But before moving to a compromise like this, are you or your director open to the idea of introducing a new custom taxonomy 'Ride Year' with the Rides post type? This means that for each ride, you'll not only specify the start and end date time but also the 'Year' number, through this new taxonomy.
As a result, you'll be able to keep both custom field filters and for the year filtering, using this taxonomy and not the start date/time.
Yes!!! That's absolutely OK to do it that way. I don't know why I didn't think of that approach myself. Let me go ahead and apply that and I'll let you know if run into any trouble.
I'm glad you liked this suggestion and let me know if you have any follow-up questions.
For a new question or concern, you're welcome to start a new ticket.