add css class such that a theme can put nice online/offline indicators when showing a username link.
i made sure the relevant queries in node, user, and tracker modules were passing the $user->access parameter which triggers the addition of this css class.
no added quries or JOINS needed.much of this patch is just moving the 'inactivity timer' pref from the Who's Online block config page to the main admin/settings/user page.
would be nice if someone contributed small graphics for online offline and added these to drupal.css. this would enhance our default presentation. i'd like for this patch not to wait on that, if possible.
Comments
Comment #1
Bèr Kessels commentedI really like thi. +1. I managed to grey out my avatars of offline users (looks very good!) with this patch.
One thing is the whos online block. IMO that should follow these same rules.
Comment #2
moshe weitzman commentedthis feature already works for the who's new and who's online blocks.
here is a slightly improved version which adds offline indicator even for admin created users who have not yet logged in.
Comment #3
ŐRY Máté commentedI patched a clean cvs install, but there are no classes in the tags of names of the owners of the nodes. I didn't can fix it and I have to go away.
I drew the icons for the default theme: http://maat.myip.hu/~maat/maat_drupal/drupal/misc/online.png & http://maat.myip.hu/~maat/maat_drupal/drupal/misc/offline.png
Comment #4
Bèr Kessels commentedExcuse my ignorance. This pach already changed the whos online block. My testsite had a too complex theme function, it was causing the whosonline block to check fro the old variable still. My error.
But my +1 still stands, though.
Comment #5
moshe weitzman commentedthanks for the icons ... this feature already works for the who's new and who's online blocks. perhaps someone (steven?) can add some css to include these images. otherwise, lets just get this improved markup committed.
Comment #6
Uwe Hermann commentedMoshe, I think there's a left-over in your patch from another patch(?) Look at the bluemarine stuff at the bottom.
Comment #7
Uwe Hermann commentedOh, and +1 for the idea (didn't try the patch, yet).
Comment #8
moshe weitzman commentedindeed, uwe was correct. here is a clean patch.
Comment #9
dries commentedSometimes
variable_get('user_seconds_online', 2700)is used, sometimesvariable_get('user_seconds_online', 900);is used. That can't be right, can it?Comment #10
moshe weitzman commented2700 => 900
Comment #11
moshe weitzman commented2700 => 900
Comment #12
Thomas Ilsche commented+1
successfully tried the patch (in a small setup)
Comment #13
drummYou can use variable_set() and variable_del() in updates.inc. I think that would be best since you have to worry less about the cache.
The 'username' class won't be set on users who have not accessed the site.
I know this is a themeable function, but I'm thinking this might want to be configurable.
Comment #14
drummComment #15
ŐRY Máté commentedThe patch works me well, but there were some bugs and/or missing features.
1) the comment module's sql querys were not enough to get user-status
2) the "username t(offline/online)" css classes weren't useful (unicode classname because of the t() function; two class...) (my version is "username-online/offline")
3) there wasn't css style for usernames
4) the icons are available on http://maat.myip.hu/~maat/drupal/online
Comment #16
ŐRY Máté commentedThere were 4 +1-s and my, also 5 ones. The patch works without errors.
I drew iecompatible icons and white backgrounds for the bluemarine compatibility. http://maat.myip.hu/~maat/drupal/online
Comment #17
Dublin Drupaller commented+1 from me..great idea
Dub
Comment #18
dries commentedPatch no longer applies.
What does it 'mean' to be online or offline on a Drupal site? I think icons are handy, but not for online/offline purposes -- Drupal sites aren't usually real-time communities like IRC or IM are. What is the value of knowing someone is online?
Icons to denote whether someone is an administrator or not, paying member (gold icon) or not, male or female, contributor or user, etc. sounds a lot more useful to me. The fact this patch paves the way to more useful things is what makes me support it.
Take a look at http://www.gfxartist.com/ to see how icons can be used in a really useful manner.
Comment #19
Kobus commentedThis is very handy when using a Drupal site for a dating service, or other service where privatemsg.module is installed. It can also be used to know if a site administrator is online, in the event of a user experiencing trouble.
But, your point is taken, and why not implement BOTH approaches? For online/offline, and to distinguish user roles?
Regards,
Kobus
Comment #20
Stefan Nagtegaal commentedThe more popular forums (did I hear something lately about improving and extending our own forum???) also displays your current status.. Think about phpBB..
I do think it's a nice addition to drupal.. :-)
Comment #21
Stefan Nagtegaal commentedIf more people would like to see this hot the trunk, I can update the patch..
Please let me know..
Comment #22
Bèr Kessels commentedDries' comment ade me change my mind. I think he is very right.
y idea is that we should simpley pass more information to theme functions and let teh themes sort out iconifying stuff. Such specific display options must not be rendered in core, nor oin other modules, but in themes. That is what they are for, provided they have acces to enough information.
Comment #23
dries commentedIn future, I'd like to do something like this:
Of course, offline/online could be used too. This is merely an example of other stuff one might want to do. Better start creating more icons. ;)
Stefan: please update this patch to work with HEAD. Thanks.
Comment #24
moshe weitzman commentedFor better semantics, I suggest avoiding the image string. Extend the technique proposed in this patch. In this example, it would be:
and then this css
i can't preview this follow-up, so it might be ugly. also, it might show up better on web than in email.
Comment #25
Bèr Kessels commentedwow. That is very unflexible.
Why not go fora flexinode alike approach? There you can theme any field.
And really, icons do not belong in core, unless maybe the ones in admin. Especially such specific icons. Such icons should live in themes.
Comment #26
adrian commentedOk. i'm just going to put this out there.
I think the current solution is quite inflexible, but the basic functionality is essentially what _phptemplate_variables does (pass more variables to the theme function / template). One of the (lesser) reasons I would like to have core move towards using associative arrays for theme() function parameters (apart from having all hooks automatically be overridable using .tpl.php files, without writing stub code in template.php), is that we could have a hook_variables, that exposes extra variables to the theme function, that it can do whatever with.
Anyway. Way off topic. Feel free to ignore me.
*goes to bed*
Comment #27
Kobus commentedI am with Ber on the fact that such icons should belong in themes. Providing the functionality to allow theming of this functionality is very important though.
Regards,
Kobus
Comment #28
moshe weitzman commentedwhat does it mean that 'icons should be supplied by themes'? the patch provides default images that are specified in drupal.css. a theme can override the images easily with its own css or by implementing theme('username'). this is the same pattern found with the throbber, the tablesort icons, the watchdog icons, the forum icons, etc.
are you saying that the css should be implemented in bluemarine's style.css and pushbutton and chameleon. should the icons be packaged with those themes (i.e duplication). should drupal not ship with default icons for this, unlike the examples i cite above?
let's be specific in these patch reviews - what code belongs where?
Comment #29
Kobus commentedMoshe, you do have a point (and some good arguments) here. Hmmm... In light of this, I think, since it is overridable, include it in Core...
Kobus
Comment #30
Bèr Kessels commentedWhat I suggest, is that:
* Let this patch proceed as it is now. *without* default icons in drupal.CSS. But *with* proper classes and IDs in user lists; Then we add this to a site or a theme, to show how these classes can be used to get icons. As well as a page in the handbook.
* If Dries's future idea gets momentum, we should consider adding better themable function for
** Any profile field.
** icons in general.
So, to be even more specific and to bring focus back on offline inline: I believe that there should be no such *specific* CSS in drupal.css. A lot of themers have been trying to get rid of the clutter in that file. With some success. Esp. these kind of very specific styles are amost annoying when themeing. If I dont want icons, I need to add at least ten lines of CSS to my themes to 'disable' them. Often even more, if I need to achieve another effect.
I very much believe that drupal core (drupal with no themes enabled) should be as minimalistic as is possible, without becoming unusable.
So, what about this: add classes to the tagsoup. Add some CSS rules to one of the core themes (or more), so that it shows icons, and thus shows to other themers what is possible.
Comment #31
semdao commented(spam removed)
Comment #32
moshe weitzman commentedoh no, someone spammed this issue and we can't delete follow-ups. yuck.
Comment #33
Bèr Kessels commentedyea. should we rather open a new thread and close this one? It will cause some loss of valuable followups though :/
Comment #34
Jaza commentedMoving to 6.x-dev queue.
I like the idea of having the boolean flag for the user's online/offline status being available in theme('username'), but I don't think that the online/offline status should actually be outputted by the default theme('username') function. Better to just let themers display this info how they want, if they want.
Comment #35
catchbumping.
Comment #36
moshe weitzman commentedComment #37
sunPlease note that User Display API has been developed for these kind of decorators, requires minimum changes to core APIs, and allows site builders to display arbitrary information when user accounts are output. I could have posted a patch for D7 if we had an UI in shape already. Everyone interested in this is welcome to join these efforts.
Comment #38
effulgentsia commentedBumping. Should be straightforward to do this in contrib with hook_preprocess_username(), and if http://drupal.org/project/user_display matures nicely in D7, perhaps some/all of it could move to D8 core.
Comment #39
jhedstromComment #40
catchThere's no way to reliably query whether a particular uid has a session with different session storage backends. So this is something for contrib. Going to go ahead and mark won't fix for core.