Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
Steps to reproduce:
- Install Drupal with the Standard profile
- Make sure you have the Private file system set up
- Go to the storage settings of the Image field on the Article content type (admin/structure/types/manage/article/fields/node.article.field_image/storage), change the Upload destination to 'Private files' and upload a default image at the same time
Proposed resolution
Fix image_field_storage_config_update()
and image_field_config_update()
.
Remaining tasks
Review.
User interface changes
Nope.
API changes
Nope.
Data model changes
Nope.
Original bug report:
When saving image for default image and in private destination it shows "Error The website has encountered an error. Please try again later." and when i check the error log it shows.
"Recoverable fatal error: Object of class Drupal\Core\Field\FieldItemList could not be converted to string in image_field_storage_config_update() (line 423 of /home/roald/sandox/drupal8-bug/core/modules/image/image.module)."
Comment | File | Size | Author |
---|---|---|---|
#24 | 2322421-24.patch | 3.95 KB | amateescu |
#24 | 2322421-24-test-only.patch | 2.81 KB | amateescu |
#20 | 2322421-20.patch | 3.91 KB | amateescu |
#20 | 2322421-20-test-only.patch | 2.78 KB | amateescu |
#19 | recoverable-fatal-error-when-saving-image-2322421-19.patch | 1.13 KB | alex.ksis |
Comments
Comment #1
slashrsm CreditAttribution: slashrsm commentedComment #2
swentel CreditAttribution: swentel commentedCan't seem to reproduce, is this still an issue ?
Comment #3
jhedstromI'm guessing this was a passing issue. Feel free to re-open if it is still happening.
Comment #4
caspervoogt CreditAttribution: caspervoogt at Plethora commentedI just encountered this in rc1, clean install with Standard profile. Steps to reproduce;
Comment #5
jhedstromComment #6
caspervoogt CreditAttribution: caspervoogt at Plethora commentedI 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.
Comment #7
jhedstromI'm still unable to reproduce this, even following the steps in #4. That first issue:
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?
Comment #8
Dave ReidComment #9
caspervoogt CreditAttribution: caspervoogt at Plethora commented"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.
Comment #10
caspervoogt CreditAttribution: caspervoogt at Plethora commentedComment #11
caspervoogt CreditAttribution: caspervoogt at Plethora commentedComment #15
alex.ksis CreditAttribution: alex.ksis as a volunteer and at Lemberg Solutions, Open Social for Open Social commentedI 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.
Comment #17
0Sarah0Al CreditAttribution: 0Sarah0Al commentedThanks @alex.ksis
I applied your patch and it worked.
Comment #18
amateescu CreditAttribution: amateescu for Pfizer, Inc. commentedYou can simply use the
getFilename()
method of the File entity :)Comment #19
alex.ksis CreditAttribution: alex.ksis as a volunteer and at Lemberg Solutions, Open Social for Open Social commented@amateescu you're right, here is the new patch
Comment #20
amateescu CreditAttribution: amateescu for Pfizer, Inc. commented@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.
Comment #22
BerdirYay, tests. Looks good :)
Comment #23
catchNeeds a re-roll.
Comment #24
amateescu CreditAttribution: amateescu for Pfizer, Inc. commentedRerolled after #2903332: Regression: lost test coverage for handling default images in the Image field.
Comment #26
catchCommitted/pushed to 8.5.x and cherry-picked to 8.4.x. Thanks!