Tag Archives: buddypress docs

Expunge non-public content from a WordPress/BuddyPress installation

It’s a common practice to create local WordPress development environments using a copy of the production database. But this can cause problems with a large production site, as the database can become very large, and it is full of non-public information that you may not want to make available to all members of the development team. This is especially problematic when running a plugin like BuddyPress, which allows users to create a great deal of content with various privacy levels.

To work around this problem for the CUNY Academic Commons, I wrote this plugin: cac-database-cleaner. It will remove all non-public data from a WP database, while still leaving an intact database image that can be used to populate a development environment.

WARNING – This is a dangerous tool, as it deletes large amounts of data. Under no circumstances should you install this plugin on a production site. To use: export your production database; import to a separate database and perform any manual changes necessary for the WordPress site to load locally (such as modification of your local hosts file); activate plugin and navigate to Dashboard > Network Admin > CAC Database Cleaner.

Again, do not use this plugin if you don’t know exactly what you’re doing.

Note that plugin support is ideosyncratic to the CUNY Academic Commons, where we run an old version of BuddyPress Docs, an old fork of BuddyPress Group Documents, a plugin called More Privacy Options, legacy bbPress forums, etc. Feel free to modify the plugin to work with whatever other data you’d like.

BuddyPress Docs 1.4 and attachment support

I’ve just released version 1.4 of BuddyPress Docs, my collaborative editing plugin for BuddyPress. The big new feature is the one that users have been asking for since the plugin was first released: file attachments. I’m using a nifty trick (involving the autogeneration of .htaccess files) to ensure that Doc privacy levels are extended to their attachments. I think it’s going to be useful to a lot of people.

In the future, I plan to write a tool to migrate content created by the abandoned BP Group Documents to this new system. Stay tuned.

This round of development was generously sponsored by the Center for Applied Research and Environmental Systems at the University of Missouri. They are long-time users of BuddyPress, and they were pleased to support the development of this feature for the community. Special thanks to David Cavins, who set up the connection between me and CARES, and also contributed huge amounts of technical, conceptual, and design help to Docs 1.4. (He also builds beautiful guitars.) Thanks to CARES and to David!

BuddyPress Docs 1.3, featuring theme compatibility on BP 1.7

I’ve just released version 1.3 of BuddyPress Docs, my WordPress plugin that powers collaborative document editing on a BuddyPress site. The main feature of Docs 1.3 is theme compatibility, which means that top-level Docs templates (archives, single docs, and the Create screen) are no longer necessarily top-level. Using the theme compat feature of BuddyPress 1.7 (currently in beta), this top-level content is put directly into the content area of your theme’s page.php template, ensuring that Docs pages will keep your header, footer, sidebar, and other global elements.

The theme compatibility feature only kicks in if you’re running BP 1.7. Existing installations of Docs on BP < 1.7 will continue to work as before.

Are you a BP Docs user? Are you already testing BuddyPress 1.7? I'd be glad to get your feedback on Docs 1.3. Report any problems on the issue tracker.

Using init callbacks with TinyMCE and wp_editor() in WordPress

WordPress 3.3 introduced wp_editor(). It’s a big improvement over the earlier hacks needed to get a TinyMCE instance on the WP front end. But it broke the feature in my BuddyPress Docs that detected idle time. The problem, in short, was two-fold: my idle-detection JavaScript was loading before the editor was initialized, and it wasn’t detecting key presses inside of the TinyMCE iframe. The solution to both parts of the problem required passing callbacks to the TinyMCE initialization array, in the setup array. It took me a long time to figure out how to do this, so for posterity’s sake, here are some takeaways.

First, the code:

