CUNY Academic Commons

Boone - About the proposed default activity filtering, we basically want to combine numerous activity scopes together (my group activity + my friend activity + my site activity). The problem is BP Activity Core doesn't support numerous scopes. These thoughts should probably go in this BuddyPress ticket, but I'm trying to think of the best way possible to introduce such a concept without causing a lot of overhead.

Hi Ray - Yes, it's not clear how to do this with the existing tools.

How feasible is it to use this as an opportunity to build a functional prototype of a fix for https://buddypress.trac.wordpress.org/ticket/4988?

For comparison - last week I was working on the DiRT repository project when I realized that I needed something like https://buddypress.trac.wordpress.org/ticket/5839. I built it in a couple of hours. It's modular enough that it can be included in a plugin for the time being. What'll be required here is a bit more complex (and we have nothing as close as WP_Meta_Query to copy from) but I wonder if we can attempt something similar.

I'm thinking that, technically, we can do something very similar to these other _Query classes, but replacing BP_Activity_Activity::get_filter_sql(). Roughly:

- bp_has_activities() etc would accept some sort of filter_query argument
- we have a separate class that transforms these queries into SQL fragments
- For input, use a similar syntax ('relation' param can be 'AND' or 'OR; individual arrays will describe filters )
- Translation would look roughly like:

relation => 'OR',

// Friends' activity
array(
    'user_id' => array( 1, 3 ), // array of user's friends
),

// Blogs following
array(
    'item_id' => array( 4, 5, 10 ), // array of blogs following
    'component' => array( 'blogs' ),
    'relation' => 'AND',
),

// Groups
array(
    'item_id' => array( 7, 8 ), // IDs of user groups
    'component' => array( 'groups' ),
    'relation' => 'AND',
),

transforms to

SELECT distinct a.ID FROM wp_bp_activity 
WHERE (
    ( user_id IN ( 1, 3 ) )
    OR
    ( component IN ( 'blogs' ) AND item_id IN ( 4, 5 ,10 ) )
    OR
    ( component IN ( 'groups' ) AND item_id IN ( 7, 8 ) )
) // etc

- Then we hook into the existing activity query and splice either (a) our SQL chunks (if possible, better to keep a single query), or (b) the results of a separate query, in the form of a big "a.id IN (...)" clause.

Clearly, this is all possible, and I'm sure we could duct-tape together something that'd suit our purposes. But I would really like to take a little extra time now, if possible, to build something that could serve as a prototype for BP. Do you think this is crazy talk, or do you think it's something we can put our heads together about over the next few weeks? And if so, do you think there's something in the discussion above that I've missed, or gotten wrong, in terms of architectural requirements?

Thanks for entertaining my madcap schemes :)

This isn't crazy at all! I'd like to transform our scope parameter into these SQL clauses to keep with what we have, but it looks like I have enough to go on.

The only thing I'll need to do is some benchmarking as to what is the most efficient method. I'll get started on something and see where it goes.

I'd like to transform our scope parameter into these SQL clauses to keep with what we have

Yes, though you should start with building the system you want, and then port the old stuff over when you're done.

The only thing I'll need to do is some benchmarking as to what is the most efficient method

Cool. I actually don't think this is going to be very problematic from a performance point of view. The built SQL query will be fast - all the activity table columns are properly indexed, and we don't need any weird JOINs. The only real overhead would be higher up the chain: querying to get the IDs of all a member's groups, friends, etc. For an initial iteration, I'd say don't worry about the performance of these separate queries, and just use whatever's already in BP. We can worry later about, eg, ensuring that these queries are cached.

Thanks for having an initial look! Let me know as you do your exploration. The braindump above is not meant to dump the task onto your shoulders, and I'll be glad to take on some (or all) of this particular task, as you see fit.

Boone - I've got a first pass of multiple scopes up on BP#4988.

Whenever you have a chance, let me know what you think.

Can you make sure that users logging in from the front page are redirected to my-commons?

This should be fixed in commit 3098d48.

There was a bug in the admin bar login form that needed to be addressed as well. Previously, the login redirect was always redirecting to the homepage and not the current page you were on. This is now fixed.

The last remaining thing for the 'my-commons' page is to support multiple scopes (groups, sites, friends) for the "Everything" activity filter. This will replace the "Sitewide" activity filter that is currently on the page.

