Import Profile picture doesn't work

same issue here.

Does uploading user pictures work?
Can you add a picture to your new Drupal account in the user settings Edit section?

twitter photos import OK but facebook don't. I can upload a user photo through usual Drupal edit user.

Does not work for me for Google profile

There a problem with the facebook import on the 7.x Drupal version.

Here's the issue with facebook. It can semi-easily get fixed. Might be a similar issue with other providers.

Here's the error:

Profile Image Import: Only JPEG, PNG and GIF images are allowed.

The imported facebook image URL looks like this

http://graph.facebook.com/715925423/picture?type=large

This is a redirect to an actual JPG, but this URL is not. The spider you have in the RPX code needs to follow the redirect. Currently RPX is simply using PHP's copy() to pull in the file. I've changed the code to use proper drupal functions for download. Supplied is the patch for the 7.x-2.0 version of rpx. This will need to get back ported to Drupal 6 & upstreamed to 7.x-2.1

I have no problem to change copy() to system_retrieve_file(), since the
latter is probably the preferred way of doing this in Drupal.

However, I can't reproduce the issue. For example, this URL
http://graph.facebook.com/100001330711472/picture?type=large is
handled fine. And yours resolves the same way as this one, therefore I
don't see why yours should create any problems.

Besides, system_retrieve_file() is not available in Drupal 6.

it seemed to resolve the issue on my server. Might want more people to give it a go and see if it resolve their issue.

PHP's copy() seems to use fopen() to handle the downloads. fopen() by default handles up to 20 redirects, so it should work on most servers. Using copy() to downloads depends on some PHP settings (allow_url_fopen) though, which may not be enabled on some hosts, which might be why they are having problems.

It's enabled in my server though, and I'm still having issues. I have a feeling it's because of the redirect, as twitter seems to download fine.

Either way, after this change it appears to be resolved on my end. This might be because in system_retrieve_file explicitly sets certain variables regarding download, aka 'max_redirects = 3'

system_retrieve_file() is simply a nice wrapper they added in Drupal 7. In Drupal 6, you'll need to duplicate it and use drupal_http_request() instead =(

I just upgraded to 7.x-2.1-rc1 and had to re-apply this patch.

I'm experiencing this problem with the 6.x.2-1 version of the module. My server has allow_url_fopen turned on. Anyone have a comparable fix for Drupal 6 (e.g., using drupal_http_request())?

I can confirm this problem still exists in 7.x-2.2 and has not been fixed. It apparently is not a problem on some servers and is a problem on others; on mine, the full "http://graph.facebook.com/XYZ/picture?type=large" URL definitely does not get read and copied as the JPEG file it points to. The fix suggested by j0rd worked perfectly for me.

Yes, the problem is still there in my new (as of today) installation. It has moved to line 354, but is otherwise the same.

However, I applied the patch and the picture was still not saved.

The system_retrieve_file is failing on https://graph.facebook.com/100000153017678/picture?type=large although that address works fine in a browser address bar.

It is now saving the picture in the user object, but not in the profile (Profile2) field as I have set up.

@NancyDru there are some PHP settings which effect system_retrieve_file() as well. Take a look at post #10. Not sure if that effects you though, but something to look into.

My issue is not really the same as the OP, so you can ignore me. We don't use the user picture, we use a profile field (I don't know why). This module simply does not allow for that.

Hi,

For the people that have this module working : do I need some special server settings for this module ?

I applied jOrd's patch with no success. I'm using the 7.x-2.2 module version.

I've tried debugging this and what I found was that , when the module calls either "copy($photo_url, $tmp_photo_realpath);" or "system_retrieve_file($photo_url, $tmp_photo_realpath, FALSE, FILE_EXISTS_REPLACE);" , the result is the same : a blank file.

All/any help is greatly appreciated.

Edit : reinstalled the server and the FB images are saved. Apparently the behaviour above was caused by the server state.

I'm having this same issue on the 2.5 version of the module.
When you say "reinstalled the server..." what exactly do you mean?

You set up a new Apache server? Reinstalled Drupal? All that? (Sorry, not a sysadmin or dev...)

Bump. Trying to map profile photo to a custom image field so far without success. Anyone figured this out?

The problem is the rpx form_alter function for the user registration is very simple (for instance, assumes a "value" element) and doesn't assume any unusual field types on the form, such as a file field. I added an additional form_alter hook in a project-specific module to bridge the gap; making this standard behavior would require a fair amount of work abstracting those field functions in the rpx module.

/**
 * Implements hook_form_alter().
 */
function my_module_form_user_register_form_alter(&$form, &$form_state) {
  if (!$rpx_data = rpx_core_get_rpx_session()) {
    return;
  }
  $field_map = variable_get('rpx_profile_fields_map', array());
  foreach($field_map as $field_mapping) {
    if ($field_mapping['field'] == 'field_user_picture') {
      if ($mapped_value = _rpx_data_map($rpx_data, $field_mapping['fid'])) {
        $file_temp = file_get_contents($mapped_value);
        $file_temp = file_save_data($file_temp);
        file_usage_add($file_temp, 'user', 'user', 0);
        $form['field_user_picture'][LANGUAGE_NONE][0]['#default_value']['fid'] = $file_temp->fid;
      }
    }
  }  
}

So far working alright...

For the Apache issue it's possible the server isn't configured to allow file writes to the system temp directory. This shouldn't be an issue in the next version of the module.

Meanwhile dafeder has a great solution for unique mapping needs. For the next version of our module we're looking at better hooks for mapping.

Cheers,
Rebekah