function bp_docs_add_idle_function_to_tinymce( $initArray ) {
	if ( bp_docs_is_bp_docs_page() ) {

$initArray['setup'] = 'function(ed) {
				function(ed) {

// Set up listeners
					jQuery(\'#\' + ed.id + \'_parent\').bind(\'mousemove\',function (evt){



				function(ed) {

return $initArray;
add_filter( 'tiny_mce_before_init', 'bp_docs_add_idle_function_to_tinymce' );

Some notes:

  • I’m passing a ‘setup’ parameter to the TinyMCE init array by filtering tiny_mce_before_init
  • Only do this when you’re editing a BuddyPress Doc – that’s the bp_docs_is_bp_docs_page() check. I don’t want to mess with every instance of TinyMCE on the installation.
  • The setup parameter has to be a string. This gets tricky when the string is supposed to define an unnamed JS callback, because you have to be very careful about escaping quotes. As a string, your callback has to be wrapped in quotes. Also, when WP prints the TinyMCE parameters (and when it sees that your paramater begins with the string ‘function’) it’s going to wrap it in double-quotes. After lots of messing around, I was able to get this to work by using escaped single-quotes. (If you need to double-embed quotes – like a chain of callbacks – use escaped double-quotes.)
  • Where possible, use TinyMCE’s native events. ed.onKeyDown is one of them. It allows me to call my _active() function whenever a key is pressed inside the editor.
  • There are some kinds of actions that aren’t really detectable using TinyMCE’s events. For instance, I wanted to be able to detect when someone was moving their mouse around the iframe and especially TinyMCE’s toolbar. You can see this where I’m binding my callback to mousemove in the TinyMCE _parent element.
  • _initJQuery() and bp_docs_load_idle() are my own functions that need to run after the editor has finished setting up. That’s why they, along with the bind, are called in a callback of ed.onInit – that’s the generic place to put things that need to happen once the editor is up and running.

BuddyPress Docs 1.1: Doc History

BuddyPress Docs History

BuddyPress Docs History

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.

Download BuddyPress Docs from the wordpress.org plugin repo or follow development at Github.

New BuddyPress plugin: BuddyPress Docs

BuddyPress Docs edit screen

BuddyPress Docs edit screen

Today I am releasing the first public beta of a significant new BuddyPress plugin: BuddyPress Docs. BuddyPress Docs is a collaborative, front-end, rich-text, document editing tool for BuddyPress groups (individual user Docs are an upcoming feature). Read much more about the plugin’s features.

This plugin has been developed for the CUNY Academic Commons (though it won’t be live there for a few weeks). Today’s release is a pre-stable beta – it should run fine, but there are bound to be bugs, and you probably won’t want to run it on a production site quite yet.

You can follow the plugin’s development at http://github.com/boonebgorges/buddypress-docs.

BuddyPress Docs

Flattr this

BuddyPress Docs is a powerful and flexible tool for collaborative editing in BuddyPress.

BuddyPress Docs features:

  • Full integration with BuddyPress Groups Docs can be activated on a per-group basis, creating a Docs tab. Doc access, by default, is inherited from group privacy settings. Doc authors, as well as group admins and mods, can override these default settings so that visibility, editing, and commenting of a given doc can be more restrictive.
  • Full integration with activity streams Whenever you create, edit, or comment on a Doc, an activity item will appear in all relevant activity streams. These activity items obey group privacy settings, so that edits in private groups are private, etc. New dropdows in sitewide activity filters allow you to view Docs activity selectively. Full activity integration means that the plugin can be coupled with a plugin like BuddyPress Group Activity Subscription for fine-grained activity notification.
  • Front-end, rich editing BuddyPress Docs has full rich-text editing, powered by WordPress’s own TinyMCE editor. Because it’s the WordPress editor, users will experience the power and ease of use they’ve come to know from the Dashboard. Because it’s on the front end, users don’t ever need to leave your BuddyPress environment to edit Docs.
  • Doc tags With full taxonomy support, BuddyPress Docs lets your users tag and organize their content however they’d like. Doc lists can be filtered by tag for easy navigation. You can see at a glance how many times a tag has been used in a given group (and, in an upcoming release, sitewide).
  • Easy sorting and search When viewing Doc lists, you can sort by a number of criteria, making it easy to find what you’re looking for. There’s also a search box, which is smart enough to limit searches to specific group contexts dynamically.
  • Comments Leave comments on docs just like you would on blog posts.
  • Protections against overwrites To make sure that users don’t overwrite each other’s work, BuddyPress Docs only allows a single user to edit a Doc at a given time. To make sure that others aren’t blocked from editing by those who leave leave Docs open and then forget about them (ahem), there is a timeout and autosave after 30 minutes of idle time.
  • Developer goodies Built by the person who has (probably!) built more BuddyPress plugins than anyone else in the world, BuddyPress Docs is designed with extensibility in mind. do_action() and apply_filters() is everywhere. Add-ons like taxonomy and hierarchy, and integration pieces like groups (and the upcoming profile integration), are totally modular. BuddyPress Docs uses WP’s internal APIs wherever possible: custom post types, custom taxonomies, and more. Templates have been abstracted out to make theme overrides easy. And – inline documentation EVERYWHERE! Feedback from developers is welcome: ongoing development lives at http://github.com/boonebgorges/buddypress-docs.

Lots more development is coming! User profile integration, BuddyPress Documents upload integration, and more!

NOTE The plugin is listed as requiring WordPress 3.1 and BuddyPress 1.3. While I have been developing against the BP 1.3 trunk, it should work fine with BP 1.2.8 as well. However, do NOT use the plugin with WP 3.0.x, as it will expose private group Docs.


  1. Upload the bp-group-reviews directory to your WP plugins folder and activate
  2. Activate Docs on a per-group basis in the group admin section

Download the plugin here.

BuddyPress Docs has been downloaded 26,474 times. Are you using this plugin? Consider a donation.

Version history

1.0-beta – March 1, 2011
Initial release