WSOD when the image.<toolkit>.inc file for the selected image toolkit is not found.

I have had the exact same experience, however when I visit the admin/settings/image-toolkit page it also brings up the same php error about line 70 in the includes files. In fact each page of the image module will bring this same error msg, as will visiting the top level admin page, however all other pages from within admin are still accessable like they are with yours.

I am running D 6.4 with image alpha 1 however.

Please advise if possible!

TIA, Renaee.

This seems to be caused by core's image handling, not by image.module. After taking a quick look at image_get_toolkit(), the logic that leads to invocation of image_gd_check_settings() is indeed a bit weak, in that a badly set 'image_toolkit' variable is all that's needed to execute that function, whether it available at all isn't checked (clearly a leftover from D5 when GD handling was part of the same file and therefore always available).

Indeed, we need to include image.gd.inc before calling image_gd_check_settings().

This is a 6.x only issue, as D7 now has, thanks to the registry, a dynamic file loading mechanism.

excellent, thank you! worked a treat, love an easy solution...

happy new year sam

After upgrade to Acquia Drupal 6.12, I get:

Fatal error: Call to undefined function image_gd_check_settings() in <snip>.../includes/image.inc on line 70

on the /admin page and all node/[nid]/edit pages.

I solved it by including an include statement for includes/image.gd.inc (this is where image_gd_check_settings() is defined) in includes/common.inc. Patch applied.

Hope somebody with better Drupal knowledge can verify whether this is the correct solution.

I am no coder, but I included the new line from the patch manually and voilá - it works! Good thinking and good catch.

Big help! Thanks.

Much appreciated- a big help!

Is there any word on when this will be fixed? I run a site with 141 separate 6.x installations. I can script this, but it's such an easy fix that I'd hate to spend the time if someone is already working on it.

Simple matter to fix - tagging for the novice queue

I had the same problem, but without doing much and without the patch the problem resolved after just a few minutes - on hosted server.

I opened all the options (tabs) under ....../admin/settings/image and saved them without any changes. I ran cron before and after plus flashing all caches a few times along the way.

So, just a little patience and a few standard buttons solved the problem here. Just to encourage you to take a break, have a tea and come back with some fresh ideas before spending too much time sorting problems that might just be hidden in slow cron runs or server refresh delays.

Good luck

Great Fix! Thanks. I found the same error in my php_error log. All I did was visit the page localhost/drupal/admin/settings/image-toolkit save the default settings and that fixed the problem.

