Media entities : Cannot access empty property in field.attach.inc line 677

Having similar issues. I'm trying to view images from the default image field in D7 from the media browser and receiving the same fatal error.

[Copied from #1015554: Removing an image from file_field: Cannot access empty property in field\field.attach.inc on line 677 by @morningtime (marked as duplicate)]

I have a node with a file-image field and several images. I'm removing one image, this works. But clicking 'save' gives this error:

(white screen)
Cannot access empty property in C:\Inetpub\wwwroot\123.net\modules\field\field.attach.inc on line 677

Next time I edit the node, the image thumbnail/preview is gone, but the image is still listed on node/edit. Trying to remove & save keeps showing above error.

More from the logs:
Unable to generate the derived image located at private://styles/thumbnail/private/upload/page/large/daviddawson_photocostinradu_cr_20071106_0084-613.jpg.
The image is gone, i.e. deleted from the file system, but not from the node/file table.

Also:
The file was not deleted, because it does not exist.
Obviously.

I temporarily solved it by manually tracking the file-node relationship in the database, and removing it there.

The errors are different, but there's another image module issue open at #937100: Image/file module passing form values to file_load_multiple() (which itself appears to have several unrelated errors on it).

Could people check admin/reports/dblog for PHP errors and see if there are additional errors in there?

Same issue here as comment #1.

Related errors:

Notice: Undefined index: field_name in field_attach_load() (line 673 of /modules/field/field.attach.inc).
Notice: Undefined index: field_id in field_attach_load() (line 674 of /modules/field/field.attach.inc).

I'm having the exact same issues (see #5 above). It seems related to the Media module, because this only happens when that is enabled. However, I tried this on a fresh install with nothing but Media enabled and everything worked fine. So maybe there is an issue with sites that upgraded from previous D7 and/or Media module versions?

An $instance without a 'field_name' property means something is seriously wrong.

Hard to say anything clever without reliable steps to reproduce, though :-(

Same experience as #5 and #6. Definitely from Media module, and I too need to reinstall from scratch with latest module versions on clean database.

For now, bumping over to Media module, then.

Once this is tracked down, we'll see if something needs to be fixed in core.

I have the same prob

Hi All

Been doing some investigating on this issue and it seems to be that the object structure of the media being passed does not contain the field_name property. Drupal all over the place makes calls like:

$field_name = $instance['field_name'];
$entity->{$field_name};

Because obj->field_name does not exist in the media object in this current scenario, $field_name contains nothing (or an empty string) thus $entity->{$field_name} is making a call to a empty property (e.g. same as doing 'object->').

The media objects dose have a field name property within the 'file' array. If you add something like:

$field_name = (isset($instance['field_name']) ? $instance['field_name'] : $instance['file']['field_name']);

to line 673 of field.attach.inc::field_attach_load and in similar places the code starts to move along alright (though I have not added the hack all the way yet to see if it would truly work).

Another thing I noticed, and I'm not sure if it is because of this bug or could happen in other places, is that field.info.inc::_field_info_prepare_instance_display() line 355, $display['settings'] is not allways being set correctly to an array. Thus the concatenation fails. This seems to be because $display already contains the key 'settings' but it is not set to anything and using += will not change this with an empty array() as a value. It might be an idea to explicitly check if 'settings' is an array and if not explicitly set $display['settings']=array().

Hope that helps. I'll keep digging when I get the chance.

Oh I forgot to mention. If you have this issue you can get your site semi working again by changing media.module::media_load() (about line 527) from:

function media_load($fid) {
  if ($files = entity_load('media', array($fid))) {
    return array_shift($files);
  }
  return FALSE;
}

to

function media_load($fid) {
  return FALSE; //Temp workaround
  if ($files = entity_load('media', array($fid))) {
    return array_shift($files);
  }
  return FALSE;
}

media_load is where the break begins so this works around the issue.

re @magicmyth #11 :
Same as $instance['field_name'] not being set, $display['settings'] not being an array needs to be fixed up the callstack, on the caller side. We cannot clutter the Field API code with checks that the data structures are well formed all over the place. That's summed up by the "we don't babysit broken code" motto in drupal coding principles.

That's summed up by the "we don't babysit broken code" motto in drupal coding principles.

I totally agree ;) If I have time I'll try to find out why the $display being passed contains a 'settings' key with no array. If I'm lucky it will go away if the media object missing field_name is fixed.

Might be a duplicate of #1028230: Fatal error: Cannot access empty property in field.attach.inc.

Anyone encountering this error : please help by following the instructions in #1028230-9: Fatal error: Cannot access empty property in field.attach.inc

OK, so it turns Media module is indeed one identified source of the error, by calling Field API with $entities from which no bundle can be extracted (entity_extract_ids() returns NULL for the bundle). Thus, bumping back to Media.

Now, some other modules might be doing the same. #1028230: Fatal error: Cannot access empty property in field.attach.inc will debate the best way for Field API to handle those cases (how to fail, how to provide meaningful info about the module at fault)

So, for people having "Cannot access empty property in field.attach.inc" :
- If you are using Media module, this is you issue.
- If not, go over to #1028230: Fatal error: Cannot access empty property in field.attach.inc, and please follow the instructions in comment #9.

subscribe

I transfer my message from a duplicate entry to this issue:
(dupl-url: http://drupal.org/node/1028886)

Description
Accessing the media-tab results in
- Fatal error: Cannot access empty property in /modules/field/field.attach.inc on line 677

Env:
- Drupal 7.0
- Media 7.x-1.0-beta3

Additionally (might not be related) on the modules-page I get two notices
Notice: Undefined index: field_name in field_attach_load() (line 673 of /modules/field/field.attach.inc).
Notice: Undefined index: field_id in field_attach_load() (line 674 of /modules/field/field.attach.inc).

@leap #18 : yes, those errors are related - it's actually a chain of errors :

Notice: Undefined index: field_name in field_attach_load() (line 673 of /modules/field/field.attach.inc).
Notice: Undefined index: field_id in field_attach_load() (line 674 of /modules/field/field.attach.inc).
Fatal error: Cannot access empty property in /modules/field/field.attach.inc on line 677

It's because there's no field_name that $queried_entities[$id]->{$field_name} causes a fatal error.

The crux of the problem is that _field_invoke_get_instances() fails to return a proper array of $instances, because we call it with $bundle = NULL. That's the bug Media should solve.

I think the issue here is that media module uses the field "type" in {file_managed} as an entity key but media doesn't handle files that have been uploaded before installing the module and leave the field "type" as null.
So I think the solution here is to take into account files that have been uploaded before media.

Patch in #20 solves this issue for me ...

subscribe

Subscribing.

Subscribing.

Subscribing.

Doing this without a batch runs the risk of exceeding memory limit an execution time on sites with lots of files that enable media module, having said I don't see a way around this on enable, and those sites are likely using drush for enabling and updates.

Couple of things apart from that - the indentation in the first foreach is a bit off.

Also it'll be more efficent to do file_load_multiple($fids); then the foreach (in fact you might be able to do file_load_multiple(FALSE) to get the whole table contents and skipping loading the fids separately).

Subscribing.

Hm. Entities having sometimes a bundle and sometimes not is tricky.

Processing all existing files on enable : right, that's tricky in one pass. Possible workarounds :
- on enable, just display a warning / error message if there are existing 'untyped' files (possibly after having processed a reasonable amount of files, to save the hassle on small sites ?)
- add a check on the 'reports' page, with a red entry indicating that some files are still to be processed, and offer a link to a batch-API processing page.

locale's .po files importer does trigger a batch API process on module enable, BTW. But it is probably tied to the 'admin modules' form (I'm not where I can easily check right now), and wouldn't work with drush.

@takeova : With which file do I merge your patch file? media.install?

Thanks.

Subscribing

The patch at comment #20 was ok to fix the problem for me. Thanks
(You have to run the update.php to enable)

subscribe
error go away with patch
but now new errors

Notice: Undefined index: media in media_browser_list() (line 183 of /www/i/id/mysite/sites/all/modules/media/media.browser.inc).
Warning: array_keys() expects parameter 1 to be array, null given in media_browser_list() (line 183 of /www/i/id/mysite/rico.d/sites/all/modules/media/media.browser.inc).


#20 with comments applied from #26.

Subscribing

I have no idea why patch is rejected, can someone help with this?

My site isn't very far along, I've been developing it as a subdomain so I could see it live. But I decided to set it up on localhost before attempting a patch. And no error! There were actually a couple errors that I have in the live version that I don't have on the localhost site. So I'm not sure what conflicts I set up that give me this message. What is the best practice way to go about building a drupal site? Chronicle every change so that when the error pops up I can isolate it better? And hopefully resolve it? Before I move the subdomain to be my production site I need to have a good way of continuing to build without risking the white screen of death. I am registered fro DrupalCon next month so I hope to learn some of this. Thanks

subscr

re #37 cartagena,
If you have upgraded your Drupal version along the way, we found the same thing up at #6 and #8 - this error got into the database early on, and a clean install was required. Personally, I have now been making a copy of my database with phpMyAdmin before installing or upgrading any developing/risky modules. With Drupal and new modules being developed simultaneously it has been a rough ride; you'll find that once D7 and modules are stable, you won't have such a problem.

#33: patch_101-updated.patch queued for re-testing.

subs

Thank you very much, Scott J (#39). I have upgraded along the way--I'll do a clean install and be more careful until things are stable.

Scott J, when you make a copy of your database using PHP, do you copy the structure as well as data with the intent of dropping and replacing the entire database if there is a problem? Thanks

sub

#33: patch_101-updated.patch queued for re-testing.

sub

subscribe

I was receiving this same error (Media entities : Cannot access empty property in field.attach.inc line 677). What I found triggered it was modifying the Media Display Type from list to thumbnail. List mode works fine, it is only if I switched to thumbnail view would I see the error (when viewing the media tab at admin/content/media).

I had to manually switch back to list mode the following sql statement:

 update media_list_type set type = 'list';

Attached is a screen shot for clarification on what triggers error.

#33: patch_101-updated.patch queued for re-testing.

#49 worked for me

Hi folks,

Can someone explain to me exactly how to reproduce this with 7.0 and Media HEAD? Like starting from a clean Drupal install?

Thanks!
Jacob

Actually, when I did a clean install and set up media module first, I didn't get the error at all. I then went on and enabled/configured my other modules and still no problem.

@JacobSingh - I'll perform some testing to assess how to replicate. I believe a fresh copy of D7 with Media won't create the bug. My guess is the bug will only arise IF files have been uploaded to the directories specified in the Media configuration prior to installation. Will submit follow up post after confirmation.

I'm downgrading if it doesn't affect new installs. Still would be good to fix though.

@JacobSingh :
See comment #20 and followups.

In short : Media seems to break on setups were there were uploaded user files prior to Media being enabled.
Apparently, this causes media entities to be sent to field API without a 'bundle' property, which badly breaks in various places within Field API. #1028230: Fatal error: Cannot access empty property in field.attach.inc has a core patch to have Field API break in a nicer and more tale-telling way when hitting ill-formed $entity objects.

Patches #20 and #33 provide a hotfix for Media, however that won't scale where there are many pre-existing files. See #26 and #28.

I have no clue about the report in #49, which seems to be a different issue.

Okay, makes total sense.

How should we handle this? Do we fill the type field in file_managed when media is installed? Not great because if someone has a ton of files this could get ugly... Do we do it "on-demand"... hard because we don't know when it is being demanded.

Any insight here?

-J

Alternately, we try to do a couple hundred upon install, and then show a persistent dsm to admins asking them to run some batch processes which does the rest?

Also, back to crit.

re #59 : sounds like the best solution at hand. + that's what I proposed in #28 above ;-)

Manually switching the list type back to list also worked for me.

Now eagerly awating a resolution.

subscribe

subscribe

Subscribe.

Looks like #33 has a typo: foreach ($files as $file => $fid) should be "$fid => $file"

Okay, had a nice longish train ride to do this.

Beware: I slept 3.5hrs last night and am running on pure visa & immigration related stress. I don't even remember my own name anymore.

Please review.

Hope you've got a bit of sleep and that the visa/immigration stress has been resolved...

I want to apply this patch but it is much more complicated than the first-ever patch I applied a couple days ago. I did not have a problem with media when I did a clean install. However, on the site I'm working on now (also 7) I didn't want to start from the beginning so I installed it and am now getting the above messages but I don't know what to do with this patch...I'm not a programmer and when it's so complicated I don't know where to begin. Please advise what I need to copy where. I think I understand that the + means a line to add and the - a line to delete? Thank you.

cartagena,
Yep, + means a line to add and the - a line to delete. The other thing to look for are the 'Index' lines, which tell you which file to edit, and the line numbers which point you to the correct location within the file. It's not so easy if you're trying to do large patches manually, but it can be done. When I need to, i'll use MS-Word or Open Office to select and delete all the + signs in one go.

It's worth spending some time getting familiar with applying patches from the command line (or there may even be gui utilities that can do this), see http://drupal.org/patch/apply for details. If you're on windows you can set up cygwin to get a cli environment. This is many, many times easier than trying to make changes by hand line by line.

I did not test the patch, just from a visual patch review - including obvious "sleep depravation" artifacts ;-)

+++ media.admin.inc	24 Feb 2011 14:22:29 -0000
@@ -605,3 +605,65 @@
+  return;

?? :-)

