If you create a view and add "User: picture" to it everything works fine, but when you decide to "Rewrite the output of this field" then nothing happens. Also "Output this field as a link" does not work correctly, the link is simply not used. Lastly, by default the user's picture links to the user's account and this cannot be disabled.

This field needs to have the same settings that the "User: name" field does.

CommentFileSizeAuthor
#32 Screen Shot 2012-08-01 at 10.30.41 AM.png29.42 KBjohnnydarkko
#18 views_userpicturerewrite_handler_field_user_picture.inc_.tar_.gz1.33 KBwiert
#5 views_userpicturerewrite.zip3.72 KBnicholas.alipaz

Comments

dawehner’s picture

dawehner
Primary language German
commented

The problem is, that views does a imlementation of drupal core.
So how does drupal core displays an user picture: it uses the theme "user_picture". There all logic is done, for example when should the image be linked etc.
So views does only call theme('user_picture').

To your bug report, i can rewrite the output

<a href="/foo/123">test</a>

So whats the problem with it?
Can you please export your view?

nicholas.alipaz’s picture

nicholas.alipaz commented
Title: User's Picture in views is not rewritable » "User: picture" link cannot be changed

ok, I went back and rechecked everything. I was able to rewrite it, so that is no longer an issue. But the issue still remains in that this field cannot have it's link changed.

I know you say it is due to the fact that it is rendered through the core theme function, but I feel that this is misleading. If it is "User: picture" I expect to get a picture and nothing else. Instead I get "User: picture linked to user profile". I could override the theme function I guess, but something still needs to change even if it is only the name of the field.

I suggest altering this field to behave the way "User: name" does.

Exclude from display
Rewrite the output of this field
Output this field as a link
Trim this field to a maximum length
Link this field to its user
Overwrite the value to display for anonymous users

All these settings should be available just as the "User: name" field has them.

dasch’s picture

dasch commented

I also have the problem that "Output this field as a link" does not work with User:Picture.
It would be nice to have it work.
I totally agree with the post above.
It would be a step forward just to hide the possibility "Output this field as a link". Users could spend their time to look for another solution.
Calling the field "User: picture linked to user profile" would also help to make this clear.

dasch’s picture

dasch commented

Rewriting works with
<a href="/foo/123">test</a>

but it does not work with

<a href="/foo/123">[picture]</a>

This is not a workaround for me. Maybe nicholas.alipaz can tell us how he solved this.

nicholas.alipaz’s picture

nicholas.alipaz commented
StatusFileSize
new views_userpicturerewrite.zip3.72 KB

Here was my solution. An override for the view handler that is packaged as a separate module. It simply overrides the User: picture field's options and format. If there is interest in it then it could be packaged as a separate module for drupal.org but I feel views should just implement something similar.

To use just install like any other module and edit your view to set the format for the User: picture field.

julesjs’s picture

julesjs commented

Great solution. With this i'm able to resize "User: picture" without using imagecache, just with plain ole HTML. It'll do for me. Thanks!

nicholas.alipaz’s picture

nicholas.alipaz commented

BTW, the part of most interest for the views developers will be this:

// $Id: $

/**
 * Field handler to provide simple renderer that allows using a themed user picture without link
 */
class views_userpicturerewrite_handler_field_user_picture extends views_handler_field_user_picture {
  /**
   * Add uid in the query so we can test for anonymous if needed.
   */
  function init(&$view, &$data) {
    parent::init($view, $data);
    if (!empty($this->options['overwrite_anonymous'])) {
      $this->additional_fields['uid'] = 'uid';
    }
  }

  function construct() {
    parent::construct();
    $this->additional_fields['uid'] = 'uid';
    $this->additional_fields['name'] = 'name';
  }

  function element_type() {
    return 'div';
  }

  function option_definition() {
    $options = parent::option_definition();

    $options['overwrite_anonymous'] = array('default' => FALSE);
    $options['anonymous_text'] = array('default' => '', 'translatable' => TRUE);

    return $options;
  }

