PHP Fatal error: Unsupported operand types in file_entity.file.inc

I stumbled into this error on the same line when deleting a field collection that contained an image (entity_delete_multiple). It seems that the file was deleted from the file_managed table but still existed in other tables (like file_metadata). I expect that when #2075791: Removing field collection item row with image field retains uploaded image is resolved then this won't be a problem, at least not for my case.

thanks for this. I was getting WSOD on the transliteration page, dmin/config/media/file-system/transliteration.

Experiencing the same as #2. But the proposed solution is not very clear: Line 102 of which version? Could you provide a patch?

I have put fix into a patch.

Patch from #4 seems to solve the problem in my case!

same problem with WSOD on transliteration submit
patch #4 fixed the issue, thanks!

I had the same error when trying to execute initial transliteration of files:
"Unsupported operand types in file_entity.file.inc on line 102"
The patch in #4 resolves this for me
Drupal 7.38
File Entity 7.x-2.0-beta1+30-dev
Transliteration 7.x-3.2
I guess this can be set to RTBC

+++ b/file_entity.file.inc
@@ -95,7 +95,16 @@ function file_entity_file_update($file) {
+    if (!isset($file->original->metadata)) {
+      $file->original->metadata = array();
+    }

I don't understand how $file->original could not have the metadata array defined. It should always be loaded via file_load().

The patch in #4 resolves this for me as well.

yes definitely it's a serious bug. I faced it when i try to migrate file from local file system to S3 by. And of-course patch #4 works for me too. we should take it to higher priority or increase it's level. So that it would be fixed in module too.

The patch works, and although I can sympathize with Dave in looking for a clearer picture of the issues in behind, this workaround makes my setup work where the release does not. Since I could neither see any potential issue in turning a potential NULL into an empty array, I would really like to remove the "patched" flag from the setup in question.

Tried #4 patch.

Got this error:
5679 Error Creating default object from empty value File /var/www/[redacted]/htdocs/profiles/cosc/modules/contrib/file_entity/file_entity.file.inc, line 105

Looking at the code its because object original to whom metadata is a property has not been initialized yet.
@see http://stackoverflow.com/questions/14806959/how-to-fix-creating-default-...

Response #10
My entry context is I am migrating file entities using drupal.org/project/migrate

This patch fixes #4 patch.

I'm still saying that if this bug is happening, it's because something else is not properly loading an existing file record using file_load() and then calling file_save() on it. It would be something that needs to be addressed in the calling code, because other things could be going wrong.

response #15.
I am not familiar with the file_entity codebase. The issue is the $file object at this point does not come with a populated original property ($file->original) . What should the original property contain? is it the file object that is about to be updated? If so well in my context during the file migration process this $file->original object is not created yet.

Fixes patch #14 because it had the wrong condition check.

Fixes patch #14 because it had the wrong condition check; apparently i didnt hit save..

Chriscalip's patch at #19 worked for me. I've been getting the Unsupported operand error when using the S3 File System Migrate module to migrate image fields from the Drupal file system to Amazon S3. I thought the problem was between S3 File System Migrate and File (Field) Paths, but with this patch everything plays nice together. Thank you!

Getting this error when we do file migration from D7 to D7

#19 worked to me as well. I've just made some code style cleanup on that patch.

#22 worked to resolve my issue

I've just come across this error when adding Transliteration module to an existing Drupal Commerce site and the error appeared when trying to transliterate the existing files.

The patch in #22 worked a treat for me so I'd love to see it included in the live version.

I can confirm that #22 fixed my issue with Transliteration just like Ollie222 said.

Also confirming the patch in #22 worked on a Drupal Commerce (Commerce Kickstart v7.x-2.40) site that had a transliteration error, as per #23, #24 and #25.

Patch in #22 worked for me as well, thank you! I was also trying to run transliteration on an existing commerce install and this took care of the problem.

reviewing this now, waiting for test results

in 7.x-2.x dev