+++ media.admin.inc	24 Feb 2011 14:22:29 -0000
@@ -605,3 +605,65 @@
+  sleep(1);

?? :-)

+++ media.admin.inc	24 Feb 2011 14:22:29 -0000
@@ -605,3 +605,65 @@
+  if ($context['finished'] == 1) {
+    $context['success'] = TRUE;
+  }

Useless. Batch API automatically populates the $success param of the 'finished' callback.

Powered by Dreditor.

Thank yched

Thank you, Scott J and catch...fortunately I'm on a mac so I guess I do it the old-fashioned way!

on a mac, it's even easier! :)

Just do this:

cd /path/to/media/module
patch -p0 < /path/to/downloaded/patch.patch

@cartagena - should be easier on Mac than Windows - http://drupal.org/node/60818

Chalk another one up for mac! Thanks!

You can even skip the download by using

curl (url of patch file) | patch -p0

+  // Updates the type field for the first MEDIA_UPDATE_RECORDS_ON_INSTALL files.
+  if (count(media_type_batch_update(MEDIA_UPDATE_RECORDS_ON_INSTALL)) < MEDIA_UPDATE_RECORDS_ON_INSTALL) {
+    // Okay, so there is a tiny logic error here.  If the user has exactly 
+    // MEDIA_UPDATE_RECORDS_ON_INSTALL files, this will return true but doesn't seem worth another query.
+    // This variable will cause a persistant nag message to appear on every page
+    // for the administrator, urging them to finish the process.
+    media_variable_set('show_file_type_rebuild_nag', TRUE);
+  }

