Imported pictures incorrectly linked to importer instead of importee

It seems that in the file_managed table the uid is incorrectly set to UID of the user executing the import.
So most people (running it as admin/superuser) will see uid 1 here.
Instead the UID should be set to the freshly imported/created user.

As for the 'picture' field in the 'users' table, that is where the file-id of the user picture is stored. This doesn't get filled properly.

Will delve deeper into this tomorrow. Need some sleep first.

Improved issue title.

I had the same problem tonight.

I created a patch to fix it. Basically $entity->picture needs the full $file object.

$entity->picture = $file;

I am also changing the way the filename is created. It now uses the same filename from the source.

$extension = pathinfo($path, PATHINFO_BASENAME);

This patch doesn't change the uid in {file_managed} because it's not necessary to fix this.

The uid in {file_managed} is from the global $user.

file_save_data/7

Minor changes to the comments in my previous patch.

Patch looks good to me.

The patch worked fine for me.

Works for me as well.

This is not working for me.
images are not imported correctly

picture in users table should have id of the corresponding file, and it remains 0 ...

Correct this now and it works,
all user's images must be in the directory sites\default\files\styles\user-picture\public\pictures

all images are now imported correctly, patch works now

@nasia123: So, you are saying it does work correctly? Mind putting the status back then? Maybe we can get this committed then?

I applied the patch with no luck. I have a list of URLs that people are using for their avatars on the current site, and I want to download them and save them to the new Drupal site, but it doesn't seem to be processing the images at all.

This patch didn't work for me, setting $entity->picture to the $file object instead of $file->fid results in the image not being linked as the users picture.

Is there a particular version of Feeds Import in which it is expecting the full file object? I'm running 7.x-2.0-alpha8

Having the file_usage updated for imported user pictures would be really handy, but as far as I can tell, there isn't enough information available in the feeds_user_picture_set_target function to do call file_usage_add manually.

EDIT:

Just noticed there was a newer version, 7.x-3.0-rc1 that wasn't coming up in the automatic updates check. This patch doesn't work for me with that version either.

this worked for me

/**
 * Callback for mapping. Here is where the actual mapping happens.
 */
function feeds_user_picture_set_target($source, $entity, $target, $value) {
  //If not a valid URL or path
  $value = reset($value);
  if (!file_exists($value) && !valid_url($value)) {
    return;
  }
  
  //Get file type & name
  $path = parse_url($value, PHP_URL_PATH);
  $extension = pathinfo($path, PATHINFO_EXTENSION);
  $destination_filename = "picture-" . $entity->name . "." , $extension;

  $picture_directory = file_default_scheme() . '://' . variable_get('user_picture_path', 'pictures');
  $destination_uri = $picture_directory . '/' . $destination_filename;
  
  //Get image from server
  $image = file_get_contents($value);
  $file = file_save_data($image, $destination_uri, FILE_EXISTS_RENAME);
  
  //$account->picture is expecting FID, not the whole file.
  $entity->picture = $file;
}

#15 works almost

$destination_filename = "picture-" . $entity->name . "." , $extension;

needs to be
$destination_filename = "picture-" . $entity->name . "." . $extension;

The comma is wrong :)

THANKS

Oh yeah. Sorry, I obviously had to fix that for it to work and I forgot to post back to fix. Thanks.

#14 worked fine for me, after applying the little fix #15 mentioned.

#15 works for me. I enclose the patch version of #15 patch with fix on #16. With one more positive review I think this can be moved to RTBC state.

This is i used

function feeds_user_picture_set_target(FeedsSource $source, $entity, $target, $value) {
  //If not a valid URL or path
  $value = reset($value);
  if (!file_exists($value) && !valid_url($value)) {
    return;
  }
  
  //Get file type & name
  $path = parse_url($value, PHP_URL_PATH);
  $extension = pathinfo($path, PATHINFO_EXTENSION);
  $destination_filename = "picture.$extension";

  $picture_directory = file_default_scheme() . '://' . variable_get('user_picture_path', 'pictures');
  $destination_uri = $picture_directory . '/' . $destination_filename;
  
  //Get image from server
  $image = file_get_contents($value);
  $file = file_save_data($image, $destination_uri, FILE_EXISTS_RENAME);
  $entity->picture = $file;
 
}

@iyyappan govind Your code is the same like in #15. Why you don't try the patch on #19 and let us know if it works for you? Patches need positive reviews to be commited. This is the only way to get this fixed on official release.

Patch #19 works for me...

Thanks

#19 works for me.

Patch not working for me.

I'm importing users from a non-Drupal site. This works fine and the user photos are uploaded to the correct directory.

However, even with the patch the necessary managed file values are not being set correctly in the DB. 'picture' in the user table is always set to 1 and 'uid' in the file_managed table is also always set to 1

This patch is worked for me. I have attached the file which i used to import the user picture.

Thanks

@surfgatinho Have you checked out permissions on your Drupal public directory?

Patch #19 works almost.

//$account->picture is expecting FID, not the whole file.
  $entity->picture = $file;

should be as the comment says

//$account->picture is expecting FID, not the whole file.
  $entity->picture = $file->fid;

I'm not sure about the filename rewrite. The patch uses

"picture-" . $entity->name . "." . $extension;

Why not keep the original filename?

Edit:
After testing the last line should be without FID.

  $entity->picture = $file;