I was reading various comments / issues around all of this, without finding a solution to the following problem when using imagecache profile pictures:

  1. suppose you've defined a preset "avatar" for a nice, small-sized avatar on all your other bits of content where you want profile pictures
  2. you've created a view with such avatar pictures and it's in a sidebar
  3. you navigate to your profile page, and all the avatars become the size you selected for your profile images, which are of course much larger.

I've read the other fixes regarding the imagecache_profiles_preprocess_user_picture function, but those don't work in this case. However, I think I have come up with a solution. The problem is that Drupal doesn't differentiate between the main profile picture and any other user picture. There are no indicators in any of the data structures. So, I did the following within the imagechache_profiles.module file to address this:

  1. hook_user offers the opportunity to do something when stuff happens with user. So, I modified the imagecache_profiles_user function right at the end to include
    <?php
     
    elseif ( $op == 'view' || $op == 'form' && $category == 'account' ) {
       
    $account->profile_picture = TRUE;
      }
    ?>

    This adds a new element to the $account object to say, "Hey, I'm either looking at a profile or editing it, so there's a profile picture!"
  2. I changed the condition in the imagecache_profiles_preprocess_user_picture function as follows:
    <?php
           
    if ( ( is_numeric(arg(1)) ||
                      (
    module_exists('me') && arg(1) == me_variable_get('me_alias') ) ) &&
                     
    $account->profile_picture ) {
    ?>

    This leverages the new data element in the $account data structure. In other words, only make it the profile preset if it is really a profile picture.
  3. There's an odd execution order that I've not figured out yet, but apparently imagecache_profile_user is called after user_user, so the profile picture is already part of the content and formatted (to the default little avatar size) by the time my #1 above actually occurs, so the next thing to do is create a new function and alter another one.
    • New function:
      <?php
      function imagecache_profiles_profile_alter( &$account ) {
        if (
      $account->profile_picture ) {
         
      $account->content['user_picture'] = array(
           
      '#value' => theme('user_picture', $account),
           
      '#weight' => -10,
          );
        }
      }
      ?>

      This function alters the data structure prior to rendering, to replace the tiny avatar picture with the actual profile picture. At this point, imagecache_profile_user has executed, and if this is the picture for viewing or editing a user profile, the the profile_picture attribute is set to TRUE. So calling the theme function again will result in the condition above in #2 in the imagecache_profiles_preprocess_user_picture function to evaluate to TRUE, and so the correct preset will be chosen for the theme function.
    • ...but that function only works for 'view', so we have to alter the imagecache_profiles_form_user_profile_form_alter function and add the following at the end of it:
      <?php
      $form
      ['picture']['current_picture'] = array(
           
      '#value' => theme('user_picture', $form['_account']['#value']),
            );
      ?>

      This resets the user picture in the edit form to the larger size as well.

And I think that's it. Now my pages render correctly. It's a bit of wasted effort in calling the imagecache_profiles_preprocess_user_picture function a couple of times for the profile pages, but I can't see any other way of doing this to keep all the changes within the imagecache_profile module and not manipulate core.

Comments

Thanx a lot for review, I already in refactoring profile picture mostly about editing capabilities.

Can you provide a patch against current 6-dev, I think it's time to start branch 2.0 for this module

Oh boy! I'm a sad little Windows XP Drupal programmer (sort of) here... patch against dev, hu? hmmmmmm.... i almost think it's easier if i just edit dev and send it to you... :|

You could try read http://drupal.org/patch/create there's instruction for windows too.

StatusFileSize
new5.58 KB

OK, try this and see if it works. For an added bonus, I included the functionality to have a node preset different from the default. I need this as I'm also using the facebook-style status module, and I want the statuses in the block view to have tiny avatars instead of big ones.

It's working on my site.

Version:6.x-1.3» 6.x-1.x-dev
Category:bug» feature
Status:Active» Needs review

Changes are reasonable, so let's others review.
Writing code you should follow http://drupal.org/coding-standards
Node settings issue #362245: Add separate setting for node posts

I advanced user profile kit after the patch is no longer the Profile picture preset. Everything else works. Have you a tip. Thank you. Greetings

Made a small error in function imagecache_profiles_user. I discovered it when I was creating new users, where I got an error message when trying to assign FALSE to $account->profile_picture, since $account doesn't seem to be populated at this point. So, I added a simple check around the assignment as follows:

<?php
function imagecache_profiles_user($op, &$edit, &$account, $category = NULL) {
  if (
$account->uid > 0 ) {
   
$account->profile_picture = FALSE;
  }
  if (
$op == 'submit' && $category == 'account') {
?>

The updated patch is attached.

As for #6 above, I'm afraid I don't understand the comment.

StatusFileSize
new162.06 KB
new106.04 KB
new186.56 KB
new112.34 KB

I'm sorry for my bad English. I packed a few pictures in order to understand perhaps to make.

Image 1+1a, without a patch.
Image 2+2a with a patch.

Can you help me, that it goes well with patch. Thanks for your help.

Thanks for the brilliant patch they have created. Greetings

I'm still not sure I really understand the problem. However, it appears that you are using some customised profile presentation, in which you are using a content type containing a picture so show the user picture somehow, as opposed to simply displaying the native profile page that comes with Drupal, yes? In that case, the patch and module are working as designed, as there is no explicit support for such customised profile presentation. I'd need to know more about exactly how you are doing what you are doing.

Hi I would not know what I have adjusted. I user "Advance Profile Kit" with "image cache profile" and "Image Field avatar". The profiles with Panels Sun compiled as it was done with APK. I have not changed the code or layout. What they need to know?? Thank you very much and Sorry for my bad english.

OK, so then in reality, you're not really viewing the profile, picture native to Drupal (which is what the patch resizes), but the picture of the user in a content type, correct? So in that case, I suspect the "node" size is what is being applied, since you're really looking at a node. I'm not familiar with the Advanced Profile Kit, and how it treats your substitute for a profile picture. What is the node type for your profile?

OK, try this patch. It ads capability to specify a preset per node type to override the default node preset. Not sure it this will solve your problem, but does provide more functionality. :-)

ohh it is wonderful work there, many many thanks. Regards

Thanks sdsheridan!!!

Your patch is really usefull :)

Status:Needs review» Needs work

@sdsheridan Please, check http://drupal.org/coding-standards
There's another issue about node settings #362245: Add separate setting for node posts

Status:Needs work» Needs review
StatusFileSize
new3.55 KB

This logic code needed a lot of work. We can actually use hook_profile_alter() to change the user profile display, and not alter any user pictures on the same page that should be using the default preset instead. Plus some cleanups in the preprocess logic. I can roll this for D7 too if you like.

This change looks more reasonable then current except comment detection.
There was a long discussion about comment so let's leave this hunk as is

<?php
-    // If viewing a comment
-    if (is_object($account) && array_key_exists('cid', get_object_vars($account))) {
-      if (
variable_get('user_picture_imagecache_comments', 0)) {
-       
$size = variable_get('user_picture_imagecache_comments', 0);
-      }
-    }
?>

I can't remember all details but $comment have to be object with cid property

I think we could use preprocess_comment to setup preset property as you proposed

EDIT I scare if we start using template_preprocess_comment() this will lead to duplicate calls to theme_user_picture()

Suppose requirement that $comment ($account) should be object to detect comment flows from comment preview. Also I remember that sometimes node object have CID property

Which is exactly what if (!empty($account->cid) ...) is checking in the patch but only requires one function call instead of three. If $account is not an object it will fail.

Sure, but isset() seem more preferable because does not throw notices

I have PHP_NOTICES enabled. Please try because empty() does not cause one. isset() vs empty() is a matter of preference, although if $account->cid = 0 then isset() will still return TRUE when !empty() will return FALSE, which is likely desired as there cannot be a comment ID of 0.

OK, I will test this - node previews, comment previews and private messages are caused most troubles

I think better to lower module weight to -10 and use preprocess for comments to setup flag-property imagecache_profiles_comment

same could be done for nodes

EDIT by this way only user/X/edit and same page with me module should be tested, because image shown on this page after upload

That could likely be a follow-up patch since this patch doesn't change the actual logic of comment detection (still checks for presence of $account->cid), it just shortens it.

Did a quick test with using three different presets (large = profile, medium = default, small = comment) and it is working great. Not seeing any new errors as a result.

Status:Needs review» Patch (to be ported)

Version:6.x-1.x-dev» 7.x-1.x-dev
Status:Patch (to be ported)» Needs review
StatusFileSize
new7.17 KB

Rolled for D7.

Status:Needs review» Fixed

Awesome! :D

Didn't think about it that way, but i like it. :-) I was trying to preserve the module author's style / logic, but guess I should have stepped back and thought about it more. Does the patch preserve the per-content/node-type settings as well?

Shawn

@sdsheridan I see no reason to make this more complicated! no need to make setting per-node-type because this will require another settings somewhere (suppose on node settings page)

Well, save for someone was looking for that feature (#6 below), and I need it at least at the 'node different from default' level, and I can see where I might want it in future so that different content types may employ different user pic sizes.

The patch I created (#12) does that, and the settings are where the other image_cache presets are. So while yes it is another setting, it's still managed in a central location along with everything else. I think it's a nice added feature for quite little increased complexity. Just my two bits worth.

If it doesn't make it in, I'll just have to keep patching the module, which is unfortunate, but not impossible.

Shawn

Status:Fixed» Needs work
Issue tags:+Needs Documentation

sdsheridan, suppose it's not hard to write 3 lines in custom module to override $node->imagecache_preset (D6) and $node->user_picture_style (D7)

I think we need add this into readme

Andy:

As a module maintainer, of course at the end of the day you get to decide. It strikes me that asking people to write custom php code and understand how to build their own custom module and integrate it into their site is a bit un-user-friendly, when a few simple settings and some built-in code would do the job, and would inhibit someone from using this module. But then perhaps I'm wrong.

Shawn

Keeping track of this thread...

OK, let's decide on place where to place a settings form for per-node settings for avatars

PS: I'm going to include this in upcoming release

Well, from a usability standpoint, might be best to keep things altogether, so that when someone is choosing what imagecache size for a user's picture on a node, they'd know to always go to user settings. That said, if I was creating a new content type, it would be nice to just do it all in one stop. Hey, how about both places? On the node form and under user settings? :-)

Shawn

I'm going to release a drupal 7 version so is there still any interest to include per-node-settings?

Definitely. :-)

D7 has setting to display Author and date at admin/structure/types/manage/article - suppose it's a good place for avatar style!

I think having the ability to set a different size photo for specific node types would be very useful. It would also be great to configure a different size photo for each build mode / view mode. Could this module be used to expose the profile photo of the node author as a field for specific node types, so the the default cck display settings could be used to configure the actual settings? This would be more powerful than providing the ability to set a specific size for a node type, as it would allow for unique sizes and placement within each build mode for the the given node type.

Status:Needs work» Postponed (maintainer needs more info)

it seems this feature is not popular, let's wait for opinions and patches

I'd love a feature like this! It would be a great way to let the user find out more about each other, without cluttering the interface of the other node! I'd really appreciate it you would include it!

wow! it is still not implemented? I definitelly would like to have different presets on all different node types/comments etc

Incredible this haven't been committed yet! :( I'm having the issue when the preset displays on Heartbeat activity blocks!