Notice : Undefined index: default_image in image_field_update_instance() - during reconfigure

I believe that's the same bug. Either try the patch in #4 or update to 7.x-dev and report back!

The patch of #4 didn't solve the issue for me. The error message still shows up if I modify an existing image-field. I've set the status back to active.

Regards
Werner

I had a similar error, but for line 505, as reported in #22 of #1558548: Notice: Undefined index: default_image in image_field_prepare_view() and it was fixed by patch #4 when modifying an existing image field.

Scratch that - still getting the same error when updating an existing image field that already has a valid default image assigned to the field, but the instance itself does not have a custom default image.

Notice: Undefined index: default_image in image_field_update_instance() (line 505 of /home/yosemite/public_html/modules/image/image.module).

I think the reason it appeared to be solved by the other patch might be that this only occurs on the first edit after upgrading? Not sure about that.

The version I'm working on is not managed by git, but I tried changing image.module line 505 to

$fid_old = (empty($prior_instance['settings']['default_image'])) ? NULL : $prior_instance['settings']['default_image'];

But I seem to be getting errors because of that

• Warning: array_flip() [function.array-flip]: Can only flip STRING and INTEGER values! in DrupalDefaultEntityController->load() (line 178 of /home/yosemite/public_html/includes/entity.inc).
• Notice: Trying to get property of non-object in file_field_presave() (line 220 of /home/yosemite/public_html/modules/file/file.field.inc).
• Notice: Undefined property: stdClass::$uri in file_save() (line 570 of /home/yosemite/public_html/includes/file.inc).
• PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '' for key 2: INSERT INTO {file_managed} (filesize, status, timestamp) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2); Array ( [:db_insert_placeholder_0] => 0 [:db_insert_placeholder_1] => 1 [:db_insert_placeholder_2] => 1336417230 ) in drupal_write_record() (line 7013 of /home/yosemite/public_html/includes/common.inc).

#4 works for me.

Subscribing

Subscribing - thought #4 was working, but there are still some places/situations where the error appears the patch I found was not #4, and only covered the first 'empty' default (instance) not the second (field). Seems ok now.

This bug is related to #1558548: Notice: Undefined index: default_image in image_field_prepare_view(), but not the exact same bug.

Previously (prior to commit d0b5d31c for #751168: Regression: Missing "Default image" per field instance), if you created an image field with no default image, an array would get saved to the data column of {field_config_instance}, but there wouldn't be any 'default_image' key in the settings array.

So, if you created your array with a version of image.module prior to that, then updated to a version subsequent to that, you get the following snipped of code in hook_field_update_instance():

  // The value of a managed_file element can be an array if the #extended
  // property is set to TRUE.
  $fid_new = $instance['settings']['default_image'];
  if (is_array($fid_new)) {
    $fid_new = $fid_new['fid'];
  }
  $fid_old = $prior_instance['settings']['default_image'];
  if (is_array($fid_old)) {
    $fid_old = $fid_old['fid'];
  }

The line causing the notice is the one that reads: $fid_old = $prior_instance['settings']['default_image'];

Because 'default_image' was not set in the previous revision of the image.module code, we get the undefined index. Re-saving the settings once causes it to be set explicitly to 0 now, so the PHP notice shows only once on a re-save of an instance of an image field with no default image. It's harmless, but if it must be avoided, the attached patch may help.

The other option would be to add a database update that walks through the {field_config_instance} table and adds the explicit 'default' => 0 to the field settings array, since adding the isset() check might be cluttering the code for a bug that will only happen once per field instance.

Sub. I also get this error.

The patch from comment #4 in #1558548: Notice: Undefined index: default_image in image_field_prepare_view() fixed this issue for me.

The patch provided in comment #8 in this issue was not needed.

To clarify to the previous commenter and others:

This bug is for a PHP notice that occurs on a different line in image.module than the lines that trigger a PHP notice in #1558548: Notice: Undefined index: default_image in image_field_prepare_view().

#1558548: Notice: Undefined index: default_image in image_field_prepare_view() is a related bug that triggers a PHP notice when you are viewing and image field.

The PHP notice reported here is triggered for image field instances when reconfiguring an image field with the most recent version of image module for field instances where the image field configuration instance was last modified/created with an older revision of the image module. The error occurs only once, when saving your changes to the an instance of an image field in this situation.

[Solved for me] - via update.php

I typed "update.php" without the double-quotes,
following my site's home name,
(Eg. www.my-site-example.com/update.php)
and pressed thee "Enter" key.

This runs the database updates that ought to be run
after any update to a Drupal site.

I had forgotten.

: o )

Still Exists for Me, and I DID run update.php

@MGParisi:
Does your error message have the same line number and function name as the one in the original post?

