Problem/Motivation
The standard profile ships with some image styles (thumbnail
, medium
and large
) that are used in other config entities shipped by the profile.
However, it is possible to edit the image style and modify its machine name. When this happens, the form displays that use that image style are not updated correctly, which leads to a WSOD when the widget tries to use the non-existent value.
Steps to reproduce
1) Install the standard profile
2) Create a node of the "Article" content type, uploading an image to the image field.
3) Go to /admin/config/media/image-styles
4) Edit the "Thumbnail" image style, changing its machine name to something else
5) Edit the node you created in step 2, and experience the WSOD
Proposed resolution
1) Fix the bug by updating the form displays when an image display has its machine name modified.
Remaining tasks
User interface changes
API changes
Data model changes
========== Original issue report by @desierto ==============
(Debian 8, Apache 2.4, Maria DB 5.5.60, PHP 5.6.33)
To reproduce the issue:
- Install default Drupal 8 with composer
- Enable media module
- Create/upload a media image
- Edit the name and Machine name of the default Thumbnail image style and save
- Go the the /admin/content/media page or try to edit the created media image and you will get a 500 error or white screen
Also it throws an error if you try to add a new media image... it will let you pick an image, but will not finish the attachment of the image and you will be unable to save a new image media.
Another note is that the media image type is not even configured to use the thumbnail image style.
To fix I have tried to flush the thumbnail image style, run cron, clear all caches, and run update.php. So far nothing has helped, including trying to create a new image style and delete all the others, choosing the new style as the replacement style. On another website I even tried delete the media image type altogether and recreating (w/o changing styles again) a new media image type. The errors persist.
There are no errors in Drupal error logs. Apache's error logs show these errors:
PHP Fatal error: Call to a member function getCacheTags() on null in /www/test2/web/core/modules/image/src/Plugin/Field/FieldFormatter/ImageFormatter.php on line 199
PHP Fatal error: Call to a member function transformDimensions() on null in /www/test2/web/core/modules/image/image.module on line 298
Should one not be allowed to change the image style machine name (I'm assuming that's where the problem lies) once media is created? Thanks for any ideas or fixes.
Comment | File | Size | Author |
---|---|---|---|
#13 | 2975539-13-test-only.patch | 3.25 KB | mondrake |
#13 | 2975539-13.patch | 4.31 KB | mondrake |
#10 | 2975539-10.patch | 1.06 KB | alexpott |
Comments
Comment #2
marcoscanoThe same error happens if you do the same (modifying/deleting the image style) and then trying to edit an "Article" node in the standard installation. It will WSOD once the image widget hardcodes the
thumbnail
image style as well.I would not be surprised if this issue already exists in core to improve validation of image styles edit form more generically (I failed to find one in a quick search though). If so, this should be marked as duplicate of that. Otherwise, this should be made a generic core issue, not restricted to Media entities.
Media-related, however, is #2923664: Missing image styles during "Media" install causes issues in media form and view display., once the module can be enabled after the image styles are modified, so the improved validation of the image styles form won't help with anything there.
Comment #3
mondrakeDoesn't this sound as a Critical issue?
Comment #4
catchYes it does.
Comment #5
marcoscanoOK, re-worded the IS a bit, to make the problem more generic.
Comment #6
marcoscanoComment #7
mondrakeReading the updated IS, #2647576: onDependencyUpdating() - React on dependency updating seems to me related, now.
Comment #8
mondrakeThe issue here is that
template_preprocess_image_style
andImageFormatter::viewElements
do not handle gracefully the case when the image style of the given name is non-existing.In #2479487-4: ImageStyles can be deleted while having dependent configuration. there's a patch that should be close to be able to fix the problem here - that issue took a different direction in the sense of fixing config dependency management (the root cause) rather than the dealing with the missing image style (the effect). But that issue only addressed dependency removal, here we have dependency update (the renaming of the machine name of the image style).
Comment #9
mondrakeAdding related.
Comment #10
alexpottHere's a fix. We broke this in #2723567: Remove entity_load* usage for entity_view_display entity type
Comment #11
alexpottSo we're obviously missing test coverage :(
Comment #12
mondrakeWorking on a test.
Comment #13
mondrakeAdded a test, taking cues from
ImageStyleIntegrationTest::testEntityDisplayDependency
.Interdiff equals test-only patch.
Comment #14
mondrakeWe probably need to update the IS - the problem we are solving here is that upon renaming the ImageStyle, the new machine name is not updated into the form display of the related image fields.
Comment #16
mondrakeComment #18
mondrakeWhat needs to be done here? We have a fix and a test.
Comment #19
marcoscanoI have reviewed the patch and it's a +1 from me.
Also updated the IS to be more accurate to the problem we are solving here.
Thanks!
Comment #20
marcoscanoNow also with a better title.
Comment #23
catchCommitted/pushed to 8.7.x and cherry-picked to 8.6.x, thanks!
Comment #25
VVS CreditAttribution: VVS commentedIt's repeated on 8.9.13...
Comment #26
mlncn CreditAttribution: mlncn at Agaric for Drutopia, Portside, Teachers with GUTS commentedGetting this same error in Drupal 9.2