I just used this module to import user icons, but after I imported the users, the images are not displayed on the profile pages. It can't come from the feed configuration, because I also made an image field associated with the user, which works.

I've attached a view of the table file_managed from the database.
In the column 'uid', the 1 corresponds to the images imported with this module (so the user icon).
And the 0 corresponds to the images imported with the core module (the image field added to the user)

I found the recordings made by this module a bit strange, but the worth is that in 'users' table, the attribute 'picture' is always set to '0', and if I force it to another number, it correctly displays an image in the profile page.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

firfin’s picture

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.

firfin’s picture

Title: Imported pictures are not linked to the right user » Imported pictures incorrectly linked to importer instead of importee
Priority: Major » Critical

Improved issue title.

chrisguindon’s picture

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

chrisguindon’s picture

Assigned: Unassigned » chrisguindon
Status: Active » Needs review
FileSize
1.09 KB

Minor changes to the comments in my previous patch.

firfin’s picture

Patch looks good to me.

druderman’s picture

The patch worked fine for me.

Jance’s picture

Works for me as well.

firfin’s picture

Status: Needs review » Reviewed & tested by the community
nasia123’s picture

Priority: Critical » Major
Status: Reviewed & tested by the community » Needs work

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 ...

nasia123’s picture

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

firfin’s picture

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

chrisguindon’s picture

Issue summary: View changes
Status: Needs work » Needs review
bobojo’s picture

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.

thatpixguy’s picture

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.

webservant316’s picture

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;
}
stevenx’s picture

#15 works almost

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

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

The comma is wrong :)

THANKS

webservant316’s picture

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

jjlsarlat’s picture

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

rcodina’s picture

#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.

iyyappan.govind’s picture

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;
 
}
rcodina’s picture

@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.

iyyappan.govind’s picture

Patch #19 works for me...

Thanks

chrisguindon’s picture

Assigned: chrisguindon » Unassigned
firfin’s picture

Status: Needs review » Reviewed & tested by the community

#19 works for me.

surfgatinho’s picture

Status: Reviewed & tested by the community » Needs work

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

iyyappan.govind’s picture

FileSize
34.94 KB

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

Thanks

rcodina’s picture

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

HansKuiters’s picture

Status: Needs work » Reviewed & tested by the community

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;