This very much feels like sloopy programming for me. In addition, it is incorrect as media_type_batch_update(MEDIA_UPDATE_RECORDS_ON_INSTALL) should be media_type_batch_update(FALSE, MEDIA_UPDATE_RECORDS_ON_INSTALL).

I think this fixes the bug (w/o actually testing); I hope it assuages DamZ's feelings too. It's not just a feeling, it is sloppy programming under pressure w/o sleep, but thanks for sharing your opinion there.

I'm too busy to do any more than this right now. I had a train ride and this was annoying me since it affected so many people (other than me), but this issue isn't even an itch that Gardens (my paying job) has at all. If someone else wants to get the kinks out and/or refine it further, please feel free.

Here is a proposal:

* Removed the fuzzy logic from media_enable().
* Make sure nagging messages are only displayed once, and only display them on admin pages.

Tested the different cases. Seems to work fine in all cases.

@Damien Tournoud, are you sure the patch is properly formatted?

I applied it against 7.x-1.x-dev and received the following errors:

patching file b/includes/media.variables.inc
Hunk #1 FAILED at 148.
1 out of 1 hunk FAILED -- saving rejects to file b/includes/media.variables.inc.rej
patching file b/media.admin.inc
Hunk #1 FAILED at 604.
1 out of 1 hunk FAILED -- saving rejects to file b/media.admin.inc.rej
patching file b/media.install
Hunk #1 FAILED at 5.
Hunk #2 FAILED at 55.
Hunk #3 FAILED at 141.
3 out of 3 hunks FAILED -- saving rejects to file b/media.install.rej
patching file b/media.module
Hunk #1 FAILED at 67.
Hunk #2 FAILED at 427.
2 out of 2 hunks FAILED -- saving rejects to file b/media.module.rej
patching file b/media.types.inc
Hunk #1 FAILED at 252.
Hunk #2 FAILED at 267.
2 out of 2 hunks FAILED -- saving rejects to file b/media.types.inc.rej

