Problem/Motivation
The Drupal 7 date module allowed the site builder to configure whether to collect an end date or not:
(This is called 'todate' in the code.)
For example, on my personal site, I have a projectNodeType which has a "time range"date. Example: https://wimleers.com/work/project/ledgrid.
Upon migration, the start value (value) is migrated, but the end value (value2) is dropped
- D7
![]()
- D8 HEAD
![]()
That's because this is being migrated to a @FieldType=datetime field in D8 instead of a @FieldType=daterange field in D8!
Proposed resolution
Make \Drupal\datetime\Plugin\migrate\field\DateField detect the todate setting and:
- expand the
processchain to also transform data for@FieldType=daterangeend_valueproperty, instead of only thevalueproperty - dynamically override the statically computed destination field type: return
daterangeinstead ofdatetimewhen appropriate - most simple, but perhaps most controversial: change the
destination_modulekey in the@MigrateFieldannotation todatetime_rangeinstead ofdatetime. The migration system seems to not have been designed for dynamic conditional edge cases like this one, and the harm of requiring that module to be installed even if unused is minimal; and certainly does not outweigh the data loss that is currently happening.
Remaining tasks
- Fix failing tests.
- Add a new test (and provide a test-only patch).
User interface changes
N/A
API changes
N/A
Data model changes
N/A
Release notes snippet
TBD