Or is it this one: #1558548: Notice: Undefined index: default_image in image_field_prepare_view()

I went to check but could not find the error message again:( A few weeks have passed Ive done nothing different, but its cleared up on its own?

The error will only ever happen once per image field anyway.

Once you get the error the value is saved correctly and no error the next time.

The patch in #8 solves the error. Can we set this issue to RTBC?

#8 didn't fix for me...sub...

i am getting notice error

Notice: Undefined index: default_image in image_field_update_instance() (line 501 of /home/content/42/8672442/html/modules/image/image.module).
Notice: Undefined index: default_image in image_field_update_instance() (line 505 of /home/content/42/8672442/html/modules/image/image.module).
Notice: Undefined index: default_image in image_field_update_instance() (line 501 of /home/content/42/8672442/html/modules/image/image.module).
Notice: Undefined index: default_image in image_field_update_instance() (line 505 of /home/content/42/8672442/html/modules/image/image.module)

please help

Running update.php worked for my D7 site. Pretty disturbing that this showed up on my homepage after an automatic update, though.

There are problems in comments above not related to this one, so a proper issue summary may help to clarify.

Note: This patch (rerolled from #8 above) only solves the issue caused by #751168: Regression: Missing "Default image" per field instance where an image field is stored without a default image set and so after the update to 7.13+ the default_image is missing from the saved field. This will only show up once and is resolved manually by resaving the image field. This patch just avoids needing to do that.

As ankur mentioned, we *could* add an empty default_image to all of the fields with an update, but it seems appropriate to me to fail gracefully either way.

with modifications (i.e. remove "core" from patch") seems to work in D7.15

Drupal 7.15. I had the error in lines 501 and 505. I edited and saved every image field. That removed the line 505 error but not the line 501 error so I changed 501 the same way the #8 patch changes 505. Both errors are gone.

7.17 is still broken.

Just upgraded to 7.18 - error Notice: Undefined index: default_image in image_field_update_instance()

This error can happen a few lines above as well as I discovered while adding a field to a content type. This patch fixes that.

Okay, #27 is for D7 which isn't going to pass. The only difference I can see in the patch is that /core/ is added into the path to the file so even though I don't have D8 I'm going to make this change manually and we'll see if it passes.

#29 patch doesn't change anything for me, issue not resolved, same error message still.

Unfortunately, #1558548-37: Notice: Undefined index: default_image in image_field_prepare_view() doesnt help. I tried it with no luck. Sorry

The patch in #29 worked for me on 7.22 version. Thanks.

After D8 conversion all field and instance settings are initialized before they are used. This error has gone.

I'm switching back to D7. Feel free to switch back if you get the error again in 8.

I just got this error on a new site installation.

Notice: Undefined index: default_image in image_field_update_instance() (line 510 of /srv/bindings/e11e0d9772374f15a4b04af83367c8d5/code/modules/image/image.module).

Setting this back to 7.x-dev - until this is fixed in the dev-branch, it follows that it will still be a live issue on any tagged releases (like 7.30), so leaving it on 7.x-dev is correct.

@kopeboy
Can you tell us what the steps are to reproduce the error you're seeing? There's a lot of conflicting information in this issue, so that would help us solve the problem. Plus, most of these reports seem to be the result of upgrades with pre-7.14 configuration. Your issue may be completely different.

Confirmed, got this error too.

Re-roll of last patch with a correct path.

#42 has fixed my issue.

Works like a charm.

That's weird. I looked at the patch in #27 and the paths are the same as #42. The starting line number is a little different but we can chalk that up the module changing a little over time and other than that the patches are identical.

The only thing I can think of as to why one worked and the other didn't is that the tester got a little smarter in the 2 years between tests.

@Reg, #27 failed when the testbot tried to apply it against Drupal 8. It applies fine to Drupal 7.

I'm not really sure what's going on with this issue :) #8 and #22 have pretty good explanations for why we might want to do this in the $prior_instance case (although there's a limit to how much we should care about leftover stuff from a years-old bug causing a one-time harmless notice, I guess it's reasonable to do a quick fix here!). It would be great to have a code comment explaining that though.

However, I'm not sure I understand the second fix (the one for the $instance) - why do we need that too, and what are the exact steps to reproduce a bug with that? It seems like that one might be hiding an existing bug that should be fixed somewhere else instead...

@David_Rothstein: Honestly, that was so long ago I no longer remember doing it yet along why and how to comment, sorry.

I am curious though, how to do you tell the test bot to apply against D7 instead of D8?

I am curious though, how to do you tell the test bot to apply against D7 instead of D8?

I believe it runs based on whatever the "Version" field of the issue points to.