Call to a member function transformDimensions() on null in template_preprocess

This is an entity_embed content filter. I'm not convinced that it should be handled like that there, preventing a fatal is indeed a good thing, but I think we'd more likely just throw a clear exception.

You could suggest instead to check the image style in entity_embed, having old references in content is a valid use case, but code calling/using a non-existing image style is not something we do not want to fail on (fail nicer yes, fail not at all, not sure..)

+++ w/core/modules/image/image.module
@@ -289,48 +289,55 @@ function image_style_options($include_empty = TRUE) {
+      '@style' => $variables["style_name"],      ¶

Also space needs to be removed.
Thanks

I stumbled upon this not having the `media_library` image style which is, however, in the `config/install` of the `media_library` module. Don't know how this happened, but it is.

+1 for my installation with respect to #5. Once I created `media_library` style it worked as expected and I no longer was receiving that error.

+1 for the reason and solution in #5.

It DEFINITELY makes sense to log an error instead if an image style doesn't exist (anymore) instead of a hard error!

+1 for a patch like #2 concerning #3.

+1

+1

Still open, I'm switching to the current Drupal version.

This error may also occur if the default image preview imagecache style has been deleted. Even if the form display settings show "No preview", the default image formatter seems to be set in the database by default and leads to this error as JS error on file upload / selection!

Received this error when creating new custom content with an image field.
At the "Manage form display" of the content entity, in the Image field settings, the "Preview image style" was set to "no preview".
Selecting there a predefined image style, e.g. "Thumbnail 100x100" solved the issue for me.
The error disappeared and the edit form of the content type was properly shown.

Fixed some CS issue and comment #4.

I think it's ready for review.

Tested #14, space related issues are resolved mentioned in #4

This occurred to me when using the Image Widget Crop module. I deleted the only required crop type and had to select another crop type in the "form display" settings. (Thanks JodiK!)

+1 for #12

14 works for me

Thanks, @JordiK #12 Works for me.

#14 works for me

I'm working on Simplytestme issue
Facing the same issue while trying to upload an image via a media entity. The Ajax throws the following error.

The patch #14 works for me.

I tested #23 issue on a vanilla drupal but wan't able to recreate it.

Indeed, patch #14 solved the exception on the /media/{MID}/edit page for me as well.

After patch the issue is fixed
for ref sharing screenshot

As manual testing for #14 seems successful, I think we need tests to ensure it won't break again?

Patch #14 was extremely helpful to me in figuring out exactly what was going wrong. Thanks!

#30 Thanks for the report and the initial work on the patch. But please do not close a core issue without agreement of core or sub system maintainers or a certain amount of users commenting here, especially not when there is nothing committed yet to core and last comments recommend further work on the issue like stated in #27.

Related but affecting another preprocess function: #3056841: null in template_preprocess_image_style()

After apply #14 I got error.

Update Patch #14.

Issues are Fixed.

Looks good to me on Drupal 9.3.8.

Thanks for moving this along!

This should be on 10.0.x now, changing version. This is tagged as needing tests and there are none in the patch, changing status. Adding tag for an issue summary update so that there is a 'proposed resolution' for future reviewers and committers.

A brief scan of the patch and I saw this

+++ b/core/modules/image/image.module
@@ -252,48 +252,56 @@ function image_style_options($include_empty = TRUE) {
+    \Drupal::logger('image')->warning('Image style (@style) missing for @image. Please add the missing style under /admin/config/media/image-styles.', [

The user interface standards states to not use 'Please' See, https://www.drupal.org/node/604342#interface-text-style. And I think a link to the image-styles configuration should be used instead of a path.

Ameymudras you are huge!

I have been facing this problem for days. It is resolved. Big thanks !!!!

#40 seems also working fine on 9.4.5 for what it's worth. thank you

Patch #40 works on drupal version 9.4, 9.5, and drupal 10 successfully. It is resolved the my issue.
Thank you

Moving back to NW for the tags

Was tagged for tests in #27
Tagged for IS update in #39

#40 does not apply to 10.1.0.
Here is a reroll.

#12 seems to be the trick for me.

Ongoing issues should be set to target 11.x

#45 is necessary for 10.1.x; #40 doesn't work with it.

Patch #45 worked on Drupal 10.1.6

Conflict with other issue:

After running patch #45, I got this error, ONLY after cache clear
Deprecated function: pathinfo(): Passing null to parameter #1 ($path) of type string is deprecated in Drupal\image\Entity\ImageStyle->supportsUri() (line 385 of core/modules/image/src/Entity/ImageStyle.php).

This error is addressed in this issue, and there is a patch
Deprecated function: pathinfo() on template_preprocess_image_style
https://www.drupal.org/project/drupal/issues/3306131
There is a patch:
https://git.drupalcode.org/project/drupal/-/merge_requests/2680.patch

It just changes one line of code, and adds a saftely check.
I added this into this patch here

- if ($style->supportsUri($variables['uri'])) {
+ if (isset($variables['uri']) && $style->supportsUri($variables['uri'])) {

#45 worked for me. I could not get #50 to apply (Drupal 10.1.6)

#45 applies on D10.2.4

Yes, I've been using #45 on 10.2 successfully.

#50 applies on D10.2.4 and created merge request for the Patch

Re-rolled patch for drupal 10.3.2

Merge requests need to target 11.x.

Please update the merge request instead of uploading new patches. That way the issue can advance.

#61 works perfectly on 10.3.2, thanks.

#62: Some points made before are still not addressed in the latest patches (like tests) so a re-roll only won't make it. To prevent wasted efforts and resources of contributors, we also maybe need some thoughts of project maintainers if this issue is outdated or still relevant, since it had its most momentum in the Drupal 8 migration live cycle.

Additionally: #57 and below are these tags added in cooperation with the project maintainers or in agreement with meetups on Drupal events? And are these still required? Since there was no comment added to the tags, they fade a little bit into curiosity.

I know a reroll isn't all that's needed, and that's why I left the status Needs Work.

Usually NR is rather used to review patches, but it also creates attention. The situation needs some more reviews and opinions like explained in #65. Repeating posted patches triggered by Needs Work just flood the issue but do not bring us closer to a final route to go. Usually this state would require Postponed (maintainer needs more info) ("PMNMI") but since I am not the maintainer of the image framework I would leave it up to the maintainers to choose this Status. There is sadly no Status in between these both.

Further Descriptions of the Priority and Status values can be found in the Drupal project issues documentation.

This crash caused me a major headache today when a new content type went live on our production system. Our editor tried to import pages from the stage system; they imported successfully but crashed when he tried to open them to edit.

Turned out that the image field in the content type had been configured without a preview image style selected, and was defaulting to "thumbnail", which doesn't exist, and was then causing this crash.

This raises two questions for me:

Firstly, why does the image style default to a style that doesn't exist? If the style doesn't exist, don't use it as a default.

And secondly, why is a crash like this allowed to persist in core? It's a relatively easy crash to make happen, and easy to fix (the patch is already done ages ago), and the crash message itself doesn't include the key detail of what image style is causing the problem, which makes it much harder to diagnose.

Please can this patch get reviewed and pushed into the next release. Thank you. :)

This worked for me!

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Please make any changes to the merge request rather than submitting new patches. Thanks.

I have been bumping into this issue from time to time, and then I come here to grab the latest patch for the current Drupal version.

I also think some simpler patches / fixes shouldn't need to take 8 years and 4 major Drupal versions to get applied, regardless if there are specific tests developed.

We will commit a validation to know if the URI is set.

Needs review (Pending to add tests)

Before we review can steps be added to reproduce this?

Based on the summary and the error this seems more like a bug then a feature request.

I agree with #77 that we need steps to reproduce so anybody who knows basic site building or greater can reproduce and test the issue.

#16 delivers a set of steps to reproduce:

Received this error when creating new custom content with an image field.
At the "Manage form display" of the content entity, in the Image field settings, the "Preview image style" was set to "no preview".
Selecting there a predefined image style, e.g. "Thumbnail 100x100" solved the issue for me.
The error disappeared and the edit form of the content type was properly shown.

How does this sound?:

1. Install Drupal 11 using the standard profile and the default theme.
2. Add an image field to the Basic page content type.
3. At the "Manage form display" of the content entity, in the Image field settings, set the "Preview image style" to "no preview".
4. The error message will prevent the edit page for the Basic content type from rendering. It will fill the page.

Is it as simple as that? Or are extra steps required?

#61 still applies to 10.3.10. Thanks!

#45 works for me

I can confirm that #45 still works on 11.2.4.

#45 Does not apply on 11.3.x anymore

For those who used #45, I re-rolled #45 for 11.3.x

I fixed conflicts with main (based on the patch from #83) and added a test.

I could not reproduce with steps from #78 but I added a PHP snippet that triggers the problem.

Appears to have two open threads, 1 is super minor but the 2nd one may be a bit more hence I didn't just apply suggestion to MR.