[function.getimagesize]: URL file-access is disabled in the server configuration

PHP 5 has the include function for remote files disabled by default and if your host is using another version of PHP and has secured the installation then you will also face this error.

Note that I was getting this error on the 6.x-1.3 version and I upgraded to 6.x-1.x and it's been working fine since then.

I have drupal 6.4 and had Gravatar 6.x-1.3 and I saw the same problem. After reading Dave's comment, I tried the 6.x-1.x-dev, but I still have the problem. On my site, this problem only occurs for users who are *not* using gravatars - the ones who *are* have no warnings.

I have read Narno's initial reply, but I am still a rank amateur and don't know what to do with what he wrote.

I just took a look at one of my sites...I am also still getting this error. My PHP installation allows remote files and it is erroring when a user has an image uploaded for their Drupal user picture and not using Gravatar. I'll look into the code to see if I can find out what's happening.

OK - let me know if you need any additional information or testing from my site.

Thank You!
JD

Hah! This patch:
1. Fixes picture for users without gravatar or uploaded picture when the site default picture is a relative URL (i.e. 'sites/all/default_avatar.jpg') or an absolute URL.
2. Fixes getimagesize errors with conditional checks for is_file($picture)
3. Fixes logic with 'width' => min($dimension[0], $real[0]), 'height' => min($dimension[0], $real[0]) - notice the height is using the width parameters of $dimension and $real. Needs to be $dimension[1] and $real[1].

Although I'm a little unsure why this module is enforcing the maximum picture dimensions for a default user image when the user.module doesn't enforce dimensions for default user pictures. I put in a comment alluding to this put didn't change the logic.

Revision to patch that fixes 'squaring' uploaded user pictures and now is ready for review.

I applied the patch in #8 (the second patch). The error messages went away, but so did many of the users pictures. For all but one of the non-gravatar pictures, their pages now simply have a text hyperlink labeled "'s picture" which links to their user page, but there is no picture. But one of the users has his picture working normally. It is a .gif, while none of the others are, so I tried making one of the other pictures into a gif and replacing the one they had, but that didn't make any difference.

I then disabled gravatar integration on the gravatar page under user management. Everyone's picture returned (except for the user who is using gravatar, of course). When I then re-enabled gravatar integration the behavior reverted to what it had been before.

I then both eneabled gravatar and set the "users can disabled gravatar" checkbox. When I went to the user page of one of the users whose picture had not been displayed, I noticed the "Enable Gravater" selection was checked and the picture was not visible. I unchecked the box and saved the settings, and then the picture was visible as expected. I went through the other users (luckily it is a new site with just a few users) and disabled gravatar for each of them, except for the user whose picture had displayed before - his was already unchecked.

Then, I went back to the gravatar control page and unclicked "users can disabled gravatar", then things behaved as I had expected, but when I added a new user that one had the same text-link problem.

Finally, I realized that if the "users can disabled gravatar" box is not clicked, the system will not use the user's already (or newly) loaded pictures. Once I grokked that everything else made sense. But, if I might make a suggestion: I would invert the sense of the "users can disabled gravater" and change the text to "users must use gravatar for pictures". When that selection is checked, the normal picture upload should be disabled, and the "'s picture" link should go away. I might be misunderstanding the point of the various selections, but I had assumed that turning on the gravatar module would not change the behavior of the system for users who hadn't selected it.

But, Thank You for the effort you've put into this!
JD

Jderoo, by chance do you have a default avatar image enabled? (under the gravatar settings or admin/user/settings)?

Jderoo, I looked into this a little bit, if you're going to enable the Gravatar module, it's assumed you're going to want to use some kind of default picture image if there is no Gravatar. If you don't want to have those links show up, you need to set the default picture image (under admin/user/settings) to a 0x0 blank image file. If you want to use the Gravatar module but not show pictures for users that don't currently have Gravatars, that's going to need to be made a feature request.

Re #10: I have the "Global default user image" selected - I do not think I changed it from its default.