I did that (visited http://localhost/drupal/admin/settings/image-toolkit), got an error, tried saving the settings but was not allowed to. STILL, magically it worked after that. Thanks!

This problem exists in the 6.13 upgrade as well as the upgrade to 6.12.

Correcting improper tag.

I've just upgraded to 6.13. I appreciate all the work and input. But I'm still a novice and still don't understand how the code is included in the code exactly. I've tried different variations and it doesn't seem to be working for me. How should the whole section look after the patch is included?

Brilliant! I followed the instruction to navigate to my image-toolkit module (per instructions on top post)

http://mysite.com/admin/settings/image-toolkit

And hit save when I got into and I'm back in business!

Thank you

This was not committed to the recent update btw, I received the error again.

bless you guys..... i thought this was way worse than it turns out.

I was trying to upgrade drupal 5 to 6 once again.

The update.php script runs, and all seems hunky dory, except that I get this message on the admin screen:

"The content access permissions need to be rebuilt. Please visit this page."

That's http://localhost/admin/content/node-settings/rebuild

Running "rebuild permissions" gives a 500 error ... apache's error log shows:

"PHP Fatal error: Call to undefined function image_gd_check_settings() in /srv/htdocs/includes/image.inc on line 70, referer: http://localhost/batch?op=start&id=4"

I copied image.imagemagick.inc to /includes/ and that fixed things, but shouldn't the function throw an error message instead of pushing apache to give out that rather unhelpful 500 error?

Same again upgrading from 6.15 to 6.16

And again upgrading from 6.16. to 6.17.

Also experiencing this, this hack fixes it:

    elseif (FALSE && !image_gd_check_settings()) {

Just upgraded from 6.17 to 6.19 and have the same problem.

UPDATE: Went back over the various fixes listed here in case I missed something - just saving my existing Image toolkit settings did the trick. http:/.../admin/settings/image-toolkit

I confirm that the problem continues to exist. Just spent two hours tracking this down.

Any chance we can get a patch of some sort committed?

The patch in #5 is not acceptable, because we shouldn't need to load image.gd.inc for every request.

This bug occurs when the image..inc file does not exist for the selected image toolkit. The most common case in which this error is encountered is when the user has imageapi installed, and has selected the imagemagick image toolkit, but the corresponding image.imagemagick.inc file can not be found.

The attached path changes the logic to automatically fall back to GD if possible when the image..inc file for the selected toolkit can not be found. It also creates watchdog errors if the image..inc file can not be loaded, indicating the issue, and whether or not it was able to successfully fall back to GD.

Renamed the previous patch so that the test system won't ignore it.

#5: include-image.gd_.inc-in-common.inc_.patch queued for re-testing.

no errors after reinstall the modules Image 6.x-1.0 and ImageAPI 6.x-1.9

Looking at the patch I wanted to raise a few questions:

• Nothing happens if it is unable to load image.gd.inc, i.e there's no ELSE clause on the following code: if ($toolkit_file = './includes/image.gd.inc' && file_exists($toolkit_file)) {
• On the watchdog() calls there's nothing assigned to the '%toolkit_file' arguments, i.e. shouldn't it be e.g. '%toolkit_file' => $toolkit_file ?

Another issue with the patch: it changes the value of $toolkit_file causing the watchdog() lines to output the wrong filename, they'll output "./includes/image.gd.inc" instead of the file that was originally attempted.

Here's a version that should resolve the issues I raised.

I'm no programmer, so the patch code is beyond me. But, it seems the gist of this thread is that using ImageAPI w/ ImageMagick causes the WOD. I am using neither (in some cases the modules are there but not enabled) and have gotten the WOD updating from 6.18 to 6.19 and then to 6.20. The last time, I had to use drush to disable any module that was image related, to be able to even log into some of my sites, as I got the WOD on .../user. Then quickly enable them again.

I have these enabled. Image, ImageAssist, Image Attach, and Image Import on my sites.

So, if I have a site with just the enabled list above (and I do) and I get the WOD using GD toolkit when I update core (and I did) where do I go from here? Is patching core the answer? I certainly wouldn't think so. Is using a different toolkit the answer? I could embrace that answer. Or, is it that, if I understood the patch conversation better I wouldn't be asking these questions? I could also get behind that answer. lol

Thanks for helping us code illiterates,

BH

No patching needed guys. When you update the modules you have manually replace the /server-root/includes/image.inc as done by Hetta in #295854: WSOD when the image.<toolkit>.inc file for the selected image toolkit is not found.#comment-2102882 .
For some reason drupal is looking for *inc files in /server-root/includes/ which are obviously not updated. This is not only image module problem I've just updated cck fields and had the same troubles.

Reverting issue title

Again I must admit I may not be the sharpest knife in the drawer on this sort of thing.
So, where does one get an updated image.inc file to place in the /server-root/includes/ location. I am not using image.imagemagick.inc, just GD. I also see a image.gd.inc file in /server-root/includes/. That then begs a new compound question. Which do I manually update and from whence do I get said updated file?

BH

@bhardison:

See http://drupal.org/patch/apply

#33: drupal-n295854-33.patch queued for re-testing.

@brianV

Seems the patch fails testing, so I am leery of using it. Thanks anyway. So I am no less foggy on this than I was in my reply #38.

Seems odd this problem.

BH

Core 6 does not have test so this fail is erroneousness

+++ includes/image.inc	9 Dec 2010 17:01:40 -0000
@@ -67,8 +67,23 @@ function image_get_toolkit() {
+      if ($gd_file = './includes/image.gd.inc' && file_exists($gd_file)) {

This file is a part of core!!! so no need to check it's existence this leads to useless IO

Powered by Dreditor.

Now I got this issue.
What do I do?

@Daniel Holm this is not going to be applied to 6.x and only 6.x-dev, so either apply patch yourself or use -dev/git sources.

rerolled patch which adds suggestion from #43, applies to 6.x-dev git sources.

left old if statement on last patch, this removes it.

re-queued for testing, whitespace--.

#49

When I apply this patch I get the error:


Parse error: syntax error, unexpected T_ELSE in /includes/image.inc on line 86


Line 86 and 87 are:

else {
watchdog('php', 'Image handling toolkit %toolkit selected, but %toolkit_file could not be loaded. Attempted to fall back to GD toolkit, but %gd_file could not be loaded.', array('%toolkit' => $toolkit, '%toolkit_file' => $toolkit_file, '%gd_file' => $gd_file), WATCHDOG_ERROR);


I had just upgraded from D6.20 - 6.22

I edited out these three lines from includes/image.inc :

/*    elseif (!image_gd_check_settings()) {  
      $toolkit = FALSE;  
    }   */

It seems to be working fine.

I would revert to 6.20 but I don't see any comments on that or whether it fixes the problem.

Hi. I just had this issue upgrading from drupal 6.22 to 6.25. It was fixed after re-submitting the form of toolkit settings for GD

Hey Radiobuzzer,

Could you explain that fix better? what do you mean

re-submitting the form of toolkit settings for GD

I have just upgraded from an older version 6.13 to 6.25 and I now have what seems to be teh same issue. Posted here.
http://drupal.org/node/1530346#comment-5863754

thanks!

Oh ok, I figured this out. in settings image toolkit. Why this was required is a mystery...

#52 FTW!! Thank you so much!

Thanks! http://mysite.com/admin/settings/image-toolkit and refreshing the settings cleared whatever the problem was. Thanks!

I also had this problem after upgrading drupal Core to 6.31

#11 worked for me, but a little precision :

I first tried to re-save gd conf from the menu entry which send you to :
http://www.mysite.com/admin/settings/imageapi/config/imageapi_gd
this didn't work

then I tried with the direct url acces :
http://www.mysite.com/admin/settings/image-toolkit
and it works !

We should yearly make a big fiesta where we could burn a big drupal puppet to avoid this kind of problems !