Imagecache is working properly with any node type in views, except user profile pics. I have tried several different imagecache presets, and none seem to resize user pics. However, I confirm that any other photo field, in any other node, resizes without any issues.

any ideas?

CommentFileSizeAuthor
#21 icp-views.PNG10.36 KBandypost
#21 icp-views2.PNG29.77 KBandypost
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Sol Roth’s picture

Anonymous’s picture

+1 . updated to last version. Then the images aren't resized anymore. Pictures from the classic "pictures" directory are printed, no imagecache preset directory is created.

andypost’s picture

Which version of views are you using? Also please provide more info about genereated html for user pictures

rot3r1’s picture

i have the same issue i create present and select it in views but nothing resized !

Aldus’s picture

subscribe... in views user's profiles portraits don't follow imagecache directives

kevinquillen’s picture

+1 and subscribe.

kevinquillen’s picture

Also, I don't use Views on the user account page, it is not resizing there.

I am using Views with User Relationships to display a user pic with a 'friend'- and it is not resizing.

design.er’s picture

I've upgraded to ImageAPI 6.x-1.10, Filefield 6.x-3.10, Imagefield, 6.x-3.10 and Imagecache 6.x-2.0-beta12 a few minutes ago and since then I have exactly the same problems: All the user pictures are showed in original size, no imagecache preset.
Please help!

design.er’s picture

Setting the mentionend modules (ImageAPI, Filefield, Imagefield and Imagecache) to the previous version and everything works great again. So it seems to be a problem with one of the updates.
I hope that helps to find the bug.

kevinquillen’s picture

Which one of those modules (or all?) can be downgraded and how? Were they code updates or did the database change at all?

design.er’s picture

Unfortunately I didn't have the time to find out which module caused the problem because it occurred on a live-site and I had to fix it as soon as possible. In my case I had to restore the db tables to get things corrected... so it seems that there were db changes.

kevinquillen’s picture

I got it.

If anyone here is using the RealName module, that would be the issue.

Apply the patch from Dave Reid here and it will not affect the User picture anymore:

http://drupal.org/node/1070102

design.er’s picture

How weird is that?! :) 1 year ago I had problems with the forum access permissions and found out that the realname module was causing this problem. Sometimes I can't understand how such things can happen... they have nothing in common. :D
Thanks a lot!

kevinquillen’s picture

RealName is incredibly useful but this threw me for a loop too.

I think the issue was RealName strongarming the $user object to change some outputs, and overwriting $user->picture, which would explain why Imagecache Profile wasn't working.

miccelito’s picture

I don't have RealName module but nevertheless the ImageCache Profiles module doesn't work for the moment, I have various views blocks that contain user:picture fields with imagecache pretets but none of those presets appear on the website anymore. I guess the ImageCache Profiles module needs an update!?

miccelito’s picture

This issue started after updating the module ImageCache from version 6x-2.0-beta10 to version 6x-2.0-beta12. ImageCache Profiles was working fine with ImageCache version 6x-2.0-beta10.

andypost’s picture

if anyone has troubles with ICP + realname - please use 6.x-1.x-dev until 1.5 will be released see #1070102-26: Latest dev release conflicts with ImageCache Profiles module

About new version on imagecache (b12) I see no big changes that can break ICP

If someone can make a deeper investigation please do

bryancasler’s picture

I'm using the current D7.x dev without the realname module, and I am running into the same problem. In views I can select "imagecache" presets, but when viewing the node they are ignored and the original image is displayed.

bryancasler’s picture

Should this bug report be changed from 6.x-1.3 to 7.x-1.x-dev?

bryancasler’s picture

I can also confirm that this bug also exists in the 7.x-1.0-rc2 branch.

Note: I am using views 7.x-3.x-dev from 2011-05-29

andypost’s picture

FileSize
29.77 KB
10.36 KB

Just tested with current views 7.x-dev and it works fine

Screens attached... so I leave this open against 6.x because cant test right now

bryancasler’s picture

Thanks andypost, I recently upgraded my site from D6->D7. I had to change all the filepath fields in my "file_managed" table from like this "sites/default/files/pictures/picture-1966.jpg" to like this "public://pictures/picture-1966.jpg". Flushed the site cache and now everything is working.

andypost’s picture

Suppose 6.x troubles caused be new version of imagecache 6x-2.0-beta12 as pointer at #16

Glad to get any feedback or patches

miccelito’s picture

Also, as I have mentioned before in another issue thread, this issue may occur after upgrade to imagecache 6x-2.0-beta12, if you are theming user-picture.tpl.php in your themed template.php.
I.e. some people have this code added in their themed template.php:

function MY_TEMPLATE_preprocess_user_picture(&$variables) {
  $variables['picture'] = '';
  if (variable_get('user_pictures', 0)) {
    $account = $variables['account'];
    if (!empty($account->picture) && file_exists($account->picture)) {
      $picture = file_create_url($account->picture);
    }
    else if (variable_get('user_picture_default', '')) {
      $picture = variable_get('user_picture_default', '');
    }

    if (isset($picture)) {
      $alt = t("@user's picture", array('@user' => $account->name ? $account->name : variable_get('anonymous', t('Anonymous'))));
      $variables['picture'] = theme('image', $picture, $alt, $alt, '', FALSE);
      if (!empty($account->uid) && user_access('access user profiles')) {
        $attributes = array('attributes' => array('title' => t('View user profile.')), 'html' => TRUE);
        $variables['picture'] = l($variables['picture'], "user/$account->uid", $attributes);
      }
    }
  }
}