  function options_form(&$form, &$form_state) {
    parent::options_form($form, $form_state);
    $opts = array(
      'user_picture_img' => 'Picture as image',
      'user_picture_link' => 'Picture linked to user',
      'user_picture_path' => 'Picture path (plain text)',
    );

    $form['overwrite_anonymous'] = array(
      '#title' => t('Overwrite the value to display for anonymous users'),
      '#type' => 'checkbox',
      '#default_value' => !empty($this->options['overwrite_anonymous']),
      '#description' => t('If selected, you will see a field to enter the text to use for anonymous users.'),
    );
    $form['anonymous_text'] = array(
      '#title' => t('Text to display for anonymous users'),
      '#type' => 'textfield',
      '#default_value' => $this->options['anonymous_text'],
      '#process' => array('views_process_dependency'),
      '#dependency' => array(
        'edit-options-overwrite-anonymous' => array(1),
      ),
    );
    $form['user_picture_format'] = array(
      '#title' => t('Format'),
      '#description' => t('This will override any other link you have set.'),
      '#type' => 'select',
      '#options' => $opts,
      '#default_value' => $this->options['user_picture_format'],
    );
    unset($form['empty']);
    unset($form['empty_zero']);
  }

  function render($values) {
    if (!empty($this->options['user_picture_format']) || !empty($this->options['overwrite_anonymous'])) {
      // Fake an account object.
      $account = new stdClass();
      $account->uid = $values->{$this->aliases['uid']};
      $account->name = $values->{$this->aliases['name']};
      $account->picture = (empty($values->{$this->field_alias})) ? url(variable_get('user_picture_default', '')) : $values->{$this->field_alias};
      $anonymous = (!empty($options['overwrite_anonymous']) && !$account->uid) ? check_plain($this->options['anonymous_text']) : FALSE;
      
      if ($anonymous !== FALSE) return $anonymous;
      switch ($this->options['user_picture_format']):
        case 'user_picture_img':
          return theme('views_userpicturerewrite_user_picture_img', $account); 
        case 'user_picture_link':
          return theme('user_picture', $account);
        case 'user_picture_path':
          return $val = (!empty($values->{$this->field_alias})) ? url($values->{$this->field_alias}) : url(variable_get('user_picture_default', ''));
      endswitch;
    }
    // Otherwise, there's no special handling, so return the data directly.
    return $values->{$this->field_alias};
  }
}

--
Los Angeles Web Design and development for Drupal.

mechdrupal’s picture

mechdrupal commented

just my opinion:

I also had that kind of problem with views with the changing of pics. here's what i i did:

just clone your customized view to make a reserve 2nd view, delete your 1st view, change pics by default with views disabled/deleted, go back to views, restore views by changing your cloned reserve 2nd view to 1st view.
Kapeesh! there you have it =) pics changed!

dawehner’s picture

dawehner
Primary language German
commented

You missed to add "user_picture_format" to the option_definition :)

nicholas.alipaz’s picture

nicholas.alipaz commented

mechdrupal, the process you are describing does not sound like a solution to this issue. It sounds like you were having some sort of caching issue. Not really sure what you are describing to tell you the truth. Read through the thread a little more to be sure what you are describing relates to what we are talking about and let us know if you aren't in the right thread.

dereine, that may be true, perhaps I should add it. Like I said in my previous post, "If there is interest in it then it could be packaged as a separate module for drupal.org but I feel views should just implement something similar." I would really just like this to get incorporated into views. If a maintainer is interested then I can make a patch, but I don't really want to go through the trouble if it won't be used. That is why I presented it as a separate addon module.
--
Los Angeles Web Design and development for Drupal.

drtrueblue’s picture

drtrueblue commented

Outstanding Work!

Nicholas.alipaz has restored my faith in Drupal. I am a relative noobe and spent about one hour wondering what on earth I was doing wrong. Thankfully google and the right key words brought me to this node and PRESTO!

Your module is concise, intuitive, and works perfectly. Wow, did you save me hours. Thank you so much.
What other modules have you developed because I trust they are valuable.

nocean’s picture

nocean commented

Thanks Nicholas -- great addition and agree, +1 to this being committed to the core Views module.

My only problem with the module, and if well-implemented in the core, this wouldn't be an issue, is that it doesn't make concessions for imagecached images like the regular User Picture handling in Views does. Easy enough to get around using an additional Views module for PHP fields, but would be great to have it all handled in one place.

merlinofchaos’s picture

merlinofchaos commented
Category: bug » feature

+1 to this being committed to the core Views module.

The only way that can happen is if there's a patch. There isn't a patch here.

Also this isn't a bug, this is a feature request.

Drupal Jedi’s picture

Drupal Jedi commented

Thanks Nicholas! Your module saved me hours of work.

TimG1’s picture

TimG1 commented

subscribing.

dawehner’s picture

