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!
Mostly for my own records, here are a few recent Boone-related videos and interviews from around the web:
- Code Poet interview – April 18, 2013. In which I speak at length (ramble?) about BuddyPress, the university, and the value of free software
- WordSesh panel – April 13, 2013. A livestreamed discussion about BuddyPress with John, Paul, Ray, and Tammie.
- BuddyCamp Miami presentation – April 5, 2013. A brief talk where I talk about how to use BuddyPress’s Group Extension API to add BP features to a WordPress plugin. The slides are at blo.so/bcmia.
- WPNYC presentation – January 15, 2013. A talk I gave on the big new features in BuddyPress 1.7
Anthologize, I haven’t forgotten about you! I have some very cool stuff in the works, but for now, a quick update on the progress of the campaign-funded work.
Back in 2011, Patrick Murray-John added some unit tests to Anthologize, covering a number of public methods in the
TeiApi class. A number of the major refactoring jobs I’m currently undertaking will require additional test coverage, but they are (unlike
TeiApi) dependent on WordPress being initalized. So I’ve migrated Anthologize’s tests to use the WP test suite. I’ve used the scaffold provided by the dope and phatte wp-cli (incidentally, I hope that their scaffold becomes the de facto standard for WP plugin tests).
This change means that, in addition to requiring PHPUnit, you’ll also need to have the WP test suite installed. You can install it manually, but I recommend using wp-cli to get the job done in just a command or two. In brief:
$ wp core init-tests /path/to/wp-tests --dbname=wp_test --dbuser=root --dbpass=asd
$ mysql -u'root' -p'asd' -e 'CREATE DATABASE IF NOT EXISTS wp_test'
To run the tests,
$ cd /path/to/wp/wp-content/plugins/anthologize
$ WP_TESTS_DIR=~/path/to/wp-tests phpunit
You can define
WP_TESTS_DIR in your .bashrc file for quicker use in the future.
This post is brought to you by Anthologize campaign supporter Demokratie & Dialog. D&D, a Major Sponsor of Anthologize (woo hoo!), is using WordPress and BuddyPress in amazing ways both to study the way that government policy affects youth and to get youth themselves involved in the development of said policy. I had a chance to get to know the very excellent Andreas Karsten of D&D at BuddyCamp Vancouver last year, and we have big plans to start a BuddyPress jazz band. Many thanks for your support of WP, BP, and Anthologize!
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.
wp_nav_menu() fetches a custom menu, as built using the Menus GUI, for display in a theme. I had a project where I needed to add some items to this menu dynamically – the links would be different for each user, and wouldn’t appear for logged-out users, so they couldn’t really be added using the GUI. After a bit of futzing, I was able to insert my menu items, tricking WP into thinking that they were native.
Details: For logged-in users, I needed to add three subnav items underneath the top-level ‘Activity’ item, if it was present. So at the beginning of the function, you’ll see that I’m doing some BuddyPress-specific stuff, to find the Activity menu. If you need to use a
menu_item_parent like I did, you’ll have to supply your own method for finding it (or just hardcode it). The heavy lifting is done in the second foreach loop, where I build
stdClass objects just robust enough that WordPress will interpret them as true nav menu items.
I get a lot of requests to do BuddyPress and WordPress dev work, and I can only take a fraction of that work myself. So I end up referring a lot of work to other developers. Sometimes I hear back from the client that one of the referrals worked out (or didn’t). Unfortunately, it’s very rare that I hear from the developer himself about it.
It’s unfortunate not because I need the gratification (although it’s nice to hear “thanks for the referrals” sometimes). It’s unfortunate because I want to be a good referer. I read every job inquiry carefully, and I try to make good matches between inquiries and what I know about the developers on my list. I look at how big the job will be, what kind of work it is (plugin dev, theme work, troubleshooting, etc), what field the client comes from (education, journalism, retail, etc), and other stuff like that, and match it up with the devs I think would be best for (and would most enjoy) that particular referral. When I never hear back from these friends, I don’t have the data I need. Stuff like: If you refused the job, why? Too busy? Not the kind of work you generally like to do? Did the referral make your lousy-client-sense tingle? If you took the job, how did it go? Was the client good to work with? Should I continue to send work like this?
So please: if you know that one of your client inquiries came from a friend’s referral, ping that friend at some point down the road. The more info you share, the better the referrals you’ll get from me.
As a side note, I’ve been chatting privately with David Bisset about coming up with systematic solutions to the kinds of problems I’ve described here (among others). But in the meantime, an occasional email will do the trick :)
It’s been a long time coming, but it’s here: Commons In A Box. Today we’re releasing version 1.0-beta1, the first public release. For some background on Commons In A Box, here’s today’s press release, my Commons Dev Blog post explaining some of the features of Commons In A Box, and the 2011 press release announcing the project.
The primary goal of Commons In A Box, in my view, is to reduce the barrier of entry to setting up BuddyPress community sites. BuddyPress is an extremely powerful and flexible platform for developing social WordPress sites, but getting a BP site right takes knowledge (which plugins are worth installing, which ones work best together, etc) and elbow-grease (customizing your theme, keeping a complex system up to date). These practical requirements have made BuddyPress seem imposing to many users – including, and perhaps especially, the users that need free community software the most, such as educational institutions. Commons In A Box lowers these barriers in a serious way, by helping with plugin selection and installation, and by providing a beautiful and flexible default theme. My hope is that Commons In A Box will serve as a gateway for a swath of potential users into the world of BuddyPress, WordPress, and free software more generally.
The process of pitching, planning, and producing Commons In A Box has been interesting, frustrating, and rewarding. In the upcoming weeks and months, I may write more about this process, and what I’ll personally take away from it. In the meantime, I’ll say that I’m very pleased to be ending this first stage of development, and pushing it into the wild, since software – even imperfect software – is infinitely more valuable when it’s out there, being used, than when it’s mouldering on a developer’s machine. Shipping FTW!
Learn more about Commons In A Box.
Today I’m releasing version 1.2 of BuddyPress Docs. This is a major release for the plugin, representing a near-entire rewrite. Read more about the release at the CUNY Academic Commons Dev Blog.
The first-ever BuddyCamp was held last weekend in Vancouver, in conjuction with WordCamp Vancouver. It was a fantastic event in so many ways. Here are a couple of personal highlights for me:
- First and foremost, it’s always a thrill to spend face time with people I work with remotely. My Wisconsinite-in-arms John and I have worked closely for years on BuddyPress, and we see each other a few times a year at WP events. I’ve worked with Ray and Bowe for nearly as long, both on free software projects and client work, and this weekend was my first time meeting either in person. The list of other current-and-future-BP-community-members I met IRL for the first time this weekend is too long to spell out here. But there’s no question that these connections were the best part of the event.
- Had a great time on Hack Day, where I believe I gave props to eight different people in commit messages – several of whom were first-time contributors. Of special note was #4600, which took me and Stéphane Boisvert a good 90 minutes to sort out. That’s the kind of over-each-other’s-shoulders, team bugfixing that I wish I got to do more of.
- It was a pleasure to have Matt in attendance. Somehow, we’d never managed to meet each other before this weekend. He was generous with his thoughts on the state of BuddyPress and directions for further development, and he was gracious about those points where he and I disgreed (aside from the “intellectually lazy” line ;). Gave me lots to think about.
- I hesitate to call BuddyPress’s founding developer a “prodigal son”, but it was certainly a kick to commit Andy’s first contribution to the project in several years!
The fact that this kind of event took place in the first place – much less that it was so successful – is, I think, hugely important to BuddyPress. It demonstrates that there’s a vibrant community around the software and its uses, the kind of cohesion that makes meetups like BuddyCamp worth traveling for. So I’d like to extend my sincere thanks to the organizing team of BuddyCamp Vancouver, whose hard work enabled a really incredible weekend for a lot of folks (or at least for me!): Cyri Jones, Joey Kudish, Jill Binder, Roland Frazer, all the BCIT and Capilano University students who helped out, and to the sponsors who made it possible. Thank you all so much!
Now, who’s gonna organize the next BuddyCamp? :)
For those Bo(o)neheads who follow me to every event in VW vans, I’ll be giving three talks in Vancouver next month:
- BuddyPress: Beyond Facebook Clones, Oct 13, WordCamp Vancouver. I’ll highlight some uses of BP that are not straightforward social networks. (BTW, if you know of any really cool ones, please let me know in the comments!)
- Free Software and the University: The Story of the CUNY Academic Commons, Oct 14, BuddyCamp Vancouver. I’ll be using the story of the Commons as
an excuse to rant about an allegory about the importance of free software in public schools.
- Getting Started with BuddyPress Plugins, Oct 14, BuddyCamp Vancouver. I’ll be giving an overview of what WordPress plugin developers need to know about getting their feet wet with BP plugins.