DokuWiki

It's better when it's simple

User Tools

Site Tools


plugin:avatar

Avatar plugin

Compatible with DokuWiki

  • 2013-12-08 "Binky" unknown
  • 2013-05-10 "Weatherwax" yes
  • 2012-10-13 "Adora Belle" yes
  • 2012-01-25 "Angua" yes

plugin Insert a gravatar into a wiki page, also needed by the discussion plugin. (previous authors: Esther Brunner, Gina Häußge, Michael Klier)

Last updated on
2013-10-24
Provides
Syntax, Helper
Repository
Source

Tagged with avatar, discussion, embed, images, media

Displays avatar images from Gravatar when a valid email address is available (falling back to monsterid if no avatar is available) or local avatar images when available. When no valid mail address is provided a local monsterid implementation or if no images can be created a fixed fallback image is used.

Syntax

{{avatar>[user|mail]?[size]|[title]}}
{{gravatar>[user|mail]?[size]|[title]}}
[user] the registered user for which you want to display an avatar required
[mail] the e-mail address for which you want to display an avatar image required
[size] either s(mall) = 20×20 pixel, m(edium) = 40×40 pixel, l(arge) = 80×80 pixel, xl (extra large) = 120×120 pixel optional; default is medium
[title] the name of the person the mail address belongs to or some other title text optional; default is the obfuscated e-mail address

By padding the e-mail address with spaces you can define the alignment like with images.

The {{gravatar>...}} syntax is still supported, but not recommended.

Local Avatars

If you don't want to use the monsterid script or the gravatars from http://gravatar.com, you can upload your own avatars into the user namespace. For a user named foo this would be an image user:foo.jpg for example and the syntax:

{{gravatar>foo}}

The username has to be lowercase and follow the pagename naming rules. If unsure, you get your username for example the recent changes log etc.. Supported image types are jpg/png/gif.

Demo

There is currently no demo available.

Changes

Discussion

A bit more control

Personally, I would prefer a slightly higher degree of control over the fallback avatars, in two main areas. I'm not knocking what is a great plugin, but I believe that it can be more things to more people by making a few modifications:-

Namespace:User -> Tokenized Filename

Instead of avatars coming from a fixed namespace, I would like to be able to specify a tokenized filename for the avatar. For example, I have my DW set up so that each user has a “user namespace” in which they have full permissions, and I would like that avatar to come from that namespace.

This is a lot easier to manage since there is no a-priori avatar, and thus ACL permission cannot be granted to upload the file - I want users to be able to change their own avatars without other users being able to; since you can't grant delete permission to a namespace, there is no way to stop users overwriting each others' avatars unless they are in separate protected namespaces.

This can be achieved by changing the namespace conf setting so that it looks something like user/@USER@/avatar (perhaps even renaming so that it is called filename, since that is a more meaningful description of the setting under this proposal). This is then resolved in _getAvatarURL into the right form, e.g. user/my_user_name/avatar, and then the files user/my_user_name/avatar.jpg etc are searched for.

i.e. changing the line $avatar = $this→getConf('namespace').':'.$user; to read

$avatar = str_replace( '@USER@', $user, $this->getConf('filename') );

Of course, the status quo can be achieved through this new system also, by setting the namespace/filename conf setting to user/@USER@.

Control over fallback order

Right now it seems that the order is Look for the avatar fileGenerate the monster ID (via gravatar)Use the default images (via gravatar)Get the gravatar. I don't want gravatar to see the image requests, but I'm sure that some people don't mind/care - to each his own. So, two things: don't talk to gravatar if you don't need to, and I'd like to be able to swap the fallback order in the config menu.

Here is how I would do it in skeleton code:-

$fallbacks   = explode( ',', $this->getConf( 'fallback' ) );
$fallbacks[] = 'default';  // Make sure that there is a successful case
 
$src = false;
foreach ( $fallbacks as $fb )
{
    switch ( trim($fb) )
    {
        case 'localimage':
            // check first if a local image for the given user exists
            break;
 
        case 'monsterid':
            // build the URL for the local monster id
            break;
 
        case 'gravatar':
            // build the URL for the gravatar
            break;
 
        case 'default':
        default:
            // fall back to the fixed image sizes
    }
 
    if ( $src !== false )
        break;
}

Hence, I can get what I achieve by setting $conf['fallback'] = 'localimage', and the current way by setting it to localimage,gravatar.

Andy Turner 2009-07-14 15:10

Sorry, I saw this just yet (bugs and feature request go to github please). — Michael Klier 2009/08/22 13:43

Using Gravatar's MonsterID...

This is great plug-in but I have poor server (p4 2.8 MHz, 768Mb ram) and I am experiencing full CPU usage whenever this plug-in make the monster pictures. How about use GRAVATAR's MonsterID to reduce local server's burden??? — SC Yoo 2010/09/19

Please add support Pavatar.com

plugin/avatar.txt · Last modified: 2013/10/24 13:02 by Michitux