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 |
|---|---|---|---|---|---|---|
| - | 7:00 – 14:00 | 7:00 – 14:00 | 7:00 – 14:00 | 7:00 – 14:00 | 7:00 – 14:00 | - |
| - | 15:00 – 16:00 | 15:00 – 16:00 | 15:00 – 16:00 | 15:00 – 16:00 | 15:00 – 16:00 | - |
Supporter timezone: Europe/London (GMT+00:00)
This topic contains 6 replies, has 2 voices.
Last updated by 6 years, 3 months ago.
Assisted by: Nigel.
Hi there
By period of time
Date fields are stored as UNIX timestamps (i.e. numbers) and so any query filters that use these date fields must be formulated such that you are comparing like with like, i.e. you are comparing timestamps with timestamps.
Normally when you insert date filters you might add a BETWEEN comparison where you add filter controls for the 'from' and 'to' dates, and to search for events happening "next month" the user would set the from date as 1 Oct 2018 and the to date as 31 Oct 2018.
When you insert filter controls for a date field the only input type options are a text input or a datepicker. (See the screenshot where I'm inserting the controls for a "Launch date" field with a between comparison.)
If you want the users to instead choose from a series of options ("today", "tomorrow", "next week", "next month") then you would need to choose the text input option and visually hide the text inputs and use JS to add a select dropdown with a series of options which you would then use to populate the hidden text inputs with the required values (UNIX timestamps for the from and to values corresponding to, for example, "next week").
By area
You can filter by distance from a location that a user enters, which is based upon the address field stored for each post (or they can choose their location as the centre of the search).
If you wanted to list all posts from "Chicago" for example, that's not quite the same thing. You would need to actually store "Chicago" as either a custom field or, better, a location taxonomy term. (Better because taxonomies are optimised for queries in a way that custom fields are not.)
And also by:
Up to budget is simple enough, you just insert a filter control for the price field and use a less then comparison instead of equals.
Hour of the day cannot be done based upon the date field stored for the post, because it is impossible to generate a comparison that compares like with like.
You would need to explicitly also store the hour of day (either as a custom field or taxonomy term).
You can add these filters to a single View, and output the View as both a list of results and—at the same time—as markers on a map.
I don't really have a lot to say about recurring events, they are potentially complicated to implement.
Event plugins, such as the Events Calendar, handle recurring events by creating new event posts for every event occurrence, rather than trying to record all of the dates as fields of a single post, which makes filtering unduly complex.
In the screenshot you can see I'm adding an event which repeats every Thursday.
On saving this single post I can go into the wp_posts table of the database and see that many new event posts are added, one for each Thursday occurrence.
When it comes to building something fairly advanced like an events system, you should consider whether your efforts are better spent on building it from scratch using tools such as ours, or taking a dedicated product designed for the purpose and adapting it to your needs.