dawehner
Primary language German
commented

I don't think that this can be fixed general out of views.

Views should use core functions which are here: theme('user_picture') and not more.

nicholas.alipaz’s picture

nicholas.alipaz commented

I personally don't deny that views should use theme('user_picture') and the submodule I coded does as such when specifying that a link to the user's profile should be used. However the option to link to something other than the user's own profile should be available, which means doing something else other than theme('user_picture') in that particular situation.

Use case:

  • Create a list of nodes created by a group of users
  • Configure the view to display each user's avatar next to the link to the node
  • Realize that you can't change the link on the avatar to match the links to the nodes and users who click the image get delivered to the user's profile
  • Get frustrated and throw hands up in the air.

I will note that I did use core functions everywhere possible:

function template_preprocess_views_userpicturerewrite_user_picture_img(&$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);
    }
  }
}

theme('image', $picture, $alt, $alt, '', FALSE); as an example.

Could this be rewritten as a patch, for sure. Will I do it? Depends on whether you guys would actually add it in assuming it were coded similarly as the submodule above. If you plan on adding it then let me know and I will rewrite as a patch against latest 3.x-dev.

wiert’s picture

wiert commented
StatusFileSize
new views_userpicturerewrite_handler_field_user_picture.inc_.tar_.gz1.33 KB

Thank you for this usefull module. Just a few additions to the handler to make Imagecache work:

function options_form(&$form, &$form_state) {
parent::options_form($form, $form_state);
$opts = array(
'user_picture_img' => 'Picture as image',
'user_picture_link' => 'Picture linked to user',
'user_picture_path' => 'Picture path (plain text)',
);
+ if(module_exists('imagecache')) {
+ $presets = imagecache_presets();
+ foreach($presets as $item) {
+ $preset = $item['presetname'];
+ $this->presets[$item['presetid']] = $preset;
+ $opts['user_picture_imagecache_'.$preset] = 'Imagecache '.$preset;
+ }
+ }
$form['overwrite_anonymous'] = array(
'#title' => t('Overwrite the value to display for anonymous users'),
'#type' => 'checkbox',
'#default_value' => !empty($this->options['overwrite_anonymous']),
'#description' => t('If selected, you will see a field to enter the text to use for anonymous users.'),
);
$form['anonymous_text'] = array(
'#title' => t('Text to display for anonymous users'),
'#type' => 'textfield',
'#default_value' => $this->options['anonymous_text'],
'#process' => array('views_process_dependency'),
'#dependency' => array(
'edit-options-overwrite-anonymous' => array(1),
),
);
$form['user_picture_format'] = array(
'#title' => t('Format'),
'#description' => t('This will override any other link you have set.'),
'#type' => 'select',
'#options' => $opts,
'#default_value' => $this->options['user_picture_format'],
);
unset($form['empty']);
unset($form['empty_zero']);
}

function render($values) {
if (!empty($this->options['user_picture_format']) || !empty($this->options['overwrite_anonymous'])) {
// Fake an account object.
$account = new stdClass();
$account->uid = $values->{$this->aliases['uid']};
$account->name = $values->{$this->aliases['name']};
$account->picture = (empty($values->{$this->field_alias})) ? url(variable_get('user_picture_default', '')) : $values->{$this->field_alias};
$anonymous = (!empty($options['overwrite_anonymous']) && !$account->uid) ? check_plain($this->options['anonymous_text']) : FALSE;
if ($anonymous !== FALSE) return $anonymous;
switch ($this->options['user_picture_format']):
case 'user_picture_img':
return theme('views_userpicturerewrite_user_picture_img', $account);
case 'user_picture_link':
return theme('user_picture', $account);
case 'user_picture_path':
return $val = (!empty($values->{$this->field_alias})) ? url($values->{$this->field_alias}) : url(variable_get('user_picture_default', ''));
+ default:
+ $preset = substr($this->options['user_picture_format'],24);
+ return theme('imagecache',$preset, $account->picture);
endswitch;
}
// Otherwise, there's no special handling, so return the data directly.
return $values->{$this->field_alias};
}

Macronomicus’s picture

Macronomicus commented

EDIT:

well I spoke too soon lol, the output is all messed for me at least.

When excluding that field and using a custom field markup like such.
<img width="120" height="140" title="[name]" alt="[name]" src="http://mesite.com/[picture]" >

