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 |
|---|---|---|---|---|---|---|
| 8:00 – 12:00 | 8:00 – 12:00 | 8:00 – 12:00 | 8:00 – 12:00 | 8:00 – 12:00 | - | - |
| 13:00 – 17:00 | 13:00 – 17:00 | 13:00 – 17:00 | 13:00 – 17:00 | 13:00 – 17:00 | - | - |
Supporter timezone: America/New_York (GMT-04:00)
This topic contains 21 replies, has 2 voices.
Last updated by 3 years, 5 months ago.
Assisted by: Christian Cox.
So how do you suggest we can resolve the issue?
I see these filters were originally written for use with some other Views (not Find a Job / Find a Nanny Views), and the syntax used to manipulate the query arguments was based on the requirements for those original other Views.
- change_date_filters_for_expiring_nanny_ads - change_date_filters_for_expiring_job_ads - post-expiry-gt-now-view-filter
Now when these filters are applied to the Find a Job / Find a Nanny search Views, my guess is the syntax is adjusting the wrong query arguments, and the result is inaccurate filtering. Jamal had some comments about the potential for problems like this in your previous ticket:
https://toolset.com/forums/topic/query-expiring-and-expired-posts/page/2/#post-1789439
"My code, at line 6, assumes that the condition on the time interval is the only condition on meta keys(custom fields). You can see how it uses the index 0:"
Similarly, the code in post-expiry-gt-now-view-filter is written in a way that isn't very flexible to support multiple custom field filters at the same time. Since the Find a Job and Find a Nanny search Views both include custom field Query Filters in addition to the expiration time added by the post-expiry-gt-now-view-filter, the code that manipulates the date filters probably needs to be adjusted to account for these additional custom field filters. Or, if you'd rather not get into adjusting this code, it would be easier to remove the View IDs 2231 and 2145 from these scripts. The scripts would still apply to other Views, so you would continue to get the benefits of these scripts in other places.
4) On a related previous Toolset ticket...we were given a custom code snippet "func-set-default-orderby-modified". Is this issue resolved with the latest updates, and if so, is this custom code obsolete and can now be deleted?
-- No, the latest updates did not address the issue you are referring to in another ticket. It is still in our developers' queue but has not yet been resolved.
func_set_default_orderby_modified - is used to fix another Toolset bug with the display of posts set to display by modified by default, which is our preferred sort critierion for those two Views.
I may have misunderstood the previous ticket and the open issue. I just took a closer look and the issue that is still open in our developers' queue is specifically about View blocks sorting controls. That ticket is still open, but it seems obsolete because right now it seems that the sorting control block functionality has been adjusted in a recent release. Regardless, the func_set_default_orderby_modified function is inactive on your site now, yet the Find a Job and Find a Nanny Views both seem to be sorted based upon Last Modified, by default when the page loads. So I don't think this additional function is necessary anyway, unless I'm misunderstanding something. See the screenshots here. It looks like the sorting is accurate without this function active anyway.
1) We can safely remove...View 2145...View 2231...from change-date-filter-for-expiring-job-ads and still sort these these two Views by Last Modified date and/or by any other custom field.
Yes, I think so. I don't see any problem with that. The front-end sorting controls should still continue to function as expected without the custom filtering code applied to these Views.
2) Am I actually correct in saying that these two code snippets are just there to correct the 1-2 hour time difference from GMT/daylight saving, right?
Based on what I can see in the other ticket, it looks like these two code snippets were designed to help filter out expired posts by adjusting the calculated filter expiration time to account for the potential time difference between the expiration field (GMT/UTC) and the calculated filter time (server timezone). The original View 10351 had one custom field Query Filter based on the post expiration field. The code adjusted the expiration date calculated in the filter using NOW or SECONDS_FROM_NOW.
By the same logic then, it would make sense to remove not only View 2231, but also 1973, 10121 from change-date-filter-for-expiring-job-ads...And similarly, View 2145 as well as 1980, 10151 from change-date-filter-for-expiring-nanny-ads (list below) Correct?
That would leave only two Views in the list of filtered View IDs for change-date-filter-for-expiring-job-ads: 10351 and 10430.
10351 no longer exists:
hidden link
10430 has no expiration date filter, as far as I can tell, unless it is added in other custom code:
hidden link
It would leave only two Views in the list of filtered View IDs for change-date-filter-for-expiring-nanny-ads: 10720 and 10722.
10720 no longer exists:
hidden link
10722 has no expiration date filter, as far as I can tell, unless it is added in other custom code:
hidden link
So for all practical purposes, the change-date-filter-for-expiring-job-ads and change-date-filter-for-expiring-nanny-ads filters can be deleted. They are not doing anything effectively now. They would only be effective if any Views in the list of IDs had one custom field filter for the expiration date field _cred_post_expiration_time, with the field value calculated using NOW(), and that is not the case for any of the Views included in the list of IDs.
3) Snippet post-expiry-gt-now-view-filter (currently inactive) came into existence in another ticket with you...Has this issue been resolved/improved by your dev team yet?
Well no, the problem is the same problem we are addressing in this ticket. My solution was for displaying expired posts correctly and Jamal's solution is for filtering out expired posts correctly. They are opposite sides of the same problem. I have attached a screenshot to explain the problem again. To show or hide expired posts, you need to filter a View based on the field _cred_post_expiration_time. A Query Filter should be configured based on that field. To show expired posts, the value must be lower than NOW(), and to hide expired posts the value must be greater than NOW(). The root problem is that NOW() is calculated incorrectly by Views filters.
Jamal's solution was designed to work with a Query Filter that exists in the View editor screen. It adjusts the calculated NOW() value automatically. My solution was designed to work without a Query Filter in the View editor screen. It creates a filter programmatically and compares the value of the expiration field to the correct value of NOW(). No Query Filter for this field will appear in the View editor screen.
The "less than" code snippet you provided in the ticket (my version: post-expiry-lt-now-view-filter) was only for Ads that had actually expired, right?
Yes, the filter there was designed to display ads that have expired.
I believe "modified" became a valid argument, whereas in previous versions, one could only use "date" as an argument? Any more updates from 2nd level on the "modified" syntax?
Yes, the option to orderby "modified" will sort the results based on the last modified date. I think you can deactivate that snippet for now, or delete it.
