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.
WordPress’s 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 :)
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!
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’sfirst 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!
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!)
In the past, I’ve written extensively about using Git with WordPress projects. I’ve focused primarily on Git as the primary development channel, with SVN (in this case, plugins.svn.wordpress.org) used for distribution only.
In contrast, I use Git for all my local development on the BuddyPress project. In this case, BP’s “official” history is in its SVN repo. My local Git repo is just a mirror. This setup means that you need a different kind of workflow, one that gives precedence to the Subversion repository. I’ll be using BuddyPress as an example below, but a similar workflow will work for any Subversion-based project where you want to do local development in Git.
(Side note: Mark Jaquith published a similar guide on how he uses Git to do WordPress core development. His process and mine are independently derived, but they are, of necessity, conceptually similar.)
Git will crawl through the entire revision history of the BuddyPress project, which will take a while.
I generally have two active, ongoing branches in my local BP-Git repo, one corresponding to trunk and one corresponding to the current bugfix branch. I use master (the default Git branch) for trunk, since that’ll be the default setup after the clone. You’ll need to create the bugfix branch manually. I use the ’1.6.x’ naming convention for the 1.6 SVN branch, etc.
$ cd /path/to/wordpress/wp-content/plugins/buddypress
$ git checkout -b 1.6.x 1.6 # In other words, create a new branch, called 1.6.x, which tracks svn's 1.6 branch
If you’ll need to do development using BP’s bbPress 1.x implementation (“Group Forums”), you’ll need to manually download bbPress 1.1 into buddypress/bp-forums/bbpress/
Day-to-day development goes something like this:
Make sure you’re on the right branch. Most day-to-day dev happens on trunk/master, but in some cases it’s necessary to work on the current bugfix branch. Once you’re on the right branch, make sure that you have no unstaged changes, and use git-svn-rebase to get the most recent changes from upstream:
$ git checkout 1.6.x
$ git svn rebase
Create a new topic branch for this bugfixing session. I generally name it after the ticket number.
$ git checkout -b bp4453
Fix your bug or develop your feature. Commit small changesets as desired.
When you’re done with your development, you’ll be in one of the following situations.
You’ve fixed the issue, and want to merge your commit history directly back into the public branch. This generally means that you fixed everything with a single changeset, or perhaps a small number of changesets that have good commit messages, etc. In that case, you can do a straight merge back to the public branch. Switch back, git-svn-rebase to make sure none of your collaborators have updated the SVN branch since you started working, and then merge.
You’ve fixed the issue, but you want to reduce a large number of changesets to a single commit. You have a few options here. You can use git rebase -i like Mark suggests. I generally do not do this, because rebasing on publicly shared SVN branches makes me nervous. Instead, in these cases I’ll use a squashed merge, which lays all of your changes on top of the destination branch, and leaves them uncommitted.
$ git checkout 1.6.x
$ git merge --squash bp4453
$ git commit -m "This is the actual commit message I want to show up on BP's SVN"
You want to share your changes with others, in the form of a patch, before committing to SVN. You’ll need to use the git diff utility, while doing a formatting trick to make sure that it’s compatible with the standard UNIX patch utility used in the SVN world.
Assuming you are ready to send some commits up to SVN:
$ git svn dcommit
In some cases, you may have sent a commit to the bugfix branch that needs to be applied separately to the main dev branch (trunk). There’s a couple different ways you might handle this. I usually use git-cherry-pick:
$ git checkout master
$ git svn rebase
$ git cherry-pick e1f2e3f # The hash of the Git commit on the bugfix branch
$ git svn dcommit
Releases follow a regular tag workflow:
$ git checkout 1.6.x
$ git svn tag 1.6.2
We do some weird stuff with BuddyPress (related to mirroring on wordpress.org/extend), which is outside the scope of Git – sadly I have to use svn for some of it :’(
Some of this is specific to BP, but most can be applied to any project where you want to use Git on a project that lives in SVN. Now git out there and git er done! and other ‘git’ puns.
I find Bebop compelling because of what it does, and also because of how it was built. In a nutshell, Bebop is an aggregator for Open Educational Resources, or OERs. ‘OER’ is a term of art among open education folks, referring to learning resources that are available for free use, under an open license. (See OER Commons for a longer definition.) In practice, this can mean anything from videos to lesson plans to games to websites. Bebop is designed to allow members of a BuddyPress community to collect their own OERs from various web services – Twitter, YouTube, Flickr, etc – for display on their BP profiles. It’s a nice demonstration of how BuddyPress can be used as a tool for aggregating work done elsewhere on the web. It also demonstrates another way in which universities can use a free platform like BuddyPress as a non-commercial, locally hosted home for students and faculty, while recognizing that valuable work happens in spaces not under the university’s control. And from a technical point of view, I like how Bebop uses BP’s Activity component and profile metaphors to creative ends.
Bebop was built as part of a “rapid innovation” project. To put the term “rapid” in context: In the context of universities, projects usually move forward glacially. Getting approval and funding may itself take years, and by the time development begins, the original idea/technology is already obsolete. Bebop, in contrast, was conceived and developed over just a couple of months. It’s great to see these kinds of (relatively) rapid projects happening in universities – they can demonstrate to funders the benefits that come along with a bit of agility and risk and freedom.
If you’re running a BuddyPress installation in a university, you might consider taking Bebop for a spin. Get it from the wordpress.org plugin repo or follow development at Github.