subscribe

@zabelc, try patch -p1 instead of patch -p0.

Subscribing

patch #78 & #79 combined solves the problem for me AND don't forget to run update.php

@catch, thanks for the pointer, I was able to deploy the patch.

It did get me a bit farther, but unfortunately, now I get the following error while downloading module updates:

An AJAX HTTP error occurred. HTTP Result Code: 200 Debugging information follows. Path: /batch?render=overlay&id=22285&op=do StatusText: OK ResponseText: {"status":true,"percentage":"100","message":"Completed 1 of 1.\u003cbr \/\u003e"} Fatal error: Cannot access empty property in /home/patcms/public_html/modules/field/field.attach.inc on line 677

I'm going to try applying the other patch as well to see if that fixes matters.

Sub

subscribing

Comitted #79. Thanks! Let me know how this works.

I get this error when I try to go to the Media tab. I upgraded to dev and am still getting this issue. I ran update.php and flushed the cache, anything else?

Also, my issue may be related to #49 - I could see the tab until I clicked thumbnail view.

Nevermind! I went to the Configuration and clicked "Rebuild type information for media" - now it works. Thanks :)

Finally did this last night here in Chicago, all is working well. Great presentation the other day, Jacob. Thanks!

I have the same issue but i cant find that "Rebuild type information for media" link.
Can you please tell me where it is? Or may be post the relative URL?

