I’ve just released version 1.1 of BuddyPress Docs, my collaborative editing software for BuddyPress.
The big new feature in version 1.1 is the History tab. After upgrading, you’ll notice that what used to be a single Edit button has been reorganized into three tabs: Read, Edit, and History. History allows you to brows the entire revision history of a document, to compare the differences between two revisions side by side, to view a single revision, or to restore to any point in the document’s history. Access to the History tab can be limited in the same way that access to the Edit tab can be, on a doc-by-doc basis.
This new feature will, I hope, bring some of the best qualities of wikis to BuddyPress Docs, and make Docs an even better way to collaborate.
The feature will be live on the CUNY Academic Commons in the upcoming weeks.
When I explain the CUNY Academic Commons to someone for the first time, the words ‘connect’ and ‘collaborate’ usually loom large. We provide a number of tools to make it easier for people to find each other (that’s the connecting), and then we try to make it easy for those people to work together on projects that matter to them (that’s the collaborating). Today I am releasing the first public beta of a new BuddyPress plugin that will, I hope, be an important tool in the Commons (and BuddyPress) collaboration toolbox: BuddyPress Docs.
BuddyPress Docs adds a new tab to groups where members can collectively create and edit documents, using an easy-to-use rich text editor. Docs support tagging, hierarchy, oEmbed multimedia, and much more. I’ve written about the feature list in detail on the BuddyPress Docs homepage.
Today the project is being released in a near-stable public beta. That means a few things. First, for the moment you run the plugin on a production site at your own risk, as there are bound to be bugs and rough spots (which I hope you will report back to me!). Second, it means that it’s not up and running on the Commons quite yet. BuddyPress Docs is slated to be turned on here with the release of Commons 1.2, which should be sometime in the next few weeks. The intervening weeks should give folks in the general BuddyPress community some time to put Docs through its paces before it gets put to work here.
The official documentation states that BuddyPress Docs requires WordPress 3.1 and BuddyPress 1.3. The latter requirement is a bit of an overstatement; Docs has been tested with BuddyPress 1.2.8 and it works well. However, the former requirement is strict: though the plugin might appear to work with versions of WP prior to 3.1, certain key features will not work (in particular, taxonomies will not work correctly, so that all Docs will appear on every group, no matter which group created them). Perhaps for the 1.0 stable release I’ll forcibly prevent the plugin from being loaded on those earlier versions of WP.
A member of the Commons community recently requested the ability to embed Prezi presentations into her Commons blog. I had a look at the options available in the wordpress.org repository, and the pickings were slim indeed. So I wrote my own plugin, Prezi WP. It’s pretty simple: use the [prezi] shortcode in your posts to embed a presentation. See the plugin homepage for more details on how to use the plugin, and how to download it and use it on your own WP installation.
Here on the CUNY Academic Commons, we have an installation of MediaWiki which runs alongside our WordPress/BuddyPress installation. Without some additional coding, edits on the wiki don’t show up in the Commons News feed, and as a result they tend to get a little lost in the shuffle. This new plugin, BP External Activity, addresses this issue by allowing the administrator of a BuddyPress installation to specify an arbitrary RSS feed whose items will be regularly imported into the activity stream.
The plugin imports RSS feeds every hour. You may find that you need to decrease your Simplepie cache time to make it work: add_filter( 'wp_feed_cache_transient_lifetime', create_function('$a', 'return 600;') );
reduces the RSS cache to ten minutes, for example. Put that in your bp-custom.php file if you are having problems with the plugin.
At the moment, the plugin uses the Author field from the RSS feed to look for a matching author in your WP database. If it doesn’t find one, it uses the unlinked text ‘A user’, as in ‘A user edited the wiki page…’.
Thanks to Andy Peatling, whose External Group Blogs served as the inspiration for a good part of the code.
One of the goals of the Community Team behind the CUNY Academic Commons is to figure out how members are using the site, so that we can make it a better place for meeting and collaborating with each other. With a system like BuddyPress, though, it’s a bit hard to get a general sense of what’s going on on the site. BP System Report is a new plugin meant to address this issue.
BP System Report records regular summaries of statistics related to your BuddyPress installation. You can then compare any two snapshots using the built-in comparison tool, which calculates percentage differences. The information currently gathered by the plugin:
Members: total number, number active during report interval, percent active, total friendship connections, average friendships per member
Groups: total number, number active, percent active, total group memberships, average group membership
Public/private/hidden groups: total number, number active, percent active, total membership, average membership
Blogs: total number, number active, percent active
The plugin is quite beta, so still might be buggy. Please feel free to report problems.
Future versions of this plugin will include:
more analytical data collected
better admin control over report frequency
Regarding this last point: the BP System Report defaults to twice-daily reports. If you’d like to adjust it manually, deactivate the plugin, edit the line wp_schedule_event( time() + 30, 'twicedaily', 'bp_system_report_pseudo_cron_hook' );
in bp-system-report.php to say ‘hourly’ or ‘daily’ or ‘weekly’ (or some custom time you define in bp_system_report_more_reccurences() )
BuddyPress has great group administrator functions – the ability to invite members to groups, to promote them to different statuses, the ability to ban certain member, and so on. But unless the sitewide administrator is also the administrator of the group, the site admin does not have the same abilities. On some sites – like here on the Academic Commons, where it’s frequently desirable to add members manually to groups – this limitation for sitewide admins can be somewhat restricting.
This plugin, BP Group Management, creates a new administration panel to the Dashboard, accessible only by the sitewide administrator, which does the following:
provides a sortable list of all groups (public, private, and hidden) with their created-on dates and ID numbers
allows admins to delete groups easily
allows admins to view lists of current members, and to promote/demote/ban them
allows admins to add any member of the site directly to the group, skipping the need for invitations
The version of the plugin in the repository only works for versions of BuddyPress 1.2 and greater. For a mostly functional version of the plugin that works with BP 1.1.3 (no guarantees on any other versions, but it should work down to BP 1.1 at least), click here.
By default, BuddyPress does not include comments from non-members (or non-logged-in users more generally) in the sitewide activity stream. For some communities, this default behavior is probably just fine. But in a community like the CUNY Academic Commons, which aims to attract readership and conversation from all sorts of folks, whether or not they’re signed in, the sitewide activity stream will be much more meaningful if it includes comments from everyone.
My new plugin, BP Include Non-Member Comments, was built with this purpose in mind. The plugin is activated here on the CUNY Academic Commons, so that all comments on your blog – whether from logged-in users or not – will show up on the news feed.
The plugin has been tested on version 1.1.3 of BP, as well as the 1.2 release candidate. If you want to use the plugin for 1.1.3 or lower, you will need to uncomment the first few add_action and add_filter lines in the plugin file.
Technical caveat: Non-logged-in commenters have BP user_id 0. When BP creates the activity stream, it decides whether or not to show the Delete button by checking to see whether the user_id for the currently logged in user is the same as the user_id of the person to whom the comment belongs. Presumably, though, you don’t want non-logged-in viewers of the activity stream to be able to delete items from the activity stream at all. BP’s core code is not currently set up to make it easy to remove these buttons, so I employed an ugly fix. If you have changed your theme significantly from the default, you might have to adjust the filter bp_nonmember_comment_content (near the end of the plugin) to remove the button properly.
I threw a little something together today to add WYSIWYG editing to BuddyPress, using TinyMCE. I want to be careful about the tags I allow, so I’m whitelisting, which is a bit tedious. As a result, there are only a few buttons available: a, em, strong, ul, ol, li. It’s a start, though.
Seems to work everywhere in BP: forums, wire, messages, profile pages.
A note about TinyMCE: WP ships with TinyMCE, and I thought it made sense to use that version instead of attaching one to this plugin. I think that the path to TinyMCE (line 18 of the plugin) should work on all installations, but you may have to tinker if you don’t see it popping up in the head of your BP pages. Moreover, the language files for WP’s version of TinyMCE are misnamed, which means that they don’t work right out of the box (at least for me they don’t). You may need to change the name of wp-includes/js/tinymce/langs/wp-langs-en.php to en.php in order to get the hover and help text in the TinyMCE box to work.
Download the plugin here. Don’t use in a production environment unless you are very certain that you are satisfied with the security of this plugin!
In my view, the most powerful feature of BuddyPress – the feature that powers the core goal of the CUNY Academic Commons, that of collaboration – is groups. By default, BuddyPress only lets you invite other members of the community to your group if you and the member are already friends within BuddyPress. In some communities, this feature probably prevents a lot of spam. But in other communities, like the one here at the Commons, the friendship requirement adds a sometimes inconvenient extra step to the process of getting a productive group up and running.
This new plugin, Invite Anyone, does just what its name claims: it alters the group invitation process to allow group creators and administrators to invite anyone from their BuddyPress installation, not just their friends.
Like so often happens, though, solving this one problem made another one pop up: Scrolling through a list of your friends to find potential invitees is one thing, but scrolling through a list of every member of the site is another thing entirely. Most communities, including the CUNY Academic Commons, will simply have too many members. To make things easier, I’ve taken the autosuggest feature from the Compose Message screen in BuddyPress and retooled it to work on the Send Invites screen as well. Start typing the name of the user you’d like to invite, and with each letter you type, BuddyPress will make better and better suggestions as to who you mean. Just hit enter or click to add the suggested user to the invited list.
After I’ve done a bit more testing with our custom theme here on the Commons, I’ll activate the plugin on this site, so that members of the Commons community can take advantage of the new feature.
A technical note: I tested the plugin in a variety of different environments (different browsers, different themes, different servers) and stumbled upon a few issues, in particular with the autosuggest AJAX in Chrome for Mac. If you find similar issues, or have any other feedback, please leave a comment.
Rodney Blevins and Marius Ooms wrote a fantastic plugin for BuddyPress called Groupblog, which allows BP groups to easily create a blog associated with their group. The killer feature of the plugin is the ability to add all group members to the blog (as authors, editors, subscribers, whatever you’d like) in a more or less automatic fashion – a far, far easier task than adding users manually through Dashboard > Add User.
I found, though, that the process wasn’t quite as automatic as I’d like. They’d based the code for adding users on a plugin by Burt Adsit called Community Blogs. Community Blogs only triggered the user adding process on a one-by-one basis: members of a group weren’t added to the group’s blog until they visited the blog. This is problematic for a few reasons. First, it’s an added step that creates some confusion among group admins and members, who assume that community blog membership should be automatic. Second, we’ve enabled various levels of privacy for blogs at the CUNY Academic Commons, and group members who were not yet members of a private group blog couldn’t really visit the blog to kick start the process. (Strictly speaking, that’s not true: the add user process was hooked to a process that took place when the blog’s login screen popped up, which happens when you persistently try to visit a blog to which you don’t have access. But this is extremely confusing.)
I took a bit of time today to rework how Groupblog handles the add user process. With the new setup, every member of a group is added to the group blog at once. The process is put into motion when the blog’s administrator updates and saves the group’s Group Blog settings. Other members of the BP community who join the group after the initial blog setup are added automatically to the blog as well, in accordance with the settings that the admin has determined for member permissions.
All the changes I made to the plugin are found in the main plugin file, bp-groupblog.php. You can download the modified file here: bp-groupblog.php.txt (don’t forget to make sure that the file is named bp-groupblog.php to make the plugin work). Just replace the stock version of the file with this one to make the changes. I intentionally did not clean up the plugin – all the original code is deactivated but still present beside the new code – because I wanted users to be able to differentiate what I had written from what the original authors had written (at least for now).