Undefined index, array_flip and non-object errors upon creating or editing

I'm having the same issue, but I'm not running Commerce Kickstart:

https://drupal.org/node/2228821

I think there's something different in Civi 4.4.5, but I've not heard anything for about a month now...

@seascoot: First, what you are seeing are PHP warnings and notices. Note these are not the same things are outright errors and shouldn't be preventing things from working (you don't have PHP notices enabled on a production site do you?). Second, I cannot replicate your problem and will need more details. What version of Drupal are you using? What version of civicrm_multiday_event? What version of PHP?

Thanks for confirming this - I reported the same behavior in https://drupal.org/node/2228821 but I'm not running Commerce Kickstart, nor have I tried to add additional events before fixing the faulty event.

I'm running the module on several installations and the main differences I can think of would be PHP version and Civi 4.4.5 - I've already tried both PHP 5.3.13 and 5.4 - no joy.

Here's hoping this can be tracked down - as per my original post, I've resigned myself to handling new events myself (and dealing with the errors) until the problem is solved. I can't let clients see this.

Thanks to all and good luck!

I was able to re-produce the errors. The problem is the way civicrm_multiday_event is checking the dates of the sessions. Field Collection changed the node attached data structure dramatically (in a good way); the entire FC related entity is now available in the node data. This will eliminate the need to do a field_collection_item_load() in the middle of CME processing.

The reason that the CiviEvent gets created with a Jan 01 1970 date is because Civi uses the Unix epoch for event dates that are set to NULL due to CME being unable to correctly find the original entities.

A patch is in the works.

After getting into the code a bit more and doing some debugging, I realized that my conclusion was essentially correct but my logic in reasoning it out was flawed. What is happening is that Field Collection is saving the node along with the form submission. Due to this we are entering into the hook_node_presave function twice for each node being saved in the UI. When the FC is saving the node, it attaches in the entire FC entity to the node object instead of going through the Field API to format the field values.

I have run into this issue when doing a CME Migration, so patching this up will be that much more useful.

Fix has been added to the latest 7.x-1.x branch of CiviCRM Multiday Event. Please try out the latest dev version and let me know if your problems are resolved.

This is why developers should move issues to "Needs Review" instead of "Fixed" themselves. The latest commit had a PHP error.

http://cgit.drupalcode.org/civicrm_multiday_event/tree/civicrm_multiday_...

Not sure if the intent there is $end_entity = end($node->field_civicrm_multiday_session[LANGUAGE_NONE]); or $end_entity = end($node->field_civicrm_multiday_session[LANGUAGE_NONE]['entity']);, but what was committed obviously isn't right.

Not sure if the intent there is $end_entity = end($node->field_civicrm_multiday_session[LANGUAGE_NONE]); or $end_entity = end($node->field_civicrm_multiday_session[LANGUAGE_NONE]['entity']);, but what was committed obviously isn't right.

@kreynen - the code works perfectly fine for me. My guess is that I'm running a more current version of Field Collection (7.x-1.0-beta7). Could you confirm this?

I am unable to reproduce the problem with Field Collection 7.x-1.0-beta5. If I could see a var_dump or dpm() of your $node->field_civicrm_multiday_session value, that would be awesome.

Note that I'm working on a fresh D7 core build, not a starter kit.

I am able to enable the module on Pantheon where they run PHP 5.3.17, but this code results in a PHP parse error at the syntax level on other servers.

This isn't an issue with the version of field_collection or the use of a distribution. The PHP parser on these servers doesn't believe that end($node->field_civicrm_multiday_session[LANGUAGE_NONE])['entity'] is valid PHP.

We never get far enough to check the change in the logic in the update.

When a site running on PHP 5.3.3 upgraded to the dev snapshot that included this change and the module was already enabled, it WSOD the entire site. When I try enabling the module on a clean site running 5.3.14, I get the same error...

Parse error: syntax error, unexpected '[' in ...sites/all/modules/civicrm_multiday_event/civicrm_multiday_event.module on line 366

On a clean site, the module never enables.

I've tried disabling APC. No difference.

I can get the site to work/module enabled if I chance the code at line 366 to...

elseif ($node->field_civicrm_multiday_session[LANGUAGE_NONE][0]['field_session_date']) {
      $start_entity = $node->field_civicrm_multiday_session[LANGUAGE_NONE][0]['entity'];
      $lastkey = key(end($node->field_civicrm_multiday_session[LANGUAGE_NONE]));
      $end_entity = $node->field_civicrm_multiday_session[LANGUAGE_NONE][$lastkey]['entity'];
    }

But I'm not sure that's the same intent as end($node->field_civicrm_multiday_session[LANGUAGE_NONE])['entity']. If it is, I suggest we change to that vs. trying to figure why specific versions of PHP throw a parse error.

I believe the problem is with versions of PHP earlier than 5.4.10. I was able to reproduce the WSOD by switching to PHP 5.3.20. Seems PHP 5.4 thinks more like I do than does PHP 5.3.

Let me know if this patch helps.

On channelAustin's live community site I upgraded to the latest dev snapshot for this module which included the commits referenced in this issue.

I'm changing the status.

@seascoot can you test the latest dev snapshot and make sure this works for your version of PHP as well? I've tested it on a few different configurations and think we're ready to roll a new release.