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.
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.)
- Get Git.
- Create a local directory for your BuddyPress installation. Use git-svn-clone to pull the SVN revision history into this directory.
$ mkdir /path/to/wordpress/wp-content/plugins/buddypress
$ git svn clone -T trunk -t tags -b branches http://buddypress.svn.wordpress.org /path/to/wordpress/wp-content/plugins/buddypress
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
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.
$ git checkout 1.6.x $ git svn rebase
$ git merge bp4453
- 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.
$ git diff --no-prefix 1.6.x...HEAD > ~/path/to/patches/4453.01.patch
- 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 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.
Hey you! It’s just been announced that I’ll be keynoting BuddyCamp Vancouver in October. Have you carved the date in your calendar (assuming your calendar is made of wood, otherwise any other form of marking will do just fine)?