Broken images displayed and PHP notices when file/image field values are missing

subscribe. i think you need to reroll the patch from the docroot.

This has been fixed in D8 conversion.

    $image_style_setting = $this->getSetting('image_style');
    foreach ($items as $delta => $item) {
      if ($item->entity) {
        if (isset($link_file)) {
          $image_uri = $item->entity->getFileUri();
          $uri = array(
            'path' => file_create_url($image_uri),
            'options' => array(),
          );
        }
    ...

This is still an issue in 7.x, looking to see if any other issues for it already open though.

unable to find an active other issue.

reroll with array_filter

this bug leads to: array_key_exists() expects parameter 2 to be array, null given in theme_image_formatter() (line 605 of .. modules/image/image.field.inc).

Not that part of the issue is that the deleted file IDs aren't deleted from the database also. References and taxonomy terms also has this issue to my knowledge and it's not an easy fix

Patch is being used on a project with multiple testers/developers and has not presented any problems yet and has fixed the issue.

I think we need the array_filter in file_field_load() instead. I think this is too high-up of a fix.

I actually think we need the same fix we did for file_field_presave() in #1443158: file_field_presave assumes that a file object has been loaded

#10 fixed the

array_key_exists() expects parameter 2 to be array, null given in theme_image_formatter() (line 605 of .. modules/image/image.field.inc).

warnings for me.

Thanks!

Let's do this instead.

#10 and #16 patches didn't work for me, user1 still can't upload/change his profile picture :(

Unassigning from @nagba as it's been a few years.

#5 saved my life. Thanks! I cannot figure out why the error produced though, because no images failed to load during the migration of a certain node type. But with this patch everything looks as it should again.

#10 made the error message go.

As I wanted a fix for this without patching core, I implemented the following in a custom module. This also logs an error if the referenced file is not accessible (deleted etc.)

function mymodule_theme_registry_alter(&$registry) {
  // Reference the image_formatter function element in the registry.
  $function =& $registry['image_formatter']['function'];
  // Save old function
  variable_set('mymodule_image_formatter', $function);
  // Set new function.
  $function = 'mymodule_image_formatter';
}

// Override function for 'theme_image_formatter'.
function mymodule_image_formatter($variables) {
  // If there is no file defined, just return.
  if (empty($variables['item'])) {
    return '';
  }

  // Check that file is readable.
  $uri  =& $variables['item']['uri'];
  if (is_readable($uri)) {
    // Call the original theme function.
    $function = variable_get('mymodule_image_formatter');
    return $function($variables);
  }
  else {
    // Log an error - file has been deleted or is inaccessible for some reason, e.g. permissions.
    watchdog('mymodule', 'File %file is not readable', array('%file' => $uri), WATCHDOG_ERROR);
    return '';
  }
}

#22 that is a very cool fix.
Funny, how such an old issue still relies on patch-work.

Just ran into this over in #2816413: Handle NULL images nicely.

I'm currently using #16 and it's working for my use case (i.e. with Diff).

However as #17 reports it's not working and there are several different methods suggested setting back to active to work out which approach to go with.

Patch from comment #16 worked for me (my website was having a warning when the images where removed from media interface) , thanks!

It seems the properly moment of the code to remove the item (when it checks file if empty in order to remove).

Can this be applied to core, or it needs some help? This solves the original problem from the issue (errors when file field values are missing ).

#16 works for me. An AJAX error while using VBO caused my site to time out and the operation to fail; this patch fixes that problem and makes my error message go away (Warning: array_key_exists() expects parameter 2 to be array, null given in theme_image_formatter()).

Patch in #16 works for me, as well.

In my case, I have a default image set on my field. Occasionally, if an image is added and then deleted, the default image will not load and the error above appears. After applying the patch in #16, the default image loaded and the error disappeared.

Just run into this again - Warning: array_key_exists() expects parameter 2 to be array, null given in theme_image_formatter().

Patch in 16 still applies and works well. Stops the error. Any particular reason this has made no progress in 5 years?

I'm happy to mark this RTBC - Seems 6 peolpe now have passes and are using this patch.

Has been in my makefile for more than half a decade. Good question.

Subscribing this issue

Just confirming that the patch in #16 still applies against 7.x-dev.

It'd be great to have a test for this.

Needs tests. I don't think this occurs when file_entity is enabled but I could be mistaken.

This patch worked for me, though it has moved down to line 187.

I have created a test which demonstrates the warning/error (in PHP 8 it throws a TypeError, so maybe it is also a PHP 8 compatibility issue). The problem can arise in two scenarios where the file/image is being displayed:

1. System is loading file/image which has empty FID in the field_data... table
2. System is loading file/image which has FID in the field_data... table which is not present in file_managed table

Keep in mind that to trigger the error the field cache needs to be cleared, because if the file/image is loaded for the first time, it is saved in field cache and deletion afterwards does not cause Drupal to load the file again, instead it is loading data from cache_field.

Adding test only patch and the original patch from #16 with the test, which should pass. I think the approach from #16 is the correct one, as it fixes two problems at once - if this problem happens on an image field and also if this happens on a file field. Also it is safe to do this unset, as we have done something similar in #1443158: file_field_presave assumes that a file object has been loaded.

According to this and also the fact that lot of people confirmed that #16 is working I think this can be set as RTBC and commited (if the testbot will be happy).

Testbot is happy and the test failures are present.

I have unintentionally switched the status to RTBC. Patch was slightly modified - new test was added, so reverting the status change.

Test looks great and confirms that #16 fixes the main issue as described. Thanks!

I wonder if some of the earlier comments describe slightly different but related problems? Either way this should be committed.

Thanks all!

@mcdruid some patches tried to fix this more "upper", so they are quite different. But there could be some related issues - few are mentioned also in the related issues linked here.