Boone and I were speccing out what this will take for BuddyPress and we're pretty close. I'll work on this a bit more later this week.

Excellent, thanks, Ray.

Boone and I were speccing out what this will take for BuddyPress and we're pretty close

Ray, let's not let our disagreements about syntax for BP get in the way of implementing this feature here on the Commons. I'm happy to continue the conversation on the BP ticket, but if it seems like it's going to take a while to come to a consensus there, then we should just go with your currently working version for CAC 1.7. We can always swap it out later, whenever it ships with BP. Thanks!

A first pass of the "Everything" activity filter is up on cdev.

Some thoughts after some quick testing on cdev:

- The "Everything" filter runs almost three times as slow as a regular group, friends or followed sites activity filter. (3.5 secs vs. 1.2 secs).
- The "BP External Activity" plugin runs an AJAX query ("refetch_external_activity" action) every time an activity filter tab is clicked. We should probably limit this.
- bp-nelo doesn't support the heartbeat feature in BuddyPress. Do we want to add support for this in 1.7.1?

I have also removed all activity tabs except the "Sitewide" tab on the "News" page.

There are a few tabs that are not on the "My Commons" page, but were on the "News" page: @mentions and Favorites. Do we want to add one or both tabs on the "My Commons" page? Or leave this functionality to the "My Activity" admin bar links?

This is looking great - thanks, Ray!

- The "Everything" filter runs almost three times as slow as a regular group, friends or followed sites activity filter. (3.5 secs vs. 1.2 secs).

It's the COUNT query. Visit http://cdev.gc.cuny.edu/my-commons/?bbg=1 to see. In BP 2.1 this query is disabled by default, right? So I think this will probably resolve itself.

- The "BP External Activity" plugin runs an AJAX query ("refetch_external_activity" action) every time an activity filter tab is clicked. We should probably limit this.

Totally. Please have at it. Maybe limit to `bp_is_group()`. Try to do it outside the plugin, but if you can't, just change it in the plugin - I think we run a fork.

- bp-nelo doesn't support the heartbeat feature in BuddyPress. Do we want to add support for this in 1.7.1?

If it's easy, yes. I don't think it's worth doing a lot of refactoring for a theme that probably only has 6-9 months left in it.

There are a few tabs that are not on the "My Commons" page, but were on the "News" page: @mentions and Favorites. Do we want to add one or both tabs on the "My Commons" page? Or leave this functionality to the "My Activity" admin bar links?

Let's not add them to My Commons for 1.7 - our goal was to be simple, simple, simple. Let's leave them on My Activity, and think about exposing them more on My Commons once our mentions + favorites systems do more. (BP 2.1 will help for the former, BP 2.2+ for the latter.)

Thanks for your work on this! Looking really close.

It's the COUNT query.

Ah, right! This also reminds me to remove the pagination links from bp-nelo's activity loop template.

Try to do it outside the plugin, but if you can't, just change it in the plugin - I think we run a fork.

Gotcha.

If it's easy [to add support for heartbeat to bp-nelo], yes.

Will take a stab at it. Have to make some changes to bp-nelo's copied version of bp-default's JS.

FYI, when working on getting the groupblog filter with the followed sites activity scope, I came to the realization that your syntax for activity multiple scopes will be way better than my simplified syntax! :)

Try to do it outside the plugin, but if you can't, just change it in the plugin - I think we run a fork.

For the BP External Activity plugin, I decided to remove the fetch routine whenever an activity loop is generated. See commit a057fe7.

The reason why I did this is we already have an hourly cronjob that does the fetching. Also the BP External Activity plugin only fetches Mediawiki edits, not group RSS activity. If we need more frequent updates, we should decrease the cronjob duration from one hour to a lesser value.

Boone, we can revert this if you want. Could use your feedback here.

If it's easy [to add support for heartbeat to bp-nelo], yes.

bp-nelo now supports heartbeat (see commit 6b28df2). Because the bp_activity_do_heartbeat() function currently lacks a filter, I needed to bypass this with some hacks, but this should now work.

For those testing, this means that if you're idling on the "my-commons" page, you should receive live updates as they arrive. When a live update is received, you should see a "Load Newest" button underneath the activity filter tabs.

Let me know if any bugs pop up.