Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
For those attempting to import calendars a date import supporting the entirety of the date_api (including from date, to date, repeats, etc) is needed.
Comment | File | Size | Author |
---|---|---|---|
#20 | 1021076-migrate-date.patch | 1.44 KB | agentrickard |
#19 | 1021076-migrate-date.patch | 1.44 KB | agentrickard |
#18 | 1021076-migrate-date.patch | 581 bytes | agentrickard |
#1 | date.migrate.txt | 1.34 KB | zabelc |
Comments
Comment #1
zabelc CreditAttribution: zabelc commentedI dug into this problem a bit more and I managed to come up with the attached solution. It will let you migrate to and from dates. I've managed to get it to pull in the rrule associated with repeating dates, but that part needs a bit of extra work.
Comment #2
somanyfish CreditAttribution: somanyfish commented@zabelc: I'd love some help implementing your code. I found something which looks similar in the beer example:
so this is what I tried in my Migrate implementation:
This does not successfully import the examdate field to field_exam_date, so any help would be much appreciated.
Thanks!
Lisa
Comment #3
zabelc CreditAttribution: zabelc commentedHI Lisa,
This is what my mapping looks like:
Comment #4
OliverMcc CreditAttribution: OliverMcc commentedHi,
I'm having the same problem with importing dates. Does the date have to be provided in a particular format?
thanks in advance
Oliver
Comment #5
OliverMcc CreditAttribution: OliverMcc commentedThink this code from the migrate beer example is potentially relevant regarding the need to preprocess datetime values.
I'm struggling to know what to replace $account and $row with, any help much appreciated.
thanks
Comment #6
somanyfish CreditAttribution: somanyfish commented@zabelc: Thanks very much for posting your mapping, but when I do something similar it does not work. However, I have successfully imported start dates with this prepare method in my Migration extension class:
and this helper function:
Comment #7
zabelc CreditAttribution: zabelc commented@OliverMcc all of my dates are coming from a mysql datetime field so I didn't need to use the prepare method. That said, my guess would be that you'll want to do that if you have string formatted dates. I'm afraid that I'm not certain of the particular PHP function.
Comment #8
zabelc CreditAttribution: zabelc commented@somanyfish I'm building on Drupal 7 so I used the field api. It appears that you're using Drupal 6/CCK, so we would both have to do slightly different things to store our fields...
Comment #9
somanyfish CreditAttribution: somanyfish commented@zabelc: I'm on D7 too, the cck you see referenced in my code was just what I named my function -- wasn't thinking about the fact that it wasn't a good name in this case!
Comment #10
BTMash CreditAttribution: BTMash commented@zabelc: Does this also handle a multi-date field?
Comment #11
BTMash CreditAttribution: BTMash commentedI was trying to work with what @zabelc wrote but was having trouble importing multi-value date fields (want to stress that not the same as date repeat where you can add a new row for the date and I have this so far:
I get the date object come through correctly if you format it in the mapper as:
So the 4th parameter would allow you to have a multi date setup working. However, I haven't tested or implemented the scenario where there is no separator (this is where maybe zabelc and my code could converge to fill this aspect) and the other part I haven't figured out is what to do in the scenario where the date field does not have a timezone associated with it (so it should keep the current date of the site). I have a series of dates under that scenario and they kept going back by 1 day until I changed the from YYYY-MM-DDT00:00:00 to YYYY-MM-DDT09:00:00 (where 9 is the offset in time from UTC). Any help in clarifying this would be helpful and probably help us get something out of full date field support out more quickly :)
Comment #12
zabelc CreditAttribution: zabelc commented@BTMarsh I hate to say it but I really don't know anything about multi-valued date fields. One thing that might make the code cleaner is if your version of the static MigrateDateFieldHandler::arguments function took an array of dates rather than a string with a separator. Then the prepare method could branch based on the contents of the arguments array.
I'm not at all sure what would happen if the TZ wasn't supplied. My dates were coming from datetime columns in a table so I believe they ended up with a default timezone. My guess is that they would be the default of the site or UTC. This was where I found the import/rollback feature of migrate 2 so useful. I just kept trying something until it worked...not ideal but not too bad an option in a system as complex as drupal...
Comment #13
mikeryanComment #14
mikeryanAs a starting point, I've committed a straight forward port of the D6 date support. For Date even more than the other modules supported by Migrate Extras, we really need simpletests to cover all the possibilities - I'll try to setup at least a broad framework before DrupalCon (no guarantees).
Comment #15
BTMash CreditAttribution: BTMash commented@mikeryan, I saw what you posted (and I see that you would provide an array of values); I was wondering how someone would set up a date migration with from (value) and to (value2) fields. I had some ideas on how mine could be changed so it doesn't use a separator (and I agree with you, @zabelc - the migrate rollback saved me lots of times :))
Comment #16
FrequenceBanane CreditAttribution: FrequenceBanane commentedI am also interested in in the possibility to do this without a seperator, but I cannot figure how to do it !
Moreover, how could $date_values[$arguments['start_date']] (associative array, since $arguments['start_date'] is a string) be working after $date_values = explode($arguments['separator'], $value) (explode creates numeric array, doesn't it ?).
So... subscribe
Comment #17
fangel CreditAttribution: fangel commentedMike, the straight-forward D6 port you talk about in #14 has some faults in it..
You start the
prepare
-method withBut it should really be
(Okay
$migration = ..
ain't really needed, but it could be later on)The reason is pretty obvious - in the code as it is now, it uses the variable $arguments without even having set it somewhere first.
-Morten
Comment #18
agentrickard@fangel's approach in #17 worked for my simple migration to a single date field. Patch attached.
I'm just importing to a single (no repeats, 1 row, Year - Month - Date), and I can now pass:
Where the mapping is:
Comment #19
agentrickardThe original patch throws an undefined index error. $instance['type'] is now $instance['widget']['type'].
New patch assumes timestamp unless overridden.
Comment #20
agentrickardThat last patch is not correct. $value in my case (type = 'date_select') should be kept as is. This patch restores the normal behavior.
Comment #21
FrequenceBanane CreditAttribution: FrequenceBanane commentedIt would have been greate if it had been committed to the new stable release, since it makes it unstable (it always throws errors about this undefined $arguments value whenever I try to migrate dates !)
Comment #22
agentrickardWithout proper reviews, patches don't get in. The patch is #20 is likely incomplete.
Complaining about the process is not helpful. Reviews are.
Comment #23
mikeryanSorry I haven't been giving migrate_extras much attention lately - there will be a beta of Migrate 2.1 released soon, then I'll turn my attention to catching up on the migrate_extras queue.
Comment #24
BTMash CreditAttribution: BTMash commentedI'm still confused on how this method captures the various other fields (rrule, timezone, timezone_db, value2) that zabelc processes (and mine used the not-so-good separator method). zabelc's suggestion on the array already having all that info in there made sense but maybe I'm missing something.
Comment #25
agentrickardI don't believe it does ATM, so Needs Work.
Comment #26
mikeryanI've committed the patch in #20 (eyeballed but untested) - I finally have time for migrate_extras, my first priority now is building out simpletests (starting with date support).
Comment #27
mikeryanOK, for Drupal 7 I've committed support for all three date field types, accepting timezones, To values, and rrules as arguments. There's also a new migrate_extras_examples module (implemented as a Feature) to help guide you to using these fields. I'm still working on simpletests, but this should get people going.
Comment #28
FrequenceBanane CreditAttribution: FrequenceBanane commentedWaiting for the next dev, then :-)
Comment #29
mfbdon't see migrate_extras_examples so I guess it's not yet pushed..
Comment #30
mikeryanIndeed, I committed and forgot to push. It's there now.
The example feature module is actually migrate_extras_date - migrate_extras_examples is the folder that contains it (and will contain more examples for other contrib destinations).
Comment #31
mikeryanOK, I've committed (and pushed:-) tests for date import, plus tweaks to the example to show import of timezones. Now to backport to D6...
Comment #32
BTMash CreditAttribution: BTMash commentedHmm, I'll need to update some of my docs; I'm a bit confused by how the date would be imported from the db if you have a table with value and value2 (let's say the columns are called 'source_value_from' and 'source_value_to' that as well in that table). Would the code be something like:
And how does it handle multiple data values (if we were gathering the multiple dates in the prepareRow() implementation (would we have
$current_row->source_value_from = array()
be an array with a bunch of values and then$current_row->source_value_to
be an equally sized array with its necessary values?Comment #33
mikeryanYes, that's precisely the code - see the examples in migrate_extras_date.migrate.inc.
And... Good point, a multiple-value date field with more than From dates isn't going to work as the code is now. The date field handler could recognize that $current_row->source_value_to is an array and iterate it alongside the primary values, but perhaps it would be better to use the same JSON technique as filefields. What do you think?
Comment #34
BTMash CreditAttribution: BTMash commentedI'll need to get myself more familiar with the JSON technique introduced in filefields but from what I saw, I think that would be the best way to go (the argument handler could either just handle the timezone or even that could come into the json fields).
Comment #35
mikeryanD6 version committed. So, back to D7 to handle the args as JSON...
Comment #36
mikeryanComment #37
mfbdidn't work for me. I got
"strtotime() expects parameter 1 to be string, array given File migrate/includes/base.inc, line 949". Either I did something wrong or the raw array is getting passed to MigrationBase::timestamp()?
Comment #38
mfbargh (why doesn't d.o. warn you when the issue has been commented on since the comment form was created)?
Comment #39
mfbAh it looks like this is the error message if source_value_to is NULL. In this case, the source_field mapping is ignored (although seems like Migration::applyMappings() should support NULL values here?) I fixed in prepareRow() by setting source_value_to = source_value_from if source_value_to is NULL.
Comment #40
mikeryan@mfb: Looks like you've uncovered a flaw in applyMappings(), when there's a value in the source_field it normally overwrites the array('source_field' => 'my_field_name') with the value from my_field_name, but when NULL it leaves that array in there. I've added an issue to the Migrate queue: #1161482: Use of source_field in arguments fails with NULL source value.
Thanks!
Comment #41
mikeryanOK, the JSON approach to date properties is committed for D6 and D7 - I've added examples and tests for the JSON and for multiple values. I'm closing out this issue - any specific bugs found in the date support should be opened up as distinct issues.
Thanks!
Comment #43
grendzy CreditAttribution: grendzy commentedCould someone please update the migrate_extras project page? "Date" is still listed as built-in, instead of supported by this module. Thanks!
Comment #44
mikeryanBuilt-in is correct - migration support is built-in to the Date module.
Comment #45
grendzy CreditAttribution: grendzy commentedAh - sorry. I was confused by MigrateDateFieldHandler vs DateMigrateFieldHandler. :O