Date field widgets

Currently our date widgets are using the same markup like the datetime module widgets but those elements result in non-semantic html markup and render in an inconsistent way when compared to other form fields.

Create our own custom form elements:

  1. custom_field_datetime_date: sets #theme to NULL and empties #theme_wrappers. This will result in a much cleaner standardized form element for date fields that don't have a time widget and for the new widget proposed for datetime-local.
  2. custom_field_datetime: sets #theme to NULL and changes #theme_wrappers to ['container', 'fieldset']. For the datetime_default widget there are separate date & time form elements and the semantic accessible way to render these are via a fieldset.

Introduce new widget: Date and Time (local)

This widget will be available for datetime subfields where the date type is "datetime" and takes advantage of the datetime-local modern element. The advantage of this widget is that it will render a much simpler form element that combines both date and time into a single form element resulting in simpler markup and UX. There are a few unresolved core issues that have prevented this element type from working that we are incorporating into our own form elements. It's better we just handle it ourselves vs. waiting years for core to fix.

Views date filters

Implement similar functionality to date_filter but no dependency on that module.

  1. Add ajax to the field type option so that on change, the filter field types change to date when value is date and textfield when value is offset.
  2. Add new exposed filter setting to choose date widget type.
  3. Override the submit handler to convert date objects to strings for saving the configurations.
  4. Update views installed schema to support new filter setting.
  5. Override some of the methods in FilterPluginBase as there are various bugs unaccounted for in core that we can fix in our own implementation.
  6. Modify the exposed output to handle date field widgets

Related Core issues to account for:

#3505318: datetime-local element is failing on Datetime::valueCallback()
#3361374: HTML 5 'datetime-local' element has incorrect format
#2419131: [PP-1] #states attribute does not work on #type datetime
#3330100: TypeError: Cannot access offset of type string on string in Drupal\views\Plugin\views\filter\NumericFilter->valueForm()
#3523482: Views exposed grouped date filter default value

Issue fork custom_field-3527922

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

vladimiraus created an issue. See original summary.

vladimiraus opened merge request !131

vladimiraus’s picture

vladimiraus
Primary language English
Location Brisbane 🇦🇺
commented
Status: Active » Needs review
apmsooner’s picture

apmsooner commented
Status: Needs review » Needs work

I like this feature however, I don't think this is gonna work depending on date_filter module as there are implications around the field definition settings that aren't gonna match up with the sub-field settings. I'll look into just adding our own logic to bypass the need for that module. I think its always better if we can eliminate extra module dependencies.

apmsooner’s picture

apmsooner commented

Somewhat related... I created a custom element here https://git.drupalcode.org/project/custom_field/-/blob/3.1.x/src/Element... to handle the "Date only" type. Core's generic datetime element is not semantically correct the way its themed for this case, a random h4 replaces the label which is just wrong. We can incorporate the correct custom_field specific element here also into views and can pass in the storage settings through the custom_field.views.inc. Even the core patch that is referenced in that date_filter module implies the date type from the field storage settings which wouldn't exist in same place there for a sub-field. It shouldn't be a whole lot of effort I don't think to replicate what they did in that module. I'll see if i can get something up to test out soon.

vladimiraus’s picture

vladimiraus
Primary language English
Location Brisbane 🇦🇺
commented

Thanks @apmsooner, however your comment is not clear on what needs more work.
At the moment I have a clear issue where date fields are working date_filter but custom_field date fields are still plain text fields.

My solution checks if the date_filter is enabled and complies with it's logic.
If you have a specific testing scenario where it doesn't work, do let me know!

apmsooner’s picture

apmsooner commented

Look here: https://git.drupalcode.org/project/date_filter/-/blob/1.0.x/src/Plugin/v...
The date type for custom_field is not at the parent field storage settings and also there are dependencies on the datetime field plugins which we don't need that module and should rely on our own subfield plugins. For these reasons, I think we just need to create our own custom plugin for views that does the same thing. Make sense?

apmsooner’s picture

apmsooner commented

I think we can copy this file: https://git.drupalcode.org/project/date_filter/-/blob/1.0.x/src/Plugin/v... into ours and just change the namespace and then modify https://git.drupalcode.org/project/custom_field/-/blob/3.1.x/src/Plugin/... and then we won't need anything from that module or core datetime module. You can see how the settings are already currently passed into our class currently so we don't need to call a get to field storage in the same way.

apmsooner’s picture

apmsooner commented

Your patch was calling the DateTimestamp class from the module also. Shouldn't it have been the DateTime? I think thats maybe why its just working for you as is but i think the widget would/should be specific to the date type.

apmsooner’s picture

apmsooner commented
Assigned: Unassigned » apmsooner

I'm taking this on in a different branch. I discovered there's some better ways to handle this that improve the UX considerably and account for the different operators better. It will take a little bit to get it complete for testing but the goal on my end is to convert even the configuration fields to a date type for easier default settings. The date elements are a bit messy in Core and have some bugs to fully support better alternatives but as I've already created a custom date element, I can extend that to account for the fixes so we can have a cleaner UX in the following ways:

  • If exposed filter is date only, strip out the extra theming wrapper so we get just a very simple date input without fieldsets and such
  • If exposed filter is date + time, take advantage of the 'datetime-local' date element so we still get a simple input but better UX.

There's a few core bugs related to 'datetime-local' that I can provide fixes for through my custom date element. All of this should lead to a better UX and be standardized across different admin themes. Stay tuned!

apmsooner changed the visibility of the branch 3527922-implement-datefilter-integration to hidden.

apmsooner’s picture

apmsooner commented
Title: Implement date_filter integration » Views date filter + date widget enhancements
Issue summary: View changes
apmsooner’s picture

apmsooner commented
Issue summary: View changes

apmsooner opened merge request !134

apmsooner’s picture

apmsooner commented
Status: Needs work » Needs review

@vladimiraus & anyone else willing to help with this review:

Please check out my branch and test. There is no connection with the date_filter module and therefore unnecessary. Everything is handled directly in custom_field and there is some pretty advanced logic and various fixes unaccounted for in Core that make date form fields and views filters way more functional and visually appealing.

  • apmsooner committed 8e3fd69a on 3.1.x 
    Issue #3527922 by apmsooner, vladimiraus: Views date filter + date...
apmsooner’s picture

apmsooner commented
Assigned: apmsooner » Unassigned
Status: Needs review » Fixed
apmsooner’s picture

apmsooner commented
Status: Fixed » Closed (fixed)