#1721 closed enhancement (fixed)
Filter Hooks needed for plugins to custom filter activity streams
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 1.5 | Priority: | normal |
Severity: | Version: | ||
Component: | Activity | Keywords: | has-patch |
Cc: |
Description
I'm writing a plugin that creates some special meta data for activity items. I created my own custom table for storing that meta data and want to add a join and where clause, but there are no filters to hook onto in the BP_Activity_Activity::get() function.
I attached a diff that includes some filters you might consider adding, so that plugin developers can easily create their own filters on activity content. This diff enables plugins to support custom arguments sent to bp_has_activities(), using them to create custom filters on the activity streams.
You might also consider adding similar hooks to other DB get functions (for filtering groups, forums, etc.).
Attachments (1)
Change History (13)
#1
@
15 years ago
- Keywords has-patch added
- Summary changed from Filter Hooks needed for plugins to custom filter activity streams to Filter Hooks needed for plugins to custom filter activity streams [Has patch]
#3
@
15 years ago
- Resolution set to invalid
- Status changed from new to closed
You shouldn't need to do any of this. There is a table called wp_bp_activity_meta that you can use to store meta and use the functions bp_activity_get_meta(), bp_activity_get_meta(), bp_activity_delete_meta().
If you need to get all meta for all activities at once, rather than querying for every item them you can use the filter 'bp_has_activities' to loop the found activities and add the meta you need.
If we start adding filters to SQL queries then it's not possible to ever change the underlaying schema without causing major issues.
#4
@
15 years ago
The functions are bp_activity_get_meta(), bp_activity_update_meta(), bp_activity_delete_meta()
#5
@
15 years ago
- Resolution invalid deleted
- Status changed from closed to reopened
Good point, Andy, but the meta table doesn't work for the kind of data I have. Please take a look at the new patch I made - it is as trivial a change as possible. It just applies filters to the final sql, so there should be no complications.
The reason the meta table doesn't work for my situation is because my meta data is more complicated. I'm tagging activities with sets of integer ranges, so I need meta data with two integer columns (start of range, end of range). Each activity can have multiple ranges. The query I use can search for a range of integers and see if it intersects the range of integers in the meta table.
I know, the BP meta table works for most cases, and mine is an edge case, but this new patch I've attached is a very very trivial change, and it makes my life a ton easier, and maybe other plugin devs will need it too some day?
#6
follow-up:
↓ 7
@
15 years ago
- Resolution set to invalid
- Status changed from reopened to closed
Pass an array to the meta functions that will store all the values you need. It isn't limited to a single piece of data.
I'm fundamentally against filtering the SQL since plugins should be using the API layer above this. Once you add filters to SQL you are starting on a slippery slope that ends in broken queries, conflicts and trouble with compatibility.
#7
in reply to:
↑ 6
@
15 years ago
- Resolution invalid deleted
- Status changed from closed to reopened
Replying to apeatling:
Pass an array to the meta functions that will store all the values you need. It isn't limited to a single piece of data.
I'm fundamentally against filtering the SQL since plugins should be using the API layer above this. Once you add filters to SQL you are starting on a slippery slope that ends in broken queries, conflicts and trouble with compatibility.
I won't reopen this any more this milestone if you invalidate it again, but please listen to my final argument.
It is your decision, but the BP API does not support what I want to do. A smart plugin developer will use the BP API when he can, but don't tie him to the API if he is trying to do something that the API can't support. Sure, it is a slippery slope, but the plugin developers are responsible for their own code.
Let me explain what my plugin does: it indexes content by Bible references mentioned. Someone might mention the Bible verses John 3:10-20 in an activity update. My plugin detects the Bible reference and stores an integer start verse and and integer end verse. Then if someone is looking for activity about John 3:16, he would find the activity about John 3:10-20 (because John 3:16 is in John 3:10-20). A query for John 3 would also return that activity (because John 3 includes John 3:10-20). I do this by creating a table with start verses and end verses and write queries for finding range intersections.
Here would be a WHERE statement that finds all activities which mention verses in John 3:
(seqs.start BETWEEN 2818816 AND 2819071) OR
(seqs.end BETWEEN 2818816 AND 2819071) OR
(2818816 BETWEEN seqs.start AND seqs.end) OR
(2819071 BETWEEN seqs.start AND seqs.end)
2818816 is the starting verse in John 3 and 2819071 is the ending verse, so this query is just searching the activity tables for intersecting integer ranges.
Can the BP API handle this kind of data?
#8
follow-up:
↓ 9
@
15 years ago
- Milestone changed from 1.2 to 1.3
Thanks for taking the time to explain this. I agree this is a fairly complex use and the API doesn't really give you what you need right now.
However, I don't think throwing in filters to provide a quick fix is the best way to resolve this, or in the best interests of the project. I'm going to punt this to 1.3 with the intention of solving this properly by improving the API.
#10
@
15 years ago
- Component set to Activity
- Milestone changed from 1.3 to Future Release
- Owner set to mrmaz
- Priority changed from major to normal
- Status changed from reopened to assigned
- Summary changed from Filter Hooks needed for plugins to custom filter activity streams [Has patch] to Filter Hooks needed for plugins to custom filter activity streams
- Type changed from defect to enhancement
The API is going to get some love in or after 1.4. This issue is fairly complex, so no guarantees that it will get attention right away, but I agree that there should be an effort to make retrieving activities as flexible as possible. That would not include filtering SQL though.
I am punting this to a future release. Feel free to add this to the 1.4 milestone once it has been created.
#11
@
14 years ago
- Milestone changed from Future Release to 1.3
- Resolution set to fixed
- Status changed from assigned to closed
Filters for this were added in r3617
I attached a patch that has the filters to make the BP_Activity_Activity::get() function more robust. This is important because it opens the door for many plugins to be written to customize the activity stream, which is now a huge focus of BP.