New post: Using date range fields in ProcessWire

[ryan]

This week in the blog we'll take a detailed look at the newest addition to the ProFields set of modules: the Date Range Fieldtype and Inputfield. This post serves both as an introduction to, and documentation for this new module. In addition, the v1 (beta) release of the module is now available for download in the ProFields board. 

https://processwire.com/blog/posts/date-range-fields/

[MarkE]

That’s brilliant @ryan. I wish I’d had that a few years back when I was developing my holiday cottage booking system. Could have done the booking form for it in a jiffy! Shame it is only days though, not times, as I can’t use it for events in an app I am currently redeveloping. 

[bernhard]

Looking really great 🙂 

17 hours ago, MarkE said:

Shame it is only days though, not times, as I can’t use it for events in an app I am currently redeveloping.

Really? 😮 @ryan is that a limitation or is that something coming later? I'd also need a field like this for events, eg MyEvent 1.12.2023 19:00 - 2.12.2023 03:00

[szabesz]

19 hours ago, bernhard said:

I'd also need a field like this for events, eg MyEvent 1.12.2023 19:00 - 2.12.2023 03:00

+1 as I am also longing for that.

[MarkE]

19 hours ago, bernhard said:

I'd also need a field like this for events, eg MyEvent 1.12.2023 19:00 - 2.12.2023 03:00

Actually, I realised that even for the cottage booking system, although the booking form is only dates, not times, I use date and time in the back end because the time is the access/leave time (see below) - the default times are auto-filled from settings  

 

[BrendonKoz]

My favorite part of the blog post (and what I was thinking about while reading):

Quote

[...] all of the date range input settings can be modified by a hook named InputfieldDateRange::getSettings

♥

Thanks, Ryan!

[Pete]

@MarkE I was going to say "+1 for the times feature" but for accommodation it doesn't make as much sense to have it there as you are mainly after the number of days/nights right? Arrival/departure times could simply be set against each holiday cottage/apartment or fall back to a "company standard" arrival/departure time like you get with some of the bigger companies? All I'm thinking is otherwise you need to enter the arrival and departure time *every time* rather than have it set at one of the "parent levels" like cottage/apartment or globally.

@ryan I definitely see the point for an optional time input for some types of event - like a single day course that runs 11am-3pm it would be good to still use this field otherwise you're back to needing 2 fields again. Same for multi-day events where there's a very definite start and end time. These are the sorts of things where on the frontend you would have a calendar with all the events on and there would be a real mix of single/multi-day but you definitely want a way of showing the times. Also allows for frontend stuff like the Resource Timeline and Resource Time Grid on libraries like https://fullcalendar.io/demos

[MarkE]

6 hours ago, Pete said:

All I'm thinking is otherwise you need to enter the arrival and departure time *every time* rather than have it set at one of the "parent levels" like cottage/apartment or globally.

With my system, the times are filled in automatically from the default for the property or system, but can be changed if, for example, early access is granted. Since the system also generates email correspondence with the guests, it needs to tell them the arrival and departure times. Sure, it could be done with separate fields, as it is now.  Having thought about it a bit more, I can see that there might be some complications arising from including times in the range and you would certainly want it to be hidden in some circumstances. 
I have another app with event booking, where date and time are essential. Using the current interface, similar to the one in my example, is a bit fiddly.