Opened 15 years ago
Closed 15 years ago
#1417 closed enhancement (no action required)
classify activity links more specifically
Reported by: | johnjamesjacoby | Owned by: | |
---|---|---|---|
Milestone: | 1.2 | Priority: | major |
Severity: | Version: | ||
Component: | Keywords: | ||
Cc: | johnjamesjacoby |
Description
Since the activity stream is hard-coded into the database, having classes for users, groups, and other related links in the feed are essential for customization of the stream item.
Actually more information in the stream is better than less, so perhaps having multiple classes per link would be helpful, such as if the user is a group moderator or admin they get a class that says so; If the user is responding to their own feed item, having a class as them being the original author would be helpful.
I'll have a chance to patch this in a few days if you don't get to it. Just wanted to make a note of it so I don't forget.
Change History (5)
#3
@
15 years ago
Actually, now I've spent two minutes thinking about it - you already have the user_id for the current item, and you have the user_id of the comment author. Adding a template tag that compares the two would be simple. You could use that template tag in the template to add a class to the original post author's comments.
#4
@
15 years ago
Well never mind all this chit-chat. As long as the containing element is classed then the rest should probably fall in line.
If something absolutely needed to filter it, it could use the "bp_get_activity_content" filter and do some text replacement.
:X <--- me closing my mouth and coding for a while
In the trunk, each stream item now has the "action" on the list item. So blog comments have "new_blog_comment", posts have "new_blog_post" etc etc. That will help styling items specific to the content they contain.
I don't like the idea of multiple classes per link, I think it's overkill and won't actually be all that helpful (generally people won't want to style just the links?). It would really need to be on the containing element.
Adding it to the containing element will probably be too expensive though since you will need to query for every item. That adds up fast and it's really feasible.
There must be another way around this.