Problem/Motivation
jQuery UI is deprecated and we need to stop supporting the jQuery UI date picker.
Proposed resolution
Move jQuery UI datepicker support into dedicated deprecated module.
Remaining tasks
Steps to refactor to dedicated (deprecated) module
- Create webform_jquery_ui_datepicker.module
- Create test_element_datepicker.yml copy all date picker test elements
- Create WebformJqueryUiDatepickerTest.php
- Confirm existing and new tests are running as expected
- Add update hooks to enable webform_jquery_ui_datepicker.module if datepicker appears in any webform YAML configuration and the jquery_ui_datepicker module is installed.
- Update requirements to check for webform_jquery_ui_datepicker.module
- Move datepicker library definition to new webform_jquery_ui_datepicker.module
- Update DateBase::datePickerExists to support new module
- Confirm datepicker still works as expected.
- Copy hooks from /webform_icheck.module with display message for debugging.
- Move (Date|DateTime)::defineDefaultProperties to new module
- Move (Date|DateTime)::configurationForm to new module
- Move (Date|DateTime)::prepare to new module
- Remove all datepickers from examples
- Create change record.
Steps to review
In Webform 6.1.x with jquery_ui_datepicker module disabled.
- Create date element and confirm datepicker settings are not visible.
- Confirm datetime element and confirm datepicker settings are not visible.
In Webform 6.1.x with jquery_ui_datepicker module enabled
- Create date element and confirm datepicker settings are visible.
- Confirm datetime element and confirm datepicker settings are visible.
Checkout 3254570-move-jquery-ui branch
- Run update hooks
- Confirm date and datetime elements work as expected
- Create date element and confirm datepicker settings are visible.
- Confirm datetime element and confirm datepicker settings are visible.
Notes
- Drupal.behaviors.date must NOT be renamed. This will support sites that are overriding or altering this behavior
- Date picker form element will now appear last
- Conceptual this should be a backward compatible change and long as the update hook works as expected.
References
User interface changes
- Minor tweaks to date and datetime element edit form
API changes
None
Data model changes
New module


Comments
Comment #2
jrockowitz commentedComment #3
jrockowitz commentedComment #5
jrockowitz commentedComment #6
jrockowitz commentedComment #7
jrockowitz commentedThis is ready for review.
Comment #8
jrockowitz commentedComment #9
cindytwilliams commentedI reviewed this, and it works as expected. Here are some screenshots.
In Webform 6.1.x with jquery_ui_datepicker module disabled:

- Create a Date element and confirm the datepicker settings are not visible
- Create a Datetime element and confirm datepicker settings are not visible
In Webform 6.1.x with jquery_ui_datepicker module enabled


- Create a Date element and confirm the datepicker settings are visible
- Create a Datetime element and confirm datepicker settings are visible
Disable the jquery_ui_datepicker module enabled


Checkout the webform 3254570-move-jquery-ui branch
- Run update hooks
- Enable the webform_jqueryui_datepicker module
- Confirm Date and Datetime elements work as expected
- Create a Date element and confirm the datepicker settings are visible
- Create a Datetime element and confirm datepicker settings are visible
- Confirm Date and Datetime elements work as expected with datepicker options selected
The only issue that I ran into was that the date picker button does not display for the Datetime field until you specify a Date format (eg. Short date).

Comment #10
jrockowitz commented@cindytwilliams Thank you for doing the review. It is really helpful.
Comment #11
jrockowitz commentedComment #13
jrockowitz commentedComment #15
joseph.olstadFYI:
webform_jquery_ui_datepicker should NOT be deprecated!
For organizations such as the european union, the federal government of Canada, Belgium public service, Swizerland public service, the provincial governments in Canada, the html5 date picker does not adhere to language requirements. Also many private companies also have a preference for a date picker that follows the language of a page or the language of a webform . The html5 date picker is not what these organizations and many others expect.
The botched refactoring that occured between jquery_ui_datepicker 1.x and 2.x was an unfortunate step backwards. There is a fix for jquery_ui that we are using.
In order to have a correctly localized date picker that follows the language of the page (not the language of the web browser) you must use webform_jquery_ui_datepicker.
Several countries have more than one official language and the date picker has to follow the language of the current page not the language of the clients web browser. Basing language on the web browser language that is often controlled by an administrator, locked down and not the client themselves is a hindrance to accessibility and localisation.
This is where Drupal can shine, we are able to load the datepicker using labels that are translated through the string translation system.
Using the french interface:
Using the English interface:
Please see the following issue for additional screenshots and the required patch:
#3339013: implement datepicker localisation in jquery_ui 2.x, compare with jquery_ui_datepicker 1.x that has localisation
the html5 date picker is not cool since it's locked on the web browser client language which as I mentioned is a setting that is often locked down by administrators and cannot be changed.
Our clients such as the Commissariat for Official Languages considers html5 date picker as a project fail. They oversee the entire federal service in Canada and therefore any department , ministry that does not have a localized date picker for both official languages controlled by the language of the page will be flagged and also considered as a fail.
The european union is similar and I'm sure also Belgium and Switzerland.
Example is the french date picker on this webform and the english version of that webform.
Comment #16
joseph.olstad