Related BuddyPress plugins

One of the comments that came back from the panel that marked the Bebop project bid was that we should make sure there isn’t already a plugin or method of aggregating resources from third-party websites to BuddyPress. Fair comment. It was the first thing I did when I started thinking about submitting the bid to JISC. I collected links to related plugins but there was nothing I could find that did the job.

There have been some efforts at using BuddyPress for teaching and learning, as can be seen by the Courseware plugin and there are efforts to integrate specific third-party services such as Twitter, Google Plus and Mendeley, and there’s also a plugin for badging achievements, which I can see being used (or modified for use) in an educational context. There’s a plugin that allows you to enrich your activity updates with media that is uploaded locally. There’s a plugin that we already use at Lincoln, that allows you to pull an RSS feed into your group activity stream, (and another one here) as well as various uses of OAuth with BuddyPress and WordPress. BuddyPress is also being used as a collaborative project management tool and a collaborative document editing tool.

Clearly other developers are thinking along the lines of what we’ve proposed for Bebop, which is how BuddyPress can be used in an educational context and reflect a user’s activity external to the platform, but as far as I can see, there isn’t a plugin that allows a user to ¬†easily add their username from YouTube, Jorum or Slideshare, for example, and have those resources aggregated and filtered nicely into their academic profile. The closest there is to that is this RSS aggregation plugin, which is designed to pull in external blog posts. It’s a start though and something we should look at early on.

The Bebop project aims to do more than this though by attempting to pull from the APIs of third-party services and organise the resources into collections on a user’s profile, as well as publish them to their activity stream. It involves more than simply pulling from RSS feeds (although we’ll include this, too), and once the data is being pulled in, we’ll provide a way for it to be pulled out again and re-purposed, assuming the T&C allow us to. Taking Slideshare as an example, could we re-use the data we get out of Slideshare within our organisation?

YOU SHALL NOT: sell, lease, share, transfer, or sublicense the SlideShare APIs or access or access codes thereto or derive income from the use or provision of the SlideShare APIs, whether for direct commercial or monetary gain or otherwise, without SlideShare’s prior, express, written permission;

It’s the word ‘transfer’ that worries me…. Jorum devs, please ensure that the T&C for your forthcoming APIs clearly state that the data via the API carries the same license as the resource itself. (We’ll post more about the T&C of APIs at a later date. If you have any advice, please do tell us).

Ideally, we’d like to be able to warehouse data about resources staff have published elsewhere on the web and have that data accessible over APIs on data.lincoln.ac.uk, like we’re doing with more and more of our data, so that we can build stuff with it. Getting data into BuddyPress is just one part of our project, but showing how the data can be made available for re-use is, arguably, the more interesting aspect.

2 thoughts on “Related BuddyPress plugins

  1. The reason why the RSS plugins are already built is because they are, so to speak, the low-hanging fruit. Nearly every content provider of any kind of user-generated content – be it YouTube (videos), Flickr (images and videos), Twitter (text), Delicious (links + text), etc – provides an RSS feed. This common format means that you only need a single infrastructure for querying and parsing the data – WP’s internal RSS parser, Magpie.

    In contrast, building API-specific importers for content providers is a tiring job, because each provider’s API is different. The way you query Flickr is different from the way you query Twitter, the data returned is different, the authentication schemas are (sometimes) different. In other words, if you want API-level access, you have to build an interface for each of them.

    There is an existing plugin that does a lot of this already, called BuddyStream: http://buddystream.net/supported/ I have only used it lightly, but I have heard excellent things about it.

    Another tack is to stick with RSS for import, but to add a site-specific layer of functionality for each content source. That extra layer would parse the RSS a bit differently for each source, display it differently, and perhaps use some of WP’s built-in sideloading functionality to duplicate the content itself on the BP installation. For example, you might pull in your Flickr stream via RSS, and then have some logic that (a) detects that it’s from Flickr (not just generic RSS), (b) (optionally) copies the image itself from Flickr’s server and loads it into a local media library, and (c) uses some Flickr-specific rules for displaying the content, ie as an image. You can keep storing it in the BP activity stream, but you would label it in such a way (perhaps using the `type` parameter) that it would be easily accessible for, for example, a Flickr-activity widget on a user’s profile.

    That’s a fair amount of work (multiplied by the number of sites you want to support), but I would imagine that the 6-8 most popular content sources would cover 80-90% of the desired use cases, while generic RSS support would cover most of the rest.

    • Thanks, Boone. I’m sure you’re right about parsing the RSS where possible. I just tried to install BuddyStream but it’s producing an error and taking my test site down, so we’ll need to investigate that a bit more. It’s good to know there’s something we can possibly build off. I see its GPL.

      Will be in touch.

Leave a Reply

Your email address will not be published. Required fields are marked *