Re #11: What I posted in #9 was rather long and rambling - I'll try to be more concise this time ;-) I have enabled gravatars on my site as an option for users, but based on my current user base, I do not expect it to be the primary way they provide avatars. Therefore, I would like to make it as easy as possible for them to upload images for their avatars in "the old fashioned way". But when I have gravatar enabled in the configuration page and I allow users to disable gravatar, their user setup pages start with gravatar enabled. They can still upload their own non-gravatar image without a warning or error, but they won't see the image. My request is essentially that the default behavior be the same as it is without the gravatar module enabled; if a user wants to use a gravatar, they should have to "opt-in" rather than "opt-out". I believe this could be done by changing the default value of the enable gravatar on the users page.

That change would be nice, but I don't think it is necessary - and I do appreciate the time and effort you have already put into this!

Thank You,
JD

Hi people

I'm having similar problems, this is the error message I'm getting:

* warning: getimagesize() [function.getimagesize]: php_network_getaddresses: getaddrinfo failed: hostname nor servname provided, or not known in /usr/home/conscioi/public_html/modules/gravatar/gravatar.module on line 112.
* warning: getimagesize(http://www.consciousvibe.co.za/files/default_pic.jpg) [function.getimagesize]: failed to open stream: Unknown error: 0 in /usr/home/conscioi/public_html/modules/gravatar/gravatar.module on line 112.

Is it the same as the others? I'm not too clued up about php and how the inner workings of modules so am a bit out of my depth.

Anyway, I'd like to know how to apply the patch, (if that's the answer to my problems) I've never done that before. Your help would be appreciated.

Thanks

harouni, what value do you have for your site's default user image (admin/user/settings)?

Hi Dave

I've uploaded this file:
http://www.consciousvibe.co.za/files/default_pic.jpg and using it as the default image for peeps who don't have a gravatar.

I'm using the full absolute url to this file in the "Default Picture:" space.

Thanks for your help, hope we can sort it out together :)

Yeah there's currently a problem when you have a full url entered as your default picture. I'm trying to make the whole default user picture a little more elegant for Drupal 7. You should be able to avoid this for now if you enter "files/default_pic.jpg" in the default picture option.

Dave Reid patch applicated on dev branch.

Hum, partielly applied : there a problem with $path = url($path, array('absolute' => TRUE));

Well I have used a relative path instead of a full URL for the avatar (set the path in Drupal users settings), using gravatar 6.x-1.4 and it didn't worked, so I reviewed the code and removed comment for this line Narno just talked about, and it works. It also works with full URL and this line uncommented... so I don't know why this line is commented in fact. Didn't test the rest of the patch for the moment, sorry.

Well there is at least one bug I found with this line of code... with multilingual sites using prefix in the path, it is adding the prefix to the path to the default picture (Drupal users settings). So we should specify that the path is not language dependent (since language path prefixes are not depending on the file system paths but on rewriting...when using clean URL's it does not make sense to add a prefix). So here's my take on this (also my first patch ever).

Reminder: This only fixes the relative path/absolute url problem, I don't have time right now to test the custom default avatars from gravatar.com.

Not sure that may be the proper way to remove language codes when using url(). It expects a language object, not a string. In the meantime, I un-commented the fix and committed the change to 6.x-1.x. If the language issue persists, we should open a different issue since it is different from the current issue.

That is right, it was also my first impression too (just didn't take care it should be an object as parameter). Also, maybe it is not really the best idea to use url() for this particular case, sure it can do the job, but the paths you set in various places in Drupal always refer to the base url, so it would be better to compose this path manually (it would also solve the language problem, but I am talking about the general principle of variable paths). I attached a patch written according to this idea. I tested various configurations and also tested the language issue and it fixes them.

Ok this should be officially fixed with the latest commit. I tested a global default user picture as an absolute url and as a relative url and it worked just fine.

Automatically closed -- issue fixed for two weeks with no activity.