PW 3.0.231 – Core updates

[ryan]

This week the core dev branch version has been bumped to 3.0.231. There are about 15 commits in this version relative to the previous. In the dev branch commit log you'll find a good mix of issue fixes and improvements. If you are already using the dev branch, this version is worth the upgrade. If using the main/master branch then it should be a safe upgrade as well, though none of the updates are urgent. And it won't be long till they are also merged to the main/master branch soon too. 

This week I've also been working on 2 new related modules: FieldtypeDateRange and InputfieldDateRange. These modules allow selection of starting and ending dates to support a date range. It also calculates and stores the number of days and nights for querying and sorting purposes. The "date from" and "date to" can be independently queried from $pages->find(), as can the days or nights.

The InputfieldDateRange module can be used independently of its companion Fieldtype module, making it possible to use the date range Inputfield in FormBuilder or other Inputfield forms. One context where the Inputfield might be useful is when selecting travel dates on a front-end form, such as one from FormBuilder. When used as a Fieldtype, you might use it to specify availability of something, start and end dates to publish content, event dates, or any number of other use cases. 

Below is a screenshot of the Inputfield as well as its configuration tab. The JS-based input widget comes from an existing package that I've made some modifications to, and it works really nicely, with a polished and easy-to-use UI. I originally found it booking some travel online, and really liked the way it worked. I was able to track it down on GitHub here and thought it would be useful to build an Inputfield module around it. It can be set up to work like the core date picker where it appears when you focus in the input, or it can be configured "inline" where it is alway s visible (and the related text input is hidden).

In the following screenshot, I've specified that Sundays can't be used for start/end selections and that November 23 is not available. The selected range spans two months.

If you want it to span more months, you could click the right arrow in the December calendar to find your desired month, leaving the first calendar in November. In this manner, you can select ranges that span multiple months, or even years:

Here's the Inputfield configuration screen so far. All of these settings are hookable as well, as some of them are more likely to be useful dynamically, especially min/max start and end dates, non-selectable dates, etc. (Note the screenshot below does not necessarily reflect the settings in the screenshots above). 

More on this next week. Have a great weekend! 

 

[bernhard]

Hey @ryan that looks great!

Are you also planning to add an API to select pages matching a date range? That would be great, because when working with date ranges the INPUT is only one part of the equation.

May I ask you to have a look at this thread? https://processwire.com/talk/topic/23097-previewdiscussion-rockdaterange-fieldtype-inputfield-to-easily-pick-daterange-or-timerange/

It shows what I came up with some time ago. I didn't proceed with the module, but some parts of selecting pages where quite promising:

<?php
// find events in 2023 (meaning from 2023-01-01 00:00:00 to 2023-12-31 23:59:59)
$pages->find("template=event, my_range=2023");

// find events in taking place in 2023-11 (meaning from 2023-11-01 00:00:00 to 2023-11-30 23:59:59)
// this would also find an event starting in 2023-10 lasting to 2023-12
$pages->find("template=event, my_range=2023-11");

// find events in taking place in 2023-11-17 (meaning from 2023-11-17 00:00:00 to 2023-11-17 23:59:59)
$pages->find("template=event, my_range=2023-11-17");

// find events starting after 2023-11-17 00:00:00
$pages->find("template=event, my_range.starts >= 2023-11-17");

// find events ending before 2023-11-17 00:00:00
$pages->find("template=event, my_range.ends < 2023-11-17");

Not sure how/if that works when dealing with different timezones, but for my use case it was of great help to have this easy human readable API, because when using timestamps it quickly get's complicated and prone to errors (like forgetting to use <= instead of < or such):

<?php
// find events taking place in 2023-11
$from = strtotime("2023-11-01");
$to = strtotime("2023-12-01");
$pages->find("template=event, my_range.starts >= $from, my_range.ends < $to");

That example is actually not working, because for real world queries you'd need to take more possibilities into account:

So if 2023-11 starts at the first black line and ends at the second, then you'd need this query to find events that take place in 2023-11:

// find events that either
// start within 2023-11 (meaning start after or at 2023-11-01 00:00:00 and start before 2023-12-01 00:00:00)
// or end within 2023-11 (meaning end after or at 2023-11-01 00:00:00 and end before 2023-12-01 00:00:00)
// or start before 2023-11-01 00:00:00 and end after or at 2023-12-01 00:00:00

