Recoverable fatal error: Object of class Drupal\Core\Field\FieldItemList

Can't seem to reproduce, is this still an issue ?

I'm guessing this was a passing issue. Feel free to re-open if it is still happening.

I just encountered this in rc1, clean install with Standard profile. Steps to reproduce;

• created a user, no special role, just Authenticated
• uploaded a picture to this user's Picture field. Notice the thumbnail preview was broken due to 404. Checked file ownership/permission but this all seemed fine, even though the styles subdir existed but somehow the thumbnail subdir didn't get created. That may be a separate issue though.
• At this point I still had the account Picture storage set to Public (as is the default). Then I went to admin/config/people/accounts/fields/user.user.user_picture/storage and changed it to Private. It let me change this even though it warned that this could no longer be changed since the field contained data. However, when I click "Save Settings" I do get that fatal error. When I go back to /admin/config/people/accounts/fields/user.user.user_picture/storage it does seem to have saved my changes though.
• I then edited the user and removed the image anyway, to be on the safe side.
• I re-edited the user, added a new picture, and now the thumbnail's showing fine. Still, any time I hit Save Settings on /admin/config/people/accounts/fields/user.user.user_picture/storage, I get that fatal error.

I am going to be dealing with this fatal error some more in coming days and hope to report back with some more details then. I hope others can reproduce this though.

I'm still unable to reproduce this, even following the steps in #4. That first issue:

uploaded a picture to this user's Picture field. Notice the thumbnail preview was broken due to 404. Checked file ownership/permission but this all seemed fine, even though the styles subdir existed but somehow the thumbnail subdir didn't get created. That may be a separate issue though.

Seems like it is probably at the root of this. I do not get broken thumbnails on user images with a clean install.

Do you see anything out of the ordinary on the status report page?

"Seems like it is probably at the root of this. I do not get broken thumbnails on user images with a clean install."
I have been playing around with it, just saving and re-saving some field / storage settings, and no longer get the fatal error. It did happen though, and shouldn't have - I just can't say for sure at this point what triggered it.

The situation now is that the default image I have set will not display - it gives a 403 Forbidden error. In fact, what seems to be happening is the default_images folder is not being created.

Example:
The thumbnail URL is:
/system/files/styles/thumbnail/private/default_images/default%20picture_2.png?itok=DP8YwAK1

But /system/files/styles/thumbnail/private/default_images does not exist although /system/files/styles/thumbnail/private does exist, while /system/files/default_images does exist and does contain the uploaded files, with correct permissions/ownership (even tried chmod 777 and ownership www-data:www-data, as a sanity check!!!).

I think perhaps I should have set the private file path and ensured correct ownership/permissions before messing at all with the User Picture settings, but permission issues still should not cause fatal errors; worst case it should result in a warning that the file can't be written. I'm unsure what exactly triggered it, at this point. I would need to run through it again from a fresh install, and properly document it.

I think, I found where is the error.
It happens because in the image_field_storage_config_update function, property $file_new->filename is used as string, however entity property returns an instance of the Drupal\Core\Field\FieldItemList class.
Please, check the attached patch.

Thanks @alex.ksis
I applied your patch and it worked.

+++ b/core/modules/image/image.module
@@ -404,7 +404,7 @@ function image_field_storage_config_update(FieldStorageConfigInterface $field_st
+    file_move($file_new, $directory . $file_new->get('filename')->value);

@@ -442,7 +442,7 @@ function image_field_config_update(FieldConfigInterface $field) {
+    file_move($file_new, $directory . $file_new->get('filename')->value);

You can simply use the getFilename() method of the File entity :)

@amateescu you're right, here is the new patch

@alex.ksis, looks much better now :)

Turns out that this issue is quite easy to reproduce, I'll update the issue summary. Also wrote some tests for this.

Yay, tests. Looks good :)

Needs a re-roll.

Rerolled after #2903332: Regression: lost test coverage for handling default images in the Image field.

Committed/pushed to 8.5.x and cherry-picked to 8.4.x. Thanks!