On unpublished nodes, when saving, it throws a fatal error: Unable to save a field collection item without a valid reference

Hi Nedd,

Speaking in IRC, it has been suggested that this might be the solution for my problem as posted here: https://drupal.org/node/2088117

I get no errors from field collections however, and am not sure the patch will solve my problem... can you confirm that it might be related or otherwise if possible?

Hi,

I have tested this patch in #4, and it does indeed solve my problem! I ma in no position to comment on the security of the patch... however functionality-wise... this solves my problem perfectly. The nodes are now staying as published, promoted to front page, etc. So long as this patch passses security checks ETC, this needs to be implemented into next version IMO.

Thanks for the patch nedd!

fixed typos

Hand patch: love to have the maintainer look into this issue and if this patch is security-ready. I have been running into this issue all over the place while using field_collections to create datastructures for use with the Salesforce module to sync to a complex SF implementation. I have re-rolled the patch against commit 0fd332e.

I applied the patch but I still get the error...
exactly same symptoms:

-weird "Unconnected field collection item"
-error then saving
Exception: Unable to save a field collection item without a valid reference to a host entity. in FieldCollectionItemEntity->save() (line 477 of /var/tmp/sypb/www/git/webdev/htdocs/sites/all/modules/contrib/field_collection/field_collection.module).

note that the error is on line 477 instead of 485 as for neddstark, but I don't think it's relevant. I'm running 7.x-1.0-beta5, so...

I noticed that if I save another revision of the host node, the problem disappear (and the title is no longer "unconnected field collection entity"

I think I'm experiencing the same issue as pbattino, but believe it's probably not related to the issues others were having.

In my case, I can see that the field collection reference field on the host entity isn't saving the correct revision ID for the field collection, so the entity field query in fetchHostDetails() obviously fails. Guessing that it's some issue with saving revisions so that the host entity's field referencing the field collection isn't updated.

The patch works but I'm not sure what's the security implication here. Can someone review?

Is this just an issue for beta5?

I tried it with the most recent version by creating an unpublished node with a field collection item and then going to the edit field collection page. The page title was correct and the field collection item was saved without error upon submitting the form.

Can anybody provide steps to reproduce this with the latest version?

Hi
This is still a issue in beta8 and also in current dev.

It seems to happen when you have a published node and you try to edit a field collection from one of it's revisions.

Normal Drupal behaviour you can not edit a revision while one is published but if you use a publiction workflow module like workbench moderation you have the ability to have a published node and a saved revision which you can edit.

So when you try to edit the field collection of a nodes revision using the path field-collection/[field-name]/[entity_id]/edit you run into the problems described in this post.

This does not seem to be an issue if you edit the field collection from nodes revision form.

The patch above does not work for this case.

But the first solution mentioned by nedstark seems to work
if (isset($field_collection_item->item_id)) {
$field_collection_item->save(TRUE);
} else {
$field_collection_item->save();
}

When this first solution is used I am able to save the field collection using the edit link and it only affects the particular revision I am working with. So the edit link does bring back the correct information and saves the field collection to the correct revision.

Maybe we just need to identify the condition where the edit link is coming from a revision of a published node with a revision that is currently active and make sure fetchHostDetails() returns the correct information in this case.

I'm seeing the same issue on the current version of field collection (7.x-1.0-beta10). I'm trying to update many field collections from their associated nodes in an update hook, and run into this intermittently. The latest patch did not solve the problem for me, but the earlier solution by @nedstark (great name!) in #2 did work for me.

Changing status.

It's not good to skip saving the host when the field collection already exists. When the data inside the node changes, values such as the "Last changed" timestamp should be updated on the node. The save function is only supposed to be called with the TRUE argument when it's known that the host entity is getting saved anyway.

This may be similar to the problem that was originally preventing workbench moderation from working with this module altogether. The thing is workbench moderation will save a node twice when creating a new unpublished revision of a node: Once to save the new revision, and again to make the published revision the currently active one for viewing. A check was added to field_collection_field_update to determine when this was happening, but that only applies when the data is being edited through the embedded form on the node edit page. A similar check could possibly solve this problem when the edit pages for individual field collection items are used.

Hi,

I have re-rolled the patch from #7 against the latest 7.x-1.x dev

I was not sure what is the status of the issue and if this one is solving it or not. Do we need to do something else?

@lachezar.valchev thank you for rerolling that patch it works for me. Also for me it was on published nodes as well, I believe it was because I was using the group module, which similar to other modules has its own content access permissions.

I can confirm that this patch solves this issue (in our case we got this error with a migrate migration). The error didn't occur on the vm of one of the developers, but did occur in another VM (although same project, git based). I know this is a bit vague, @jmuzz therefore it might be difficult to reproduce, there is some external factor, we spend some time on thinking what this might be, but couldn't fin it. So for now we go with this patch.
And it might be useful to apply this patch to the latest dev

Sorry @neddstark, I accidentally gave credits to wrong person.

Patch #19 worked for me too.