This code would break certain functions such as imagecache profiles module+views user fields (maybe because of that Drupal or modules such as imagecache have been updated?). Anyways for those having problem with imagecache profiles module, pls take a look in your themed template.php if using that. I made a change in my themed template.php and now the Imagecache Profiles module works fine and presets for user fields in Views are displaying.

tribsel’s picture

I have the same problem, d6 with latest dev version and views 3. And im not using real name module and did not do any theming of user-picture.tpl.php. Presets for user fields in Views are displaying, thats not a problem. They just dont work, profile image is always same (original) size.

miccelito’s picture

Imagecache Profiles module works fine for me since some days, user fields presets set in Views are displaying correctly on the site.
Only thing I've done was update my themed template.php (/sites/all/themes/---/template.php) and clear cache (Performance task), twice.
First time with the code above (see #24) added in the end of the themed template.php, then cleared cache (Performance). Then again I removed the added code from the themed template.php and again clear cache. And suddenly Imagecache Profiles were displaying user pictures with imagecache presets correctly. Well, sounds weird doesn't it? But howsoever what made it start working for me...

As reference I'm using Drupal 6.22 with Zen 6.x-2.1, Imagecache Profiles 6.x-1.3, Imagecache 6.x-2.0-beta12, ImageAPI 6.x-1.10, Imagefield 6.x-3.10, Views 6.x-2.12, Imagecache Actions 6.x-1.8.

daniel-san’s picture

I can confirm that updating Realname Module to the 6.x-1.x-dev version worked for me. Now all of my imagecache profiles have begun to work again.

Thanks for the information.

vcrkid’s picture

Wow, after spending half the day chasing my tail on this problem, I'm glad I found this thread. Updating Realname Module to the 6.x-1.x-dev also worked for me!

deanflory’s picture

I too can confirm that updating to Realname 6.x-1.x-dev solved the issue with profile pictures not being resized by ImageCache Profiles. This also solved that same issue in FBSS Facebook-style Statuses where the user picture (class="picture") was using the original size image without any ImageCache resizing.

Some keywords here to help searchers:

User picture not resizing
User picture too large
User picture ImageCache Profiles
FBSS picture size

hatuhay’s picture

Subcribing...

Grzegorz Zbiński’s picture

Here is another way to deal with profile pictures in block using views, views customfield (php), imagecache.
http://drupal.org/node/1262572#comment-4964614
I've made it before I read this issue after huge upgrade.
Thanks for patch - I will keep it in my mind for future.

andypost’s picture

it seems that patch for realname been commited so can we close this issue?

Aldus’s picture

Version: 6.x-1.3 » 7.x-1.x-dev

well, maybe it's fixed in 6.x but not in 7.x . For me it's being ignored in views :(

bryancasler’s picture

Aldus take a look at my comment in #22 and see if that helps

Aldus’s picture

animelion, thanks, but I'm running a fresh D7 - didn't upgrade it

justindodge’s picture

The solution in#22 happened to solve my particular issue perfectly. I am not sure why this didn't happen automatically as part my D6 -> D7 upgrade...maybe this is a core bug?

At any rate, if anyone is curious, this is the database query I executed in order to convert:

UPDATE file_managed SET uri = REPLACE(uri, 'sites/default/files', 'public://');
bryancasler’s picture

Should we move this to core? Is it a bug with the upgrade path?

myha’s picture

Looked into module code and found the condition which need check for not altering picture in the views from our template.php:

function MY_TEMPLATE_preprocess_user_picture(&$variables) {
  // $variables['picture'] = '';
  if (variable_get('user_pictures', 0) && !isset($variables['account']->imagecache_preset)) {
    // ...
  }
}
pitxels’s picture

For me its working ok with the dropdown "Imagecache preset" and the images styles d7 have included like: "thumbnail" , "square_thumbnail", "medium" , "large"

But not working with the images styles I create myself.

justindodge’s picture

Found out a little hint about what may be going on as far as core issues.
function user_update_7012() of the user module has this:

// As a batch operation move the photos into the {file_managed} table and
  // update the {users} records.
  $limit = 500;
  $result = db_query_range("SELECT uid, picture FROM {users} WHERE picture <> '' AND uid > :uid ORDER BY uid", 0, $limit, array(':uid' => $sandbox['last_user_processed']));
  foreach ($result as $user) {
    // Don't bother adding files that don't exist.
    if (file_exists($user->picture)) {

For me, I was doing a dry run of my upgrade on a dev site that was not current with the files directory of the live site, and this seemed to be causing issues.

I'm thinking it probably shouldn't be the responsibility of the upgrade script to verify the existence of files, it should just update the db records, although I see what they were going for.

mansspams’s picture

In my case, it does not work with default image. Should we close this issue with 6.x tag and open 3 new issues with 7.x tag? Like "Add support for default image", "Does not work with custom image styles" or "Core upgrade path brakes ImageCache Profiles functionality"?

Update: #1107464: user default image doesn't get formatted

Arjean-1’s picture

The solution in#36 (#22) solved my particular issue too. Thx.
I'm not using the realname plugin.
I did however use the Unique avatar plugin, but removed it before upgrading to D7.
Not sure it relates though.

damtoul’s picture

Hello,

Any news about that bug? How can we solve it under D7 (Realname modulenot installed)?

Dam.

Geldora’s picture

#22 (#36) solved the problem for me too.

Should be a Drupal upgrade path bug, not this particular module, IMHO.

VictorMYeste’s picture

The solution in#36 (#22) solved mine too, and it was caused when I upgraded D6 to D7. Thanks a lot!