I get the following output on my page :(

<div class="markup">
 <img width="120" height="140" title="&lt;a href=" karl-someone="" users="" class="">Karl someone" alt="<a title="View user profile." href="/users/karl-someone">Karl someone</a>" src="http://mesite.com/sites/mesite.com/files/pictures/picture-11956465550.jpg"&gt; 
  </div>
dawehner’s picture

dawehner
Primary language German
commented

If you really want to have another way to output it use real theming or alternative write a field handler which does everything you need.

verta’s picture

verta commented

Subscribing, need to have this function, surprising it's not in Views already.

artbussy’s picture

artbussy commented

Enabling this module gives me a warning:
# warning: file_exists() [function.file-exists]: open_basedir restriction in effect. File(/sites/default/files/avatar.png) is not within the allowed path(s): (/home/httpd/vhosts/example.com/tmp:/home/httpd/vhosts/example.com/httpdocs) in /home/httpd/vhosts/example.com/httpdocs/sites/all/modules/views_userpicturerewrite/views_userpicturerewrite/views_userpicturerewrite.module on line 28.

Fiddling around with the filesystem didn't bring me any solution. Any help would be greatly appreciated.

coolhandlukek2’s picture

coolhandlukek2 commented

Subscribe - wiert's patch worked for me when using image_cache. Thanks for contributing

cnalbert’s picture

cnalbert commented

I have the same problem! The output as link option won't work for User: picture

esmerel’s picture

esmerel commented
Category: feature » task

If someone wants to finish/clean up that patch, we can potentially consider it.

nicholas.alipaz’s picture

nicholas.alipaz commented

esmerel, there was never a patch within this thread. Only a submodule I threw together. I could rewrite it as a patch I guess. Perhaps I will look into it.

verta’s picture

verta commented

There is a patch over in #750172: User picture always links to user profile but I have no idea if it's compatible. These issues look as though they might be duplicate, however.

verta’s picture

verta commented

http://drupal.org/files/issues/views.user_picture.patch

bcobin’s picture

bcobin commented

The module works in removing the picture link to the user profile (thank you!), but outputting the field as a link doesn't work as expected.

For example, rewriting the picture link to be http://[site]/blog/[uid] actually outputs http://[site]/blog/[name]. In my case, I'm using Content Profile to create profiles of bloggers and I'm trying to create a block with their name and picture, which would then link to the specific blog.

I'm able to use the rewritten output of the user ID to generate the link from the name, and having no link on the picture avoids the automatic link to the user profile, which is a big improvement. However, it would be nice if users could click on the picture, too. Perhaps this is beyond the scope of the module, but if the picture can link to the name token (which isn't a sensible link), it should be able to link to a URL that uses the [uid] token too.

Hope this makes sense - again, thanks for solving at least part of the problem!

michelle’s picture

michelle
she/her
Primary language English
Location Wisconsin, USA
commented

I just ran into this as well. Seems to be a bit of a bug as far as the UI is concerned to have options there that do nothing. In my case, all I want is to rewrite the alt text to show other fields in the view and I couldn't figure out why it wasn't working until I searched the queue and found this.

BTW, I'm using Views 2, not Views 3 as the version of this issue is set to. But the problem is the same so it didn't make sense to make a new issue.

Michelle

byue’s picture

byue commented

Just tried the patch, and it wipes out the UID for the views too if i select no link, but the name field is ok.

johnnydarkko’s picture

johnnydarkko commented
StatusFileSize
new Screen Shot 2012-08-01 at 10.30.41 AM.png29.42 KB

For those just having trouble getting rid of the user picture field's pesky link to the user profile in views: I was able to remove the link by stripping out the HTML tags in the image field settings of the view and just preserving the <img> tag so all that remains is the image. (see attached)

HTH!

elango cod’s picture

elango cod commented

Thanks Nicholas Alipaz, i registred just to say thanks to you, i spent 8 hours searching (google and php code), am a Java developer by day.

took this module and is working as expected

couturier’s picture

couturier commented

Do we want to try to get #32 instructions into documentation? Oh, just noticed this is for Drupal 6. Most people are working in D7 or D8 now. I'll close and let anyone searching for instructions for D6 find it. Hopefully everyone is upgrading to D7 by now.

couturier’s picture

couturier commented
Status: Active » Closed (fixed)
kappaluppa’s picture

kappaluppa commented

I am on Drupal 7 and having this problem still with views 7.x-3.7

Edit: found a solution here https://drupal.org/node/750172#comment-6456000