Here's a screen shot of where it is on the menu bar (I am using the admin module for my menus, not the D7 core menu)

If you click on Configuration in the D7 core menu, it appears in the MEDIA area. Go here in your site to activate: /admin/config/media/rebuild_types

I didn't upgrade, have never used Drupal 6, and had the same problem, once I installed Media Module and tried thumbnail view.

There were two images uploaded before I installed Media Module, then I added a third. There were no display problems til I went to admin/content/media/thumbnails as #49 described, Then I got the two field_attach() errors lines 673 and 674 and my home page showed a fatal error line 677.

Applying "update media_list_type set type = 'list' in phMyAdmin made the error go away.

My front page and all other content pages rendered fine now and I could to content/media without an error (showing the media items in list mode)

I could edit the third media file (a png), added after the media module was enabled, and the second file added before (also a png) but not the first, which gave an error (a jpg but not necessarily related).

Next I tried to delete the first file and got lots of line 673 674 errors and "file in use" but when I removed it from the blog node I was indeed able to delete the mage.

(although I did get an eror:
"An illegal choice has been detected. Please contact the site administrator" from
http://xxxx/admin/content/media
Message Illegal choice 3 in files element. )

However once the bad image was removed I could now go to admin/content/media/thumbnails without an error.

When I re-added the image the thumbnail generated correctly and I could insert it into a field just fine.

