Allow to import availability data with Migrate

Thanks for posting this patch. I had a quick look at it and found the points below. Reading your blog made some things clear, but let's ensure the code is readable stand alone, so adding some additional comments would be nice.

Regarding the hybrid approach:
It started as a field, and a complex one. So complex that I had to store the "real" data outside the field storage. Only later I discovered that it would be handier to (also) define it as an entity as that would facilitate integration with Views and Search API. So I defined it as an entity, but only on the reading side, thus no C,U, and D out of crud, via the entity API as that served my purposes. If I am going to create a D8 version it will be an entity only and the field should be replaced by an entity reference field.

Regarding the code you are reusing:
This code was so specific for the communication with the edit form that I could not envisage any use elsewhere and as such did not nbother to abstract it into a decent API method. However, I can do so now by moving the code you are using out of the widget code into the .inc where most of the API functions are living. In doing so, I can add parameters for the period to accept or even push that to a separate validator.
On the other hand, you can easily create your own array to pass directly to availability_calendar_update_multiple_availability() by adding 1 line per day, using a lookup to convert your source state to the destination state and a DateTime that you advance with a day on each character. In doing so, there's no need for the very strict validation, the need to convert to a string and back, nor for the date restrictions. Moreover, just passing NULL as $cid to availability_calendar_update_multiple_availability() ensures that a new calendar will be created and its cid returned, so exit $cid_unique and $new_cid_count. You can even "optimize" that array later:

$current_entry = 0;
while ($current_entry < count($availability_array) - 1) {
  if ($availability_array[$current_entry][state] === $availability_array[$current_entry + 1][state]) {
    $availability_array[$current_entry][enddate] = $availability_array[$current_entry + 1][enddate];
    unset($availability_array[$current_entry + 1]);
  }
  else {
    $current_entry++;
  }
}

1. +++ b/availability_calendar_migrate_field_handlers.inc
   @@ -0,0 +1,94 @@
   +   * Register availability_calendar type.
   +   */
   

   Due to the hybrid approach of A.C. I'm not sure whether this registers the entity or field :)

2. +++ b/availability_calendar_migrate_field_handlers.inc
   @@ -0,0 +1,94 @@
   +   * Force creation of an entity embedding availability.
   +   *
   

   not sure about this sentence, perhaps something like:
   Creates and populates an availability entity/field.

3. +++ b/availability_calendar_migrate_field_handlers.inc
   @@ -0,0 +1,94 @@
   +  protected function prepareCalendar($dates, $element, $entity) {
   +    $changes = array();
   

   Add @param and @return

4. +++ b/availability_calendar_migrate_field_handlers.inc
   @@ -0,0 +1,94 @@
   +      if (!empty($line)) {
   +        $change = availability_calendar_field_widget_month_form_validate_line($line, $element);
   

   trim($line) before checking for empty

5. +++ b/availability_calendar_migrate_field_handlers.inc
   @@ -0,0 +1,94 @@
   +        if ($change == FALSE) {
   +          watchdog('availability_calendar', "Invalid availability data: %line", array('%line' => $line), WATCHDOG_ERROR);
   

   use ===.

I was more thinking about going the direct way (using availability_calendar_update_multiple_availability() directly), but think that this solution that accepts both ways is better.

I Also made some other (small) changes. Can you review (and test?)? Will this work in a real migrate situation?

Nice, however I can't get the test to work, it fails on the last assertion.

- hook_migrate_api in availability_calendar.migrate.inc gets called
- I see the XML mapper at work
- But the resulting string does not get "prepared". It gets set as the field value and after that the node gets saved with that incorrect field value ("2,2016-04-01,2016-05-31\n ...")

Where should AvailabilityCalendarFieldHandler enter the stage (getting constructed) and when should its prepare() method gets called?

I'm running the test via the UI on my local install.

I committed the code, including the tests, even if I can't get them to run locally. Can you have another look? Maybe my latest changes contain a bug after all.

Do you want to be listed as a sponsor/contributor to this module on the project page? If so, under what name and link?