That shows that it quickly gets very complicated and you need to be really careful with all the times and comparison operators! IMHO using the other syntax makes code a lot easier to read and maintain. For my use case (showing events in a calendar) it was a lot easier to use this syntax, because you don't have to find the timestamps of the first second of the month and the last second of the month or the first second of the next month etc.; You just use "range=2023-11" and that's it.

[PavelRadvan]

Hi.
I really like this options in date ranges.
I do not know if my question is right, but I will explain here, so it will be nice to have some info from your if what I want is possible.
I have customer with restaurant and he has from me whole site and I used Form Builder Pro from Ryan for reservations.
That customer has requirement to disable specific days which are visible in data picker.
For example he wants to disable every Sundays and Mondays and some public holidays.
On these days his restaurant is closed and thus not available for reservations.
Is it possible with that new Date ranges  ?
What do you think ?
Thanks for answer

[DV-JF]

See last screenshot in Ryan's post, bottom left 😉 From what I see, this would be possible.

[BitPoet]

This is great! Just a tiny nitpick: I'd swap around the logic for "Don't allow selection in both directions" and get rid of the "Don't", or maybe change it to "Disallow". It's a very cultural and regional thing whether questions with a negation get answered with a yes or no to confirm then, and it's bitten me in the backside myself when I rolled out an app with such a toggle to our international employees.

[ryan]

Quote

Are you also planning to add an API to select pages matching a date range?

@bernhard Since it has a Fieldtype the ability to query it from selectors comes baked in. Though it uses the terms "date from" and "date to" rather than "starts" and "ends". Each are MySQL DATE (not DATETIME) columns,  so time isn't a factor. Days and nights will also queryable from selectors. I've not yet added a custom getMatchQuery() method to the Fieldtype, but I think most of the examples you mentioned may even be possible with it using the one inherited from the base Fieldtype class, but I've not tested that far yet. I'm planning to add a custom getMatchQuery() method either way for the days/nights support, so may tweak it further too. 

Quote

On these days his restaurant is closed and thus not available for reservations.
Is it possible with that new Date ranges  ?

@PavelRadvan The disabled days or days of week would be possible. Though if this is for restaurant reservations, I'm not sure that a date range is what you'd need, unless a reservation spans more than one day? Plus, aren't reservations about time as much as date? (There's no time selection in date range). Since it would likely be just one day, I'm thinking the regular/core FieldtypeDatetime/InputfieldDatetime is probably better, plus it also supports time. It uses the jQuery UI datepicker, though I don't think that one supports disabled days. In any case, you could always use a hook or JS to alert the user when they've selected a day that reservations aren't allowed on. If you want to explore it more post in the FormBuilder board and let's see what's possible.

Quote

Just a tiny nitpick: I'd swap around the logic for "Don't allow selection in both directions" and get rid of the "Don't", or maybe change it to "Disallow". 

@BitPoet I wasn't thrilled with that label either. I converted all (or most) of the JS library's config settings to a PW settings screen and used the descriptions from the JS library in some cases, at least to start. I don't yet fully understand what that option does, so was going to figure it out and then come up with a better label/description. 

 

[BitPoet]

4 hours ago, ryan said:

It uses the jQuery UI datepicker, though I don't think that one supports disabled days.

It does if you pass a filter function to the beforeShowDay option, though I haven't found a way to set that without modifying InputfieldDatetime.js.

[Robin S]

11 hours ago, BitPoet said:

It does if you pass a filter function to the beforeShowDay option, though I haven't found a way to set that without modifying InputfieldDatetime.js.

One way is to set the option when the datepicker field is focused:

$(document).ready(function() {

	// The days to disable
	const disabledDays = ['2023-11-27', '2023-11-28'];

	// When field "date_1" is focused
	$('#Inputfield_date_1').on('focus', function() {
		$(this).datepicker('option', 'beforeShowDay', function(date) {
			return [!disabledDays.includes($.datepicker.formatDate('yy-mm-dd', date))];
		});
	});

});

 

[BitPoet]

5 hours ago, Robin S said:

One way is to set the option when the datepicker field is focused

The problem I have is that the focus event isn't triggered for inline datepickers, which are especially handy if one wants to avoid invalid manual input.

I've nevertheless thrown together a small POC module I've called DatePickerExclusions that works with focus and button click options. It still needs an option for time windows.