SO. the conclusion is that installing Media Module when there are already images uploaded does not build the thumbnails and deleting and readding the faulty images works.

I am not a module coder and brand new to this, so hope this helps and is somewhat accurate.

subscribe.

Before deleting and re-uploading all your images, you should first try to rebuild the image database, by going to this page: /admin/config/media/rebuild_types it's also in the Configuration page under Media.

subscribe

There is no link for rebuild_types... There are some serious issues w/ this module in D7... I know it's a beta.. but it's kinda frustrating that this was so hyped up at DrupalCon Chicago, only to be unusable....

NM... turns out a drush updatedb needed to be run, then the rebuild types link shows up.. once you've fired that off, everything seems to be working fine.. might be a good idea to push these operations into the .install file? Seems like some steps that could be automated when the module is installed...

subscribe

Does this merit a beta4 release?

Me too. Above patches failed to resolve the problem. I am disabling the media module on my site because the error interfered with the search function (wtf?)

[Fri Apr 01 20:04:12 2011] [error] PHP Fatal error: Cannot access empty property in /home/www/parts-unknown.org/drupal-7.0/modules/field/field.attach.inc on line 317
[Fri Apr 01 20:04:39 2011] [error] PHP Fatal error: Cannot access empty property in /home/www/parts-unknown.org/drupal-7.0/modules/field/field.attach.inc on line 317
[Fri Apr 01 20:05:58 2011] [error] PHP Fatal error: Cannot access empty property in /home/www/parts-unknown.org/drupal-7.0/modules/field/field.attach.inc on line 317
[Fri Apr 01 20:12:46 2011] [error] PHP Fatal error: Cannot access empty property in /home/www/parts-unknown.org/drupal-7.0/modules/field/field.attach.inc on line 317
[Fri Apr 01 20:17:12 2011] [error] PHP Fatal error: Cannot access empty property in /home/www/parts-unknown.org/drupal-7.0/modules/field/field.attach.inc on line 317
[Fri Apr 01 20:19:27 2011] [error] PHP Fatal error: Cannot access empty property in /home/www/parts-unknown.org/drupal-7.0/modules/field/field.attach.inc on line 317
[Fri Apr 01 20:20:47 2011] [error] PHP Fatal error: Cannot access empty property in /home/www/parts-unknown.org/drupal-7.0/modules/field/field.attach.inc on line 317
[Fri Apr 01 20:22:34 2011] [error] PHP Fatal error: Cannot access empty property in /home/www/parts-unknown.org/drupal-7.0/modules/field/field.attach.inc on line 317
[Fri Apr 01 20:25:37 2011] [error] PHP Fatal error: Cannot access empty property in /home/www/parts-unknown.org/drupal-7.0/modules/field/field.attach.inc on line 317

Did you try to go to the page which rebuilds type information like several other people have suggested?

Did you clear your cache after patching? (something you should always do anyway)

@RavenHursT:

It actually does run at install time. But we made it so it would only do 100 or so then. If you had more than 100 files, it will prompt you to visit the page to rebuild all of them with a progress meter.

@JabocSingh

hmm.. odd.. cause this is a fairly new D7 install and there's only, like 5 images on here.. so yeah.. doesn't seem like it ran on install.

#79 worked great for me, cheers

#20: patch.patch queued for re-testing.

Are you using the beta-3 release or the -dev version. I don't think the fix has been included in a release yet.

Hi all I ve got the same error
Fatal error: Cannot access empty property in ..modules/field/field.attach.inc on line 677
I solved the problem just by disabling Field Slideshow the field ui and field group modules

