Skip to:

Opened 12 years ago

Closed 8 years ago

Last modified 8 years ago

#4046 closed enhancement (fixed)

@mentions not working in blog posts

Reported by: will_c's profile will_c Owned by:
Milestone: Priority: normal
Severity: normal Version: 1.5.2
Component: Toolbar & Notifications Keywords:


Our site is using WP 3.2.1 and BuddyPress 1.5.2 and when we add @mentions in a blog post, they don't work. I'm not sure if this is a bug, a feature request under review, or the intended behavior, but it would be a great addition if we could @mention users in blog posts so that they get notifications.

I have tried this with our custom theme and the bp-default theme and get the same behavior in both.

Change History (8)

#1 @boonebgorges
12 years ago

  • Milestone changed from Awaiting Review to Future Release

It works this way because of a quirk in the design of @mentions. Strictly speaking, @mentions are a property of activity items. As such, they're only triggered by the content of an activity item. In the case of a blog post, the content of the activity item consists of the first few words of the blog post. So @mentions that appear in this first sentence or so of the blog post should trigger notifications.

Unfortunately, a better system would require a major rethink of the way @mentions work - we'd have to separate them from the activity component, or create a separate index of them, or start storing fulltext in the activity table, or any number of these options at the same time. I do think that this is something we should think about, but unfortunately it won't be for this dev cycle.

#2 @henrywright
11 years ago

Hi boonebgorges, following on from 5230, could this ticket be resolved with the proposed notifications component outlined in ticket 5148?

Perhaps a notifications table could be introduced with fields such as

id | notified_user_id | notifer_user_id | notification_text | status


  • notification_text could be a simple string like "Member X mentioned you in a comment"
  • status could be a boolean value to signify read or unread notifications.

I think this approach would be along the lines of your first and second suggestion above. I don't see a need to store the full text (suggestion 3). This I think would (as you will be aware) bloat the activity table unnecessarily with lots of duplicated data.

Edit: Thinking about the table, it might also need field(s) to identify the item so that a link to the comment, post, private message etc can be shown to the user who is being notified.

Last edited 11 years ago by henrywright (previous) (diff)

#3 @boonebgorges
11 years ago

It's *possible* that we might be able to do with the notifications table. The only trick then is that Activity would be dependent on Notifications, which is a sort of straightforward dependence that we try to avoid in most cases.

In any case, to store this info in Notifications, it'd look something like this:

  • When a blog post (or any other item, I guess) is stored, look for @-mentions
  • For each one, store a notification item:

'user_id' => $user_id,
'item_id' => $mentioned_user_id,
'component_name' => 'activity',
'component_action' => 'mention',
'secondary_item_id' => $activity_item_id

  • Mentions queries would then look like: SELECT * FROM {$bp->notifications->table_name} WHERE item_id = {$displayed_user_id} AND component_name = 'activity' AND component_action = 'mention'. The results would then be fed into bp_has_activities()`.
  • When the source items are updated, re-parse

We'd need a proof-of-concept to show that this scales properly. It'd surely be better than the existing LIKE query, but it would still involve a number of queries.

#4 @henrywright
11 years ago

'user_id' => $user_id,
'item_id' => $mentioned_user_id,
'component_name' => 'activity',
'component_action' => 'mention',
'secondary_item_id' => $activity_item_id

How would component_name and component_action work in the case of @-mentions in comments and posts? Would these mentions also be tied to the activity component?

#5 @boonebgorges
11 years ago

What I'm proposing is that notifications labeled with component_name = 'activity' and component_action = 'mention' serve as an index for *any* kind of mention. If you want to know more about the source of the mention (the blog comment, the blog post, the activity update, whatever), you would need to use the secondary_item_id results to fetch the original activity items. Those activity items, in turn, have enough information (in the form of component, type, item_id, secondary_item_id) to fetch the source content.

I'm really just throwing out this idea, not necessarily seriously proposing it. I'm not sure Notifications is the right place for this index to live. What really *is* needed, however, is some sort of storage mechanism for @-mentions that is more than just a text search on activity content.

#6 @henrywright
11 years ago

I see! You're right, there is hardly a need to identify the mention. A mention is a mention no matter where it comes from. That said, I can see how secondary_item_id would do the trick.

I agree, a Notifications table may well not be the best place for them. Something like this needs a brainstorming session to find the most efficient and scalable way of doing it. It could be worth looking at existing systems that make use of @-mentions. I don't suppose Twitter or Instagram publicise their methods but there could be some open source examples which give an idea of good practice?

#7 @slaFFik
8 years ago

  • Resolution set to fixed
  • Status changed from new to closed

As we already send a notification to a user ("slaFFik mentioned you" with a link to a mentions tab in profile), when he/she was mentioned in a blog post, I consider this ticket (its initial request) to be fixed.

#8 @slaFFik
8 years ago

  • Milestone Future Release deleted
Note: See TracTickets for help on using tickets.