Remove dependency on jquery_ui_datepicker

Hi,

Creating a patch for this issue.

Please review the patch.

Thanks.

@heddn Is there any reason we can't add a widget that uses browser native datepickers?

IMO we should use a native browser datepicker. Which #2648950: [PP-2] Use form element of type date instead textfield when selecting a date in an exposed filter tries to add to Drupal core.

So for this module it's probably the easiest solution to get #2648950: [PP-2] Use form element of type date instead textfield when selecting a date in an exposed filter in core and then fallback to the default filter.

I created a MR that removes all occurrences of jQuery UI Datepicker and an update hook that updates all filters that use jQuery UI datepicker to the default filter.

I like the approach here of removing jQuery UI datepicker in favor of the native browser one. And the code in the merge request works as advertised.

The one question I have is should this module do something like provide an option to covert the field to a #type => date element as a stop gap until #2648950: [PP-2] Use form element of type date instead textfield when selecting a date in an exposed filter is resolved? On the one hand it is duplicate effort, on the other it means not having to wait on core to remove the functionality from this module without also being a step backwards in terms of what this module offers. I don't personally feel strongly one way or another but that's the one thing that made me hesitate when considering this solution.

If the answer is no we don't want to provide a stop-gap in this module then we can either commit this now and essentially remove the feature from the module. Or, we should mark this issue as blocked on the core issue.

Either way, thanks for getting things rolling here @JeroenT.

I also like the idea of just using browser native form elements, and don't have a problem with the stop-gap option in #10.

This would also allow other modules to add javascript libraries for datepickers if they choose to.

Thank you very much for this helpful approach. jQuery should be removed as all current browsers have type type="date" support.

I think it would make sense if maintainer(s) would have a look at #10 and decide which way to go.

Thanks all!

Setting back to NW for reroll. Please set NR afterwards.

Done.

Thanks for rebasing / rerolling @Grevil! :)

Technical RTBC +1 for MR!17. Does what it should.
But #10 should be discussed. BTW in this webform issue, you can see how webform solves something similar: #3120543: Date field missing core/modernizr dependecy

MR !17 merge error

MR needs to get rebased on current 5.x. Should we also cherry-pick the commit into 6.x? I guess that would make sense?

Changing version to 5.x for now, but my question still stands.

I rerolled the MR 17 patch for 6.0.x. It failed for the composer.json and the README (change from txt to md extension).

Fixed overlapping of update functions.

We shouldn't work with patches here, as we are already have implemented the changes in our issue fork. @rcodina could you update this issue fork's "3210945-remove-dependency-on" branch with your changes from #19 and #20? Or provide an interdiff between patch 19 and "3210945-remove-dependency-on"?

It would still make a lot of sense to remove the jquery datepicker and replace it by the native HTML5 date selector. More lightweight, standard and less issues on our side.

@Grevil what was the reason to use 8.x-5.x instead of 6.x?

Re #10 regarding #2648950: [PP-2] Use form element of type date instead textfield when selecting a date in an exposed filter I think that issue is PP-2 and will need loooooooong until being resolved. So we should do here, what we can and solve that part in a follow-up. jQuery datepicker is old, ugly and no more required here.
Issues like #3338846: Datepicker is displayed in wrong position when the page is scrolled will be gone after the change.

Anyone agrees we should finish this?

@Anybody, honestly, I have no idea. Let's target 6.0.x!

Alright, I applied the rerolled patch by @rcodina on the newly created branch "3210945-remove-dependency-on-6.0.x".

Please review MR 39.

LGTM!

@Grevil: Could you please test this in some combinations in the view and post a screenshot of the HTML5 datepicker shown? Also please try that it works in the expected formats, which means, ensure that the view returns the expected results from the date filter.

If you need further information, don't hesitate to contact me personally ;)

Back to "Needs work" there is no "datepicker" option.

Oh my bad, didn't realise, that this patch requires the core patch provided in #2648950: [PP-2] Use form element of type date instead textfield when selecting a date in an exposed filter!

It works alright. The date picker is way to specific. E.g. when filtering content based on the updated date, we also need to specify an exact time (with seconds), which won't do the trick here. But this should be discussed in the parent issue.

Here are some impressions:

But as the core patch is required, we should postpone this issue for now anyway.

POSTPONED on: #2648950: [PP-2] Use form element of type date instead textfield when selecting a date in an exposed filter.

So since core can be slower there anything we can do here instead to drop the crud of jquery.

Actually lets do that. Just a simple filter for "Date" that uses a basic template OR we update the default filter that if it's a date field to set the type "#date"

Dealers choice

Only concern is if this could break existing sites maybe I start a 7.0.x branch for deprecations.

Started a 7.0.x branch so this can continue.

Sorry for the noise.

We have removed jquery_touch and have up for removal removal of jquery_slider

Leaves just this one but seems it's really blocked on a core issue that's stalled.

So lets handle ourselves here #3444650: Add support for input type "date". Then we update jquery plugins to use this and should be min disruption.

Tried a different approach were we keep the filter but instead of relying on jquery it adds the attribute of type date.

Hi, will this feature will be backported on current stable 6.x version?

Plan is to merge this change into 6.0.x then in 7.0.x remove from the composer file.

Bad form on my part I admit. But I went ahead and merged so that can get 7.0.x ready for a D11 release.

Shouldn't the 'datepickers' library (js/bef_datepickers.js) also be removed within this change?
Or am I missing something?

No the library is the same. It’s just now using non jquery plugins.

Ok thanks for the clarification. Misinterpreted the change then.