Hello, this is my first comment, I have the same issue ("Fatal error: Cannot access empty property in /----/modules/field/field.attach.inc on line 677" ) I read all posts, and I downloaded the Soft Eclipse for PHP, and I follow the steps to patch a file, but, what file I have to pacht? media.api.php? I need some help about this. I don´t know what is the file where I must to apply the patch, I need to know the directory.
( Sorry for my english Im on my 3rd degree. :P)
thanks, !

Request: Could we get an update to repo and a confirmation on this thread? What's the status of this issue? Thanks!

This bug might be related to: http://drupal.org/node/1023814
I also get this:
# Notice: Undefined index: field_name in field_attach_load() (Zeile 673 von modules/field/field.attach.inc).
# Notice: Undefined index: field_id in field_attach_load() (Zeile 674 von modules/field/field.attach.inc).

@JocobSingh: I think you were asking me... I'm using 7.x-1.x-dev patched w/ your patch...

subscribe

subscribe

Since this issue apparently is still not fixed, my experiences of today with Media + Media gallery:
- installed Media again, and gave me no trouble. Then I installed Media Gallery, which gave me WSOD, so I removed it again.
- went on with my work, not using Media yet, and got the error 'Fatal error: ..on line 677' on the bottom of my screen, e.g. on admin/reports/event/1234.
- remembered this issue, and the issues of rebuilding the file_managed-table, so I started admin/config/media/rebuild_types, which gave me the hopeful message "1995 files identified and given a type. All files in the system have been assigned types. Media installation complete."
- refreshed page admin/reports/event/1234, and the error has gone.
- ran update.php and gave me no Media-update. Strange because I remember there were(?) on previous attempts. Or was it already done during rebuilding?
- checked patch #79, and it is already in (which was reported as fixed in #88).
- installed Media Gallery, giving me again WSOD, so I removed it again. I reported it in #999530: Upgrade Media Gallery for Media's new File Entity (EntityFieldQueryException: Field storage engine not found).

So, apart from not giving me a 'nag' message for rebuilding the file-types, this seems OK.

subscribe

Still getting this error.

subscribe

There are too many different issues/bugs in this issue.

It looks like, except the fairly critical #999530: Upgrade Media Gallery for Media's new File Entity (EntityFieldQueryException: Field storage engine not found), only #117 remains, which seems to be about updating from earlier versions; i.e., 'media' entity to 'file' entity. Please create a new issue for that.

Apparently, the switch of entity types is already worked on and discussed in #1086958: Switch from Media Entity to File Entity

EDIT: Only latest media_gallery code doesn't account for that major change yet.

Bookmarking, greetings, Martijn

updating to the latest dev and the error have seemed to stop
(I also installed entity module but its probably unrelated)

Latest dev (Jun 29th) changed the error for me to Call to undefined function file_view_file()

...and then I wondered why my "File Entity" module was disabled, so I enabled it and things clicked back online.

Now I see images and videos, but with a bunch of 'Undefined Index' and 'trying to get property of non-object' warnings. Maybe I'll delete all my media and see if things come back into order?

Yup, wiping out the file system and clearing the 'file_managed' table got everything running again, but with all new errors which I'll talk about elsewhere I suppose...

Do I get this right? The problem is, that there are entries in the file_managed-table that have NULL as a value for type? Or is this bug more complicated? Since none of the patches worked for me I'm curious. It's not really an option to setup a clean install and port all the content that's already available... so I kind of hope that operating on the DB could solve this. :)

After a self-test, this seemed to be the case. As a really dirty workaround I connected to the database and opened the files_managed-table. The right-most column is 'type'. If you have an installation that had previously uploaded files, the value for any of those is NULL. Query all entries where type is NULL and take a look at the value for filemime. Then update the database so that every row with a mime-type of image/* has 'image' inserted as value for type. If you find other media than images (like application/octet-stream) you need to google the type-values those should have.

This fix is really dirty. If you should decide to try that route, backup your database. I'm on day 2 after this hack and everything seems to work fine, but with insane solutions like this you could never be sure... :)

any updates?