Notice: Undefined index: revision_id in field_collection_field_get_entity() (line 1586 of field_collection/field_collection.modu

I just had this exact same issue and fixed it by updating the entity api module to the latest dev release. The whole page was crashing for me because of a later missing function. Updating appears to have cleared up both issues.

Tom

Any updates on this?

After upgrading from 7.x-1.0-beta4 to 7.x-1.0-beta5 I get this error:

Notice: Undefined index: revision_id in field_collection_field_get_entity() (line 1589 of sites/all/modules/field_collection/field_collection.module).

This looks to be the same error (the line number is slightly different).

Nothing was changed in the database except the update.php script was run between the updates.

thanks!
david barratt

Please test this patch and see if it fixes the issue.

The patch just checks to make sure their IS a revision_id before using it, it does not get to the root of problem, which is why their are some collections that do not have revision_id's in the first place.

thanks!

The patch suggested in comment #4 did not work for me. If the "revision_id" index does not exist in the array, then the test proposed in the patch causes the same error the patch is seeking to address. Instead, I used the PHP array_key_exists function to test for the existence of the "revision_id" key.

What version of PHP are you using?

Are you getting the exact same PHP error?

I've never seen array_key_exists() in any Drupal core code, I usually see !empty() or isset(), since neither of those assume that the input is an array, where array_key_exists() assumes that what you are passing in is an array, so you'd also have to have is_array() (which I've also never seen in Drupal Core).

Also, did you run update.php after updating the module?

thanks!

David.

Sorry to take so long to reply. Busy week. Yes, I did run update.php.

I have little experience with Drupal core code, but I don't think that a is_array() would be needed. The preceding line of code makes the assumption that $item is an array, so I think my patch is safe in making the same assumption.

I do not know why the patch failed testing. I cannot find any extra curly brace in my code. In any event, without the array_key_exists check, I get an error from this module.

Thanks.

I was getting this too and ended up fixing it by updating to File Entity 2.x dev version (9 Feb 2013).

Does having a recommended release called unstable7 seem odd to anyone else?

I was experiencing this error with Entity API 7.x-1.0 and Field collection 7.x-1.0-beta5, and the change from #4 worked.

Changing the !empty() check to !empty($item['revision_id']) in patch from #4 worked for me.

Drupal 7.20, Entity API 7.x-1.0+2-dev, Field collection 7.x-1.0-beta5, Devel 7.x-1.3+41-dev.
Patch in #4 fixed this issue for me, but there is a ")" missing on line 1589 of code:
(array_key_exists('revision_id', $item)) {
Besides that the patch works fine and my generated field collections are populated correctly.

The attached patch should fix everyone's problems.

It checks to make sure that both items are present before continuing to the existing conditional.

Thanks!

It works ! Thanks.

works indeed as expected. thanks a lot!

Is the problem still relevant? It does not look like a lot of people have this issue, and I never had it either?

Is this related to #1877800: Field collection Beta7 upgrade fails.? The patch there should fix this as well? (just a guess)

I had this issue too by copy a fc from one to another entity. After hours of fiddling around i found this issue.
Works perfectly now after applying patch from #16.
Thanks so much!!

Confirm this bug, +1 to RTBC and additionally better to commit #1852112: Invalid field value with devel_generate

As stated in #4, it seems like this solution doesn't get to the root of the problem.

Can anybody provide steps to reproduce the error?

@Jehu how did you copy a field collection item to another entity?

This happens after updating field_collection module to latest version (7.x-1.0-beta7, in my case from 7.x-1.0-beta4) and having field_collection_items already in database.
I ran update.php of course.

I think it is a problem with the updates that add support for revisions which do not create separate revisions for field collection items even when the host entity has several revisions. This should be fixed in #2000690: Deleting revisions via node_revision_delete wrongly deletes entire field collection and if I am right the issue in this ticket will be solved as well.

Let's stop the bleeding. #1822844-16: Notice: Undefined index: revision_id in field_collection_field_get_entity() (line 1586 of field_collection/field_collection.modu fixes the issue and is a very simple solution.

Same issue with 7.x-1.0-beta7, on multilingual website. Patch provided above did the trick for me. Thanks

I get this issue when delete field collection programmatically from node.
Patch works. It hides errors.
But if print node object you can see that field collection field is not empty.
Better would be prevent generating of non existing field collection values.

+1; removed the warnings.

Cross-post: I found that while creating field collections programmatically following #1106182: Creating field collection programatically, if I use:

 $field_collection_item->save();

I get the error mentioned in this issue.

However, If I change that line to the following the error goes away.

  $field_collection_item->save(TRUE);

Maybe this could be helpful to others to track-down if there is something really wrong with the underlying code or if other modules are incorrectly saving their field collections.

Sorry heddn but I'm not committing this. A notice message isn't what I would call bleeding and I think it's best that it does say something when a revision of an entity is loaded but the field collection item in the object is the field collection item's current revision instead of the revision that was supposed to be loaded. Depending on the operations that are performed on it (ex. $field_collection_item->deleteRevision() ) there could be unintended changes to data.

As per the discussion it seems there are many ways the data can end up in a state to trigger this message. The causes should be fixed and updates made to repair the data that was left in a bad state because of them. Then if there are still any other ways the data can get messed up like this there will be a symptom to show there is a problem and it won't just load different data than was requested without saying anything about it.

I tried to duplicate this error message by deleting a field collection item programmatically as a.milkovsky brought up. I used $item->delete() . The result was correct for the current revision of the node but for previous revisions that had the field collection item I get the following error when viewing the revision:

Notice: Trying to get property of non-object in field_collection_field_get_entity() (line 1653 of /home/jmuzz/devel/drupal7/sites/all/modules/field_collection/field_collection.module).

Understandable since the object doesn't exist. It might make sense to remove the references to it in all the node's revisions, but I wonder if deleting field collection items this way (or with entity_delete etc.) should even be allowed. I don't think it is supposed to be possible to edit node revisions other than the current one. The UI doesn't support that and trying to do it programmatically can have strange results. For example if you load an old node revision and then save it that revision becomes the current, published revision, even though there are still revisions after it.

We should do away with public access to $item->deleteRevision() and only let a revision of a field collection item be deleted if a revision of its host is deleted. A field collection item shouldn't be deleted unless it only exists in its host's current revision or its host is being deleted. Letting these things happen implicitely makes changes to a node's past revisions. Though these are operations that entities usually support, a field collection item is meant to act as data in its host and not as an independent entity.

Making these changes would be a good start to getting some of the revision related problems under control.

Does anybody agree or disagree with this?

Patch in #16 solves the notice.

Case:
- Create a node (do not publish it)
- Create some revisions (do not publish it)
- Change the state multiple times (via workbench moderation widget) (do not publish it)
- Publish the node via the workbench state moderation state widget
- Now revert back to the revision before state changes
- Unpublish the published revision
- Remove this unpublished revision
- Now visit the node edit page: presto: error.

So this patch does not fix the cause for me. (seems like a workbench moderation issue)

there's steps to reproduce so easy to write tests

We're facing the same problem while running tests in Jenkins

I have following error message and it looks like it is related to this issue

Notice: Trying to get property of non-object in field_collection_field_get_entity() (line 1679 of modules/contrib/field_collection/field_collection.module).

Notice: Trying to get property of non-object in field_collection_field_get_entity() (line 1679 of field_collection.module).

I get the above error when a field collection field is in a view and displays a row with this field value empty. The field collection field labels are displayed even if I select to hide the field when empty.

I faced same issue #16 works for me thank you.

Thanks for the working patch in #16.

Redone the patch against the latest dev.