ImageCache integration
| Project: | Facebook-style Statuses (Microblog) |
| Version: | 6.x-2.x-dev |
| Component: | Miscellaneous |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Facebook Status fits well together with activity (particularly activity 2.0). Facebook Status alone emulates twitter functionality right out of the box (with a load of features). Combined with activity 2.0, you can virtually emulate facebook's aggregated status feed that contains everything from blog posts to status updates. I would consider user picture support fundamentally important to both workflows being that they're most commonly used within social networks. As shown in token-fashion below, the expected result for a facebookesque "WALL" feed (even twitter feed) always begins with the user picture:
[Facebook Status BOX]
[user-picture] [user-name] [node-title OR facebook_status]
if -then [field-image] if -then [field-body-teaser]
if -then [links]
etc.
Activity 2.0, fb_status and views allow for virtually all of this to work. Except for uniform user picture support. The challenge supporting user pictures for social network sites is that they often require different display sizes. That's where, with Drupal, imagecache comes into play. Imagecache Profile, with this patch (http://drupal.org/node/349331), provides imagecache support for user pictures from within views 2.0 but here's where the problem comes into play:
Ice was gracious enough to provide support for user pictures (here: http://drupal.org/node/482364) but I discovered shortly after testing it, along with activity and views, an obstacle. Facebook Status doesn't use Drupal objects "user" and "account" but instead "owner" and "poster". These objects don't have access to two very important possibilities. One is the imagecache support as mentioned above. The other is that the picture of "poster" might be redundant in a view that already provides the "user" picture as a field. Since a "poster's" picture is different form the picture of the user who's profile a status has been posted on it will likely appear as a duplicate in an aggregated view-feed as the one shown above.
So my suggestion to remedy this is one or the other: either switch "owner" and "poster over to Drupal standard objects like "user" and "account", or try and provide an imagecache handler for "poster" and "owner" pictures in views with imagecache profile. Since I'm not a module programmer I really don't know how much work the former would take or whether Drupal objects like "user" and "account" can even work to provide the type of functionality that IceCreamYou has brought us with this module using "poster" and "owner". Namely, the ability to have status updates by different users be distinguished based upon whether they were submitted on a user's own profile page or another user's profile page. But I would suggest that the former is the most ideal solution.
#1
Spare yourself the essay, which demonstrates exemplary enthusiasm but a thorough lack of understanding of what's actually going on under the hood. ;) All you needed to ask for was ImageCache support. And yes, I'll get to that when I have time, but it will take awhile because I have extremely little free time these days, I'm away from my home PC at the moment, and I need to play around with ImageCache to see what's going on.
As far as the actual tokens, there's very little ambiguity (at least in Activity 2). You can set different tokens for the recipient of a message from another user (the owner), the poster of a message to another user, and/or a user who posts a status on their own profile. For the last case ("self" in the Activity publishing template settings) the "owner" and "poster" tokens are the same, so either can be used.
#2
That's great Ice. And I've said this elsewhere, I'm just learning the module programming. I also haven't had the time to look at your code much since I'm busy myself so I'm just making some rather premature observations. I'll definitely leave it up to you to make the best judgment as to what to do. I am definitely a little too excited about this module. It's working out so well so far with users.
Cheers.
#3
subscribing
#4
also subscribing
#5
Hey Ice,
Considering I already threw this out there in this request, perhaps it should go under yet another feature request thread, I thought I'd ask:
I'm just wondering what would be the better way of supplying user/poster pictures of fb_statuses for activity 2.0 publisher templates/views. There are two ways of doing this that I can think of. One is to simply support a [poster-picture] token that can be used with views, the other is to supply the poster-picture (and other facebook status elements) in views for activity 2. I suppose we need the activity module maintainers to implement the latter support.
I'm not sure the latter method would work well though. Say you have a view of just nodes and statuses. If you setup a view to show user-picture and poster-picture for both nodes and statuses you'll end up with a redundancy. The best method would be to have a token of [user-picture] for node publisher template (activity maintainers' responsibility of course) and a [poster-token] for the status publisher template. Perhaps I'll request a [user-picture] token for other publisher templates.
Again, I'm simply trying to find a way to replicate what Facebook does by attaching the user picture (of the author) to the beginning of the display to any activity type, be it status or (node-type) post.
What do you think?
#6
Well, the maintainer of the activity module turned down support for user tokens in the activity publisher template and for good reason: http://drupal.org/node/528928.
#7
As you've discovered, there is no satisfactory way to implement ImageCache integration in Activity views at this time - at least, not without a substantial amount of non-degradable JavaScript (an approach I'm not interested in taking). In the future, Activity may develop to a point where it processes tokens during rendering instead of saving, at which point a user picture token will be practical.
The only integration with ImageCache I can add right now is for a column in facebook_status views.
#8
:) that's still excellent regardless. I'll do without such support and figure out a way around it. Keep up the excellent work Ice.
#9
I might be wrong, or I'm just not understand this issue but can't this be done with by theming views2? I've done this fairly easy with activity1... the dev release. But maybe I'm not following along here.
#10
I think the problem is that FBSS uses its own custom version of theme('user_picture') which doesn't allow ImageCache or ImageCache Profile to override it. (Thinking through it now, the solution is probably to just change the way images are handled instead of creating a whole new column in Views.) Will look into it within the next month I hope, and probably sooner rather than later.
Just to clarify: the purpose of this issue, as I understand it, is to allow ImageCache (possibly through ImageCache Profile) to control the size of images displayed in the FBSS View fields that display user pictures.
I'm not sure that answered the question at hand, but honestly I know nothing about Views theming so I'm not really qualified to answer that question anyway. I suspect that it would be possible to do this through Views theming.
#11
yes, it is theoretically possible to achieve imagecache resizing of images with views theming (like you can easily within a node.tpl or page.tpl) however no one has yet to figure it out and post it on Drupal.org - trust me, I've checked and posted on almost every thread pertaining to this. If someone is willing to take a stab at it I've come up with various possible snippets that should work but aren't because of one missing variable or another.
#12
Oh... Well it's really simple... I'm doing it now... I've pulled an all nighter so I'll either post an example tonight or sometime tomorrow... But if you have the devel module installed it makes theming views a snap. Anyways I needed something along the same lines as you so I'll give you a quick run down when I finish
#13
oh my god - I will worship you. I've been using devel to acquire the path to user picture but I've found none that work within a .tpl. I've tried:
<?php$default_picture = variable_get('user_picture_default', '');
if ($row->{$field->field_alias}) {
print theme('imagecache', 'user_thumbnail', $row->{$field->field_alias});
}
?>
to resize just regular user pictures. or
<?php$image = $fields['facebook_status_pid']->content;
print l(theme('imagecache', 'user_thumbnail', $image, $alt, $title, $attributes)); ?>
or simply ...
<?php print l(theme('imagecache', 'user_thumbnail', $facebook_status_pid, $alt, $title, $attributes)); ?>and different variations in different types of view.tpls to call the facebook status poster picture to resize but to no avail.
#14
Glad it works for you. Thats actually a bit different then the way I do it. What template are you doing this in?
#15
oh sorry, my point was that none of the above actually work for me. If you could share what works for you that would be swell.
#16
Ah! Okay... I must say it's a bit of a pest to theme this module. Mainly the user with pictures field which can be used as a $row object. I did manage a work around for it.
Anyways seems like you've waited long enough for me to post something... I'm not finished but this will at least give you a base to work on for now. If you have any question feel free to ask. I ended up having to use user_load() due to the custom user picture output of FBSS.
So just import the view... it's incomplete so I assume you'll make changes to this. But it does work as is....
Next create your template files under theme information in the view. You can change this to any style you want as long as row style fields can be used with it.
The important template here is views-view-fields--notebook.tpl.php with notebook being the name on my theme... you can get more specific depending on how many pages or blocks you have but for now were just dealing with the main default view.
Here's a quick overview on how to achieve specific customizations within this field... Oh yeah also note that this is stripped down. I don't like all the tags views give me cause I basically just use it for queries...
<?php
// This goes into your views-view-fields--notebook.tpl.php
// Also I left out the top helper text.... just to let you know...
$poster = user_load(array('uid' => $row->facebook_status_pid)); // Need to call user_load because FBSS picture field is not available as a $row object.
if ($poster->picture) {
$picture = '<a href="/user/' . $row->facebook_status_pid . '">' . theme('imagecache', 'avatar_45x45', $poster->picture) . '</a>';
print $picture;
}
print $fields['status_time']->content;
print $fields['status']->content;
print $fields['pid_extra']->content;
print $fields['respond']->content;
print $fields['delete']->content;
print $fields['edit']->content;
?>
Sorry for the sloppy code. So if you add new fields or what have you, use devel theme developer... Most important data is $row and $field objects.
I hope this makes sense...
Cheers!!
#17
Opps also just to note you really don't want the edit and delete fields there.... might want to do an permission check on that... IceCreamYou can probably provide you with better advice from here...
#18
The Edit and Delete fields do their own permission checks, so they won't show up if you don't have permission to access them.
Also I'll probably change the way FBSS renders user pictures before 2.0 to use the default theme('user_picture') so it will be easy to override. My problem with it was that most themes float the pictures to the right, which looks weird in Views, but there are more valid ways to get around that. (FWIW, that's basically what this issue comes down to for me, and I'll leave it open until I make that change even if the method described here works.)
#19
Cool - thanks Walker! This works amazingly well. I've been using devel without the themer - need to start using it again. As for the issue, I agree, let's leave it open until IceCreamYou can make the changes.
#20
*sigh*
I have too much other stuff going on and too many bug fixes and smaller things I want to get into RC2. After I get out RC2 I will come back and focus on some larger features including this one.
#21
Fixed, in that the "Users with Pictures" field in Views now uses theme('user_picture') instead of a custom function. From what I can tell without actually trying it, Imagecache Profile should override that by default.
The reason I originally used a custom function was to get around some magic in Garland and other themes that made the picture display awkwardly, but I used CSS this time instead.
#22
I assume this will make theming with views a bit easier. No need to call user_load() in your view template.
Thanks IceCreamYou
#23
Amazing. Great work Ice! And thanks again for your help too Walker.
#24
Automatically closed -- issue fixed for 2 weeks with no activity.