Problem/Motivation
The image module does not test the PHP platform for library support of image types the module supports. This has affected a few site owners after upgrading to PHP builds that were not compiled with support for some image types.
Proposed resolution
Change the toolkit's getRequirements() method to detect the actually available image formats as reported by gd_info(); add a string to the UI of the status report under 'GD Library' to report the actually supported image formats; add testing.
Remaining tasks
User interface changes
Screenshots taken from the status report page
Current UI (no color module installed)

New UI
ALL GOOD

One format missing

Two formats missing

API changes
Data model changes
Release notes snippet
Original report
Hi,
I installed media and media library.
I am on an Ubuntu PC with docker environement for my Drupla 8.8.2 install.
(PHP 7.3.14, Apache 2.4.38, MySql 5.7.29)
When I try to upload an image I get this error:
Warning: imagesx() expects parameter 1 to be resource, null given in Drupal\system\Plugin\ImageToolkit\Operation\gd\Resize->execute() (line 67 of core/modules/system/src/Plugin/ImageToolkit/Operation/gd/Resize.php).
Warning: imagesy() expects parameter 1 to be resource, null given in Drupal\system\Plugin\ImageToolkit\Operation\gd\Resize->execute() (line 67 of core/modules/system/src/Plugin/ImageToolkit/Operation/gd/Resize.php).
Warning: imagecopyresampled() expects parameter 2 to be resource, null given in Drupal\system\Plugin\ImageToolkit\Operation\gd\Resize->execute() (line 67 of core/modules/system/src/Plugin/ImageToolkit/Operation/gd/Resize.php).
Warning: imagesx(): supplied resource is not a valid Image resource in Drupal\system\Plugin\ImageToolkit\GDToolkit->getWidth() (line 328 of core/modules/system/src/Plugin/ImageToolkit/GDToolkit.php).
Warning: imagesy(): supplied resource is not a valid Image resource in Drupal\system\Plugin\ImageToolkit\GDToolkit->getHeight() (line 343 of core/modules/system/src/Plugin/ImageToolkit/GDToolkit.php).
All other functions of the site are OK.
I can also uplad PDFs with media manager but not images.
thx.
| Comment | File | Size | Author |
|---|
Issue fork drupal-3116611
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
- 3116611-add-a-requirements
changes, plain diff MR !302
Comments
Comment #3
xem8vfdh commentedI am seeing the same issue, which is preventing my system from generating Image Style instances.
Comment #4
gurunathan commentedI face the issue with Drupal 9.0.1 and PHP 7.4.
Any solution?
Comment #5
xem8vfdh commentedMy issue seems to be specifically tied to php 7.4. I opened this other issue about it, and the errors went away after I downgraded to php 7.3.
Comment #6
gurunathan commented@xeM8VfDh
Strange, it's said that Drupal9 will be supported by PHP 7.4.
Comment #7
xem8vfdh commentedyeah, I know, I'm very confused by it as well. I;m on Drupal 8.9.1 by the way.
Comment #8
gurunathan commentedTried to downgrade into 7.3.
It caused the error.
TypeError: Argument 2 passed to Symfony\Component\Routing\RouteCollection::add() must be an instance of Symfony\Component\Routing\Route, bool given, called in /mnt/www/html/midlandsbdev/docroot/core/lib/Drupal/Core/Routing/RouteProvider.php on line 382 in Symfony\Component\Routing\RouteCollection->add() (line 74 of vendor/symfony/routing/RouteCollection.php).This one fixed that issue.
https://www.drupal.org/project/drupal/issues/3145563#comment-13664364
But the original issue with PHP 7.4 still remains.
Comment #9
xem8vfdh commentedThat's weird... I had the issue on 7.4 and resolved it by downgrading to 7.3...
Comment #10
cilefen commentedPossibly? https://stackoverflow.com/questions/49891991/warning-imagesx-expects-par...
Is GD support for JPEG there on this PHP build?
Comment #11
mondrake#10 actually in the requirements we are testing if the gd extension is enabled, but not if specific image formats are supported, and that is a gap IMHO because some PHP builds may miss linking the relevant libs. The only format explicitly checked for is PNG, but the check is in the color (!) module requirements. See also #2340699-111: Let GDToolkit support WEBP image format for similar discussion on supporting WebP image format.
Comment #12
cilefen commentedRe #11. I was wondering about that. After the OPs check in, let's consider re-framing this issue as a requirements logic improvement if no issue exists.
Comment #13
cilefen commentedAlso GDToolkit::load doesn't seem to have a good way to signal failure.
Comment #14
xem8vfdh commentedSo, #10 may actually be my issue as well. I am using pantheon, and their 7.4 does not have JPEG support, but their 7.3 does. Thanks for the suggestion @cilefen!
For those on Pantheon as well, their engineering team is working on resolving this. I'll post back when its done.
I think #11 is a great suggestion.
Comment #15
cilefen commentedComment #16
cilefen commentedComment #17
cilefen commentedAs a task this may be a duplicate.
Comment #18
xem8vfdh commentedfor what it is worth, Panthon updated their 7.4 environment to include JPEG support for GD. Unfortunately, running this updated environment that used 7.4.3, the issue persists. I can upload and render (create Image Styles) for PNG files no problem, but the JPEG files still present issues:
Comment #19
xem8vfdh commentedthis is a critical issue that prevents using Drupal on 7.4. As 7.3 will hit its end of life relatively soon, I'm wondering if this issue merits having it's priority increased.
Comment #20
cilefen commentedDid Pantheon in the end add support for JPEG in GD? Drupal could test for library support in the related issues (as I've titled this one, it is probably a duplicate—so I retitled it to be more like a bug). But I don't know how Drupal could work around a missing GD library. Any ideas?
Comment #21
xem8vfdh commentedSorry @cilefen, I typed a reply to you days ago and must have never submitted it.
yes you can review the Pantheon 7.4 env here, and it does now support JPEG with GD. However, despite upgrading my Pantheon 8.9.2 site from 7.3 to 7.4, I am still seeing the errors in #18.
I had to downgrade back to 7.3 to prevent error.
Comment #22
cilefen commentedI think GDToolkit::load returns false and never sets the resource property. Is imagecreatefromjpeg, from GD, a global function on that new PHP build?
Could you use ImageMagick temporarily?
Comment #23
xem8vfdh commentedHey @clefen, unfortunately I have no control over Pantheon, so I can't easily test those packages. But, since 7.3 works and 7.4 doesn't, can you spot any difference in those separate phpinfo outputs that might indicate the issue here?
Comment #24
cilefen commentedThey were configured for compilation differently. In 7.3 the flag is --with-jpeg-dir=/usr but in 7.4 it is --with-jpeg. But I assume that is for a reason. Ask support if function imagecreatefromjpeg exists in their PHP 7.4 container.
Comment #25
xem8vfdh commentedAwesome, I will look into it @cilefen and get back to you, I really appreciate it!
Comment #26
xem8vfdh commented@cilefen, I just received this from Pantheon:
Comment #27
cilefen commented🤷♀️
The stack trace you posted in the issue summary indicates two things. First, that imagesy was passed a resource but it "is not a valid Image resource":
But then, this runtime warning suggests that ::load did not return anything:
Ostensibly someone could build a minimal reproduction on a clean Drupal install on Pantheon and hand that off to support.
Comment #28
xem8vfdh commented@cilefen, so are you confident that this issue is likely the result of the Pantheon environment, as opposed to drupal/GD/7.4/etc? if so I will reproduce there and ask them to investigate. Thanks again for the helpful insight.
Comment #29
cilefen commentedIt is not reproducible with Homebrew PHP 7.4 by uploading a jpg and creating jpg variants. Incidentally, Homebrew's compiled-in GD jpeg support is:
JPEG Support enabled
libJPEG Version 9 compatible
Comment #30
xem8vfdh commentedhey @cilefen, I worked with Pantheon to try to reproduce in their 7,4 environment. I wasn't able to, so maybe I just didn't test properly after they fixed their 7.4 environment. I can't say, but hopefully I just screwed something up and this is no longer an issue with pantheon 7.4 or my system. If the issue resurfaces, I will post here. Thanks very much for the help, I really appreciate it.
Comment #31
cilefen commentedThanks for the follow-up. I am moving this back to a support request because the title now sounds like a statement of fact ;-).
Comment #32
jedgar1mx commentedThis is not a Pantheon only issue, Acquia also has issues with
PHP 7.4. I had to downgrade toPHP 7.3to temporarily fix the issue. Seems to be an environment issue.Comment #33
cilefen commented@jedgar1mx Did you report it to them, and reference this issue?
Comment #34
jedgar1mx commentedI reported it to acquia awhile back and it seems they will be doing some updates to their platform. I just found this issue while looking for some other stuff. Figured I should let acquia users know 🙂.
Comment #35
mforbes commentedAcquia lists it as a known issue at https://docs.acquia.com/cloud-platform/known-issues/#some-image-formats-... and support clarified the cause to be PHP 7.4 doesn't have jpg and png support compiled into the GD library. We are on D7 and experienced it.
Comment #37
mrjey commentedIf you are using docker, you can build your GD library with JPEG using the following lines:
This way GD is compiled and enabled with libjpeg and the problem is solved.
Comment #38
mforbes commentedThe fix has been deployed on Acquia.
Comment #39
mondrakeThis patch add requirements check for the existence of the image functions for the format supported by the GD toolkit.
Comment #40
mondrakeComment #41
anil.gangwal commentedI am able to solve this issue by adding below configuration to docker file.
This works with PHP 7.4 and Drupal 9 for GD issue
apt-get update; \
apt-get install -y --no-install-recommends \
build-essential \
libfreetype6-dev \
libjpeg-dev \
libpng-dev \
libpq-dev \
libzip-dev \
libjpeg62-turbo-dev \
# GD
docker-php-ext-configure gd --enable-gd --with-freetype --with-jpeg --with-webp; \
docker-php-ext-install -j "$(nproc)" \
gd \
; \
Comment #42
cilefen commentedComment #43
mondrakeGetting this in the db log:
Comment #44
mondrakeNever mind #43... I was running an old patch. Sorry for the noise.
Comment #46
mondrakeRerolled and cleaned up after commit of #2340699: Let GDToolkit support WEBP image format. Changed to MR workflow.
Comment #47
andypostAdded 2 comments and it looks mostly great!
Comment #48
mondrakeThanks for review @andypost, fixed your points.
Comment #51
nikral commentedI have the same issue on PHP 8.0 and Drupal 9.3.12
Fixed by
Comment #52
avpadernoComment #53
mondrakeBumped the MR target branch and rebased.
Comment #55
mondrakeThanks @heddn, merged your suggestions
Comment #56
mondrakeComment #57
mondrakeRebased for 10.1.x, and at this stage dropped the changes to the color module that it's better be left alone since it is up for removal in D10.
Comment #58
mondrakeWorking on adding a kernel test.
Comment #59
mondrakeComment #60
andypostNeeds CS fix but overall looks great!
Tagging for usability review as if GD library missing more then one format it could look weird
Would be great to add screenshots about how it may look
PS: thinking about contrib module /project/imagemagick which using
convertCLI command - how it may change the message for supported formatsComment #61
mondrakeScreenshots taken from the status report page:
ALL GOOD
One format missing
Two formats missing
Comment #62
mondrakeComment #63
andypostThank you! That's what I mean when more then one format is missing
I find it more readable if it will be one-liner - The GD library was compiled without following formats: JPEG, WEBP. Check the...
Comment #64
andypostAdded commit to fix #63
Comment #65
mondrakeThanks, did some more cleanup, we would need new screenshots now.
Comment #66
mondrakeComment #67
mondrakeNew screeshots:
One format missing
Two formats missing
Comment #68
mondrakeComment #69
andypostIMO it's ready to go but still needs UX POV on it and wording
Comment #70
andypostComment #71
benjifisherWhen you tag an issue for usability review, please make it easy for the usability team to review the issue. Update the issue summary:
Most of the time, I prefer to have plain text in the "Proposed resolution" section and screenshots in the "User interface changes" section.
You can also attend the weekly usability meeting to present an issue.
I am adding the tag for an issue summary update and setting the status to NW.
Comment #72
mondrakeHonestly I think usability review here is a bit of an overkill, but updated IS according to #71 anyway.
Thanks.
Comment #73
mondrakeComment #74
mondrakeComment #75
rkollerWe've discussed the issue at #3296084: Drupal Usability Meeting 2022-07-15. That issue will have a link to a recording of the meeting. For the record the attendees at todays (07-15-2022) usability meeting were @benjifisher, @shaal, @simohell, @worldlinemine, and me.
There was a consensus that it is useful feature. We would have two suggestions in regards of the scan-ability of the micro copy. Currently it reads for one file format missing:
for two image formats missing:
The information of interest are the supported image file formats. That is easily scan-able. You have the keyword
Supportedand then there is the visual queue of the italic file format list. That's good.If the user wants to know the unsupported file formats he or she first has to scan the bits about GD library, compilation and so forth until the points of interest, the unsupported file format(s) could finally be found.
The other detail is the end of the second sentence about
how to correctwhich implies that something is wrong. But perhaps the selection of file formats was a conscious decision. We would suggest the following pattern:one file format missing
two image formats missing:
That way you have the identical easy to scan pattern for the supported as well as unsupported image file formats. The description about the unsupported file formats gets shorter and more concise - you provide the link to the documentation for those interested and or necessity how to add support.
I'll set the issue to
needs workand remove theneeds usability reviewtag.Comment #76
mondrakeThanks a lot team for the review.
I made changes to the MR according to the feedback.
Comment #77
mondrakeUpdated IS with latest screenshots.
Comment #78
andypostI find it ready to go
Comment #79
mondrakeRebased
Comment #80
mondrakerebased
Comment #81
mondrakerebased
Comment #82
alexpottAdded a review to gitlab
Comment #83
mondrakeMade the suggested fixes.
Comment #84
andypostSuggestions addressed, let's get it in
Comment #85
alexpottI think we can have less reliance on array keys and more rely on PHP constants. See code review above & in gitlab
Comment #86
mondrakeMade fixes according to @alexpott's input. Thanks!
Comment #87
andypostIt looks rtbc but I'm curious about to define array of formats as enum, so when we'll add avif format it will need to change less places
Comment #88
mondrakeOK, but I wouldn't hold on that... otherwise this becomes a never ending issue...
Comment #89
daffie commentedAll the code changes look good to me.
All the points of @alexpott have been adressed.
The IS is in order.
For me it is RTBC.
Comment #90
alexpottBackported this to 10.0.x because it is a task that is a pure addition and useful. Didn't backport to 9.5.x because it has a PHP 7.4 feature...
Committed and pushed 00d6bd97a7 to 10.1.x and ee88d7a711 to 10.0.x. Thanks!
Comment #95
liam morlandThere is a proposal to change this check in #3570466: Reduce severity of GD library supported image file formats warning. Please review and comment.