Exception: The host entity cannot be changed. in FieldCollectionItemEntity->updateHostEntity()

This happened to me too. I was using the dev version and had patched it per #47 on https://www.drupal.org/node/2382089, and it did not help. I then rolled Field Collection back to beta8 and it now saves fine. I won't have time to investigate further right now, but thanks (giupenni) for reporting the workaround.

I am having this problem on Beta 8. Multi-lingual site that I have inherited and not sure what is going on.

Same issue : multilingual site.
Revert to beta8 save me : thanks giupenni !
Conclusion : no more updates, too risky.

Debugging the patched module (https://www.drupal.org/node/2382089#comment-11679969), I found this row:

//sites/all/modules/field_collection/field_collection.entity.inc:318
$this->hostEntityId = $data ? end($data_array_keys) : FALSE;

$data coming from a query that extract all entities with the fields attached, if query returns more than one entity (I don't know why, l'm investigating) the veritication of the host entity failed.
I changed the code like reported in patch and all start to works fine. I've to test better, but suggest will be very apreciated

Ciao

I have manually applied this patch to Beta 12 and it fixes my issue.

I tried all of the patches and none solved our specific implementation. Beta 8 works perfectly. Our scenario -- Field collections with entity references to content that have entity translations. Beta 8 saved the day.

UPDATE on #9: This patch works but I saw a side effect when field collection is inside a field collection.
when a user is not admin, the flow to check permission fail with this error:
EntityMalformedException: Permission to create a node was requested but no node type was given. in entity_metadata_no_hook_node_access() (line 680 .../sites/all/modules/entity/modules/callbacks.inc).

#9 works for me. So far this is the only way that I've been able to make field collections translatable via. content translation on the site I'm working on right now.

@Coreyck - this is a big bug. It prevents nodes from being indexed by ApacheSolr.

We were able to work around this by manually adding those elements to the index outside of the off-the-shelf Apache Solr modules using hook_apachesolr_index_document_build and manually constructing a value to insert into the document object that is sent to Solr.

There were a few hoops we had to jump through:

1) Getting the right value to use for language. We found that not every entity supported $entity->language so we wrote a function where we pass the entity object into and we receive the right value for language:

$entityLanguage = $entity->language;

   if (!$entityLanguage || strlen($entityLanguage) < 1) {
      $entityLanguage = entity_language($entity->type, $entity);
   }

   if (!$entityLanguage || strlen($entityLanguage) < 1) {
      $entityLanguage = LANGUAGE_NONE;
   }

2) We programmatically constructed the value we attached to the document to send to Solr for indexing using the following code within the hook_apache_solr_index_document_build function we wrote:

a) Get the field collections:

$cta_left_coll_field_colection = entity_load('field_collection_item', array($field_cta_left_coll));

b) Do whatever we needed to do to formulate the values we wanted to send to Solr, each case is different based on how the values in the field collection are going to be used in search results

c) Create a json object with that information, in this case we were building buttons that appear on a page based on a field collection of taxonomy terms that were translated using entity translation:

$left_button['label'] = $term_name;
    $left_button['url'] = $field_collection_value->field_link[$entityLanguage][0]['url'];
    $cta_left_coll = json_encode($left_button);
    $document->addField('sm_cta_left_coll', $cta_left_coll);

And that was it. We spend weeks digging through code trying to make the off-the-shelf modules work and gave up and went this approach and we solved it in a day or so. We also solved the problem of Drupal Commerce not being fully entity translation friendly using this same approach. The end result we wrote about 3,000 lines of code to build our custom elements that we attach to the document that Solr indexes -- but absolutely every scenario, including field collections of field collections where both levels were translated using entity translation worked perfectly.

I tested the patch on the patched beta12 module and it solved the issue.

Like #16, patch works for me on beta12

The patch in #9 did not fix this for me.

The fix from #27 on #2658882: "the host entity cannot be changed" error with VBO fixed this for me when combined with the changes added to the dev version.

I'm not following the what #19 is reporting. He suggests #27 #2658882: "the host entity cannot be changed" error with VBO plus a dev version commit.

I have entity_collection 7.x-1.0-beta12+4-dev. Does this include the commit he references?

#27 from the VBO page lists two patches:
2658882-fc-27.patch
2658882-fc-27-beta12.patch

Assuming I follow #27, would I apply both of these? Thanks.

@jemandy the patches on the VBO issue are each for a different version of Field Collection. Since it looks like you're running the dev version, you'll want to apply 2658882-fc-27.patch

Reroll of the patch in #9 so it applies cleanly against current dev.

In basic tests this allowed me to re-save nodes which have a field collection based field and have existing content (node) translations (from pre-beta 8). Without the patch I get the same error. With the patch the node saves.

#23 worked for me.

#23 no working for me, i create batch with views for update a field collection, working with one register in batch, but no working with various nodes in the same time, same error with the patch #23 and current beta12+dev

related patch working for me Patch apply

With this patch I get Warning: array_flip(): Can only flip STRING and INTEGER values! in DrupalDefaultEntityController->load() (line 175

#23 works for me.
Can you please merge and release the new version.
Thanks in advance.

i've refactored #23's patch so that it works with the latest revision of dev.

I have the same errors in my log than described in #26:

Warning: array_flip(): Can only flip STRING and INTEGER values! in DrupalDefaultEntityController->cacheGet() (line 388 of /home/XXX/includes/entity.inc).
Warning: array_flip(): Can only flip STRING and INTEGER values! in EntityCacheControllerHelper::entityCacheLoad() (line 84 of /sites/all/modules/external/entitycache/includes/entitycache.entitycachecontrollerhelper.inc).

I was able to remove all the warnings of type array_flip(): Can only flip STRING and INTEGER values! when accessing any pages containing field collection, by modifying a bit the function hostEntity().

  if(is_array($this->hostEntityId)) {
    $this->hostEntity = entity_load_single($this->hostEntityType, end($this->hostEntityId));  
  }
  else{
    $this->hostEntity = entity_load_single($this->hostEntityType, $this->hostEntityId);
  }

The hostEntityId was an array of this format:
Array ( [0] => Array ( [0] => 4833 ) )

But the original error saving node came back.

Modifying the function fetchHostDetails fixed my 2 issues.

          if ($this->isInUse()) {
            $data_array_keys = array_keys($data);
            $this->hostEntityId = $data ? $data_array_keys : FALSE;
            $this->hostEntityRevisionId = FALSE;
          }
          // If we are querying for revisions, we get the revision ID.
          else {
            $data_array_keys = array_keys($data);
            $this->hostEntityId = FALSE;
            $this->hostEntityRevisionId = $data ? $data_array_keys : FALSE;
          }

In case a field collection item is reused in several nodes, we should also set hostEntityId to this list, and not uses the last one with function end().

Reverted to version beta8 solve my issue.

I'm using the latest dev version and still facing this issue

Reverted to version beta8 but note solve my issue.

Patch in #28 applied on the latest dev fixes my issue.

Patch in #28 on latest dev solved the issue for me as well.

Coming back on my comment in #37, the patch didn't solve all edge cases. We still have errors when saving nodes in SOME situations. Still trying to figure out how to fix this bug.

I'm having this issue on a node that contains a user reference, from a view, and then an attached field collection that also contains a user reference. Upon editing the Field Collection, it doesn't save the data that was added to the initial user reference in the node.

So you can update each field individually, and then save, and it works. But if you try and update both fields and save, it only saves the field collection and not the edits to the node form.

Is there anything I can do to contribute to testing or support efforts to fix this patch?

Cheers,

Dave

In my case I have a translated node (2 languages) with Field Collections. With patch #28 fetchHostDetails() does not pick the right host entity ID. But #2701809-6: update collection on a translatable node (i18n) did work.

The latter also has a better software architecture as it strengthens fetchHostDetails() instead of requiring the calling function to have knowledge of how to interpret the content of $this->hostEntityId.

Should be checked against the latest dev. Committed the issue that @Sutharsan pointed to.

Patch #43 worked in my case, using beta13 version.
Thx

After applying patch 29, I was able to save the node successfully, but do encounter the issue when viewing that node as anonymous, i get an issue

EntityMalformedException: Permission to create a node was requested but no node type was given. in entity_metadata_no_hook_node_access() (line 680 of /home/vagrant/.../docroot/sites/all/modules/contrib/entity/modules/callbacks.inc

Without the patch, I am able to view the node no problem.

After the patch I get this:
The entity_id now shows up as [0][0][123] instead of [0][123]. If you look at the test in #43, that is what is happening. Getting an exception: [Warning] Line 388 of includes/entity.inc:
array_flip(): Can only flip STRING and INTEGER values!