Monthly Archives: May 2014

Yes! We have no THATCamp

I work extensively with universities, but I don’t really think of myself as of universities anymore. One of the things that has most stubbornly kept me connected to the academic world has been the yearly pilgrimage to RRCHNM for THATCamp. Since leaving grad school, it’s been one of my last remaining interfaces with academia where I don’t feel like a service provider, but like an equal participant (kinda the point of THATCamp).

This year, there’ll be no THATCamp at CHNM. Until today, it hadn’t dawned on me that not only am I missing my usual summer kick-off, but I’m also missing my annual reminder that I used to be a geek-leaning academic rather than an academic-leaning geek.

On that note, an only slightly irrelevant clip:

CSV export of WordPress data

I’m often asked by clients to export various bits of data from a WordPress site into a CSV file. For simple queries, this kind of technique is simplest. For more complex queries, I use PHP to do some of the heavy lifting. Below is some of the boilerplate I use for generating the proper headers, etc. Just swap out the filename and the query logic for your own, and visit wp-admin?bbg_export as a super admin.

Five years of BuddyPress

I started working with BuddyPress by accident. In February 2009, I responded to a tweet from my friend Matt Gold asking for help with a CSS issue on a site he was working on. That site was the still-in-beta CUNY Academic Commons, running on the still-in-beta BuddyPress. Within a few weeks, I was doing paid work for Matt’s project, working with BP (and WP, and web software in general) for the first time. And BuddyPress 1.0 came out just a few weeks after that.

Over the last five years, BuddyPress has taken over my professional life. I began by writing BP plugins. I started to contribute to BP itself through support and patches. I became a member and eventually a lead on the core team. My consultation work involves BuddyPress almost exclusively; this success (in terms of both money and impact) emboldened me to drop out of graduate school. People know me as “the BuddyPress guy”. When you type “boone gorges” into Google, it suggests “boone gorges buddypress”.

I feel very grateful to have stumbled into the project when I did. It aligns with many of my philosophical and political positions: the primacy of people over content, the importance of data ownership and free software, the fight against parasitic software vendors in public institutions. I’ve met some good friends through my association with BP. I’ve leveraged my expertise into a fun and comfortable career.

But the fact remains that it’s all been a fluke. When I realized it’s been five whole years, I couldn’t shake the thought: WTF. How strange to devote such a large part of one’s life to something that was such an accident. [Something something destiny something something forks in the road something.] I got lucky because I happened to stumble into something that was a particularly good fit for me. But I also took many leaps of faith along the way: agreeing to work on the CUNY Academic Commons when I had pretty much no idea what I was doing, submitting my first patches to BP, quitting my job, upping my rates, donating huge amounts of time to the free project instead of doing paid client work. I’m glad I had the guts to make each of these leaps.

Happy birthday to BuddyPress, and happy anniversary to me. Here’s to many more happy accidents!

Manually copy content and settings between sites in a WP network

I just had a request to copy the contents and settings from one site within a WordPress network to another within the same network. (The destination site is the “staging” version of the source.) Daniel Bachhuber’s Dictator along with the general wp-cli export/import tools are the ideal tools for this sort of thing, but due to some odd circumstances I wasn’t able to use them. So here’s a quick rundown of what I ended up doing. (This post mainly for my own records. If any step below is confusing to you, you probably should not be doing it this way. Use at your own risk!)

  • Get exports of the production db tables (as well as staging, for backup). I ended up crafting the following (614 is the ID of the production site):
    mysql -u [username] -p information_schema -B -N -e "SELECT table_name FROM tables WHERE table_name LIKE 'wp_614_%'" | xargs mysqldump -u [username] -p [database name] --add-drop-table --skip-lock-tables --quick --extended-insert --result-file=[/path/to/dumpfile.sql]
  • I downloaded that dumpfile and imported it into a local database, so that I could run it through to do the necessary URL replacements. (Could’ve used wp-cli, but this way I didn’t need to have a functional local WP installation.)
  • Did a further search and replace to change instances of ‘wp_614_’ to ‘wp_860_’ (the staging site ID)
  • Uploaded that .sql file and imported
  • Next, I had to handle files. Normally this would take 30 seconds at the command line, but permissions were locked down on this server: my SSH user didn’t have proper permissions to modify some of the directories in blogs.dir. So I wrote a quick script that would run the necessary commands in PHP (as the webserver user), implemented as an mu-plugin:

Again, use at your own risk.