My Anthologize development fundraiser is going great so far – as of this writing, $870 has been pledged. Put that together with the generous match from CHNM, and you’ve got $1,740. This translates to over 23 hours of dev time. A huge thanks to those who have already made pledges – you’ll be hearing from me individually once the campaign is over on October 10.
Aside from some miscellaneous cleanup and compatibility issues, my first goal during the development period will be to get the plugin running better in more server environments. Our most reported bug is that Anthologize Exports time out due to memory limits. This is an especially vexing problem on inexpensive, shared hosting, which is what much of the Anthologize target audience uses for hosting their WordPress sites. I’ve started to sketch out a plan in this Github ticket for making Anthologize exports less memory-hungry.
It’s always hard to estimate these things, but I’m guessing that 23 hours will be enough to do the initial plugin cleanup, and to get most of the way toward the rewrite of the export process described above. That’s progress!
Remember, more pledges mean more development. If you want to see more fixes and enhancements to Anthologize, you’ve got until October 10 to donate.
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 2010, I was on the team that built Anthologize, a WordPress plugin for turning your WP content into ebooks. (For more on the project, check out my previous posts on Anthologize.) People continue to be interested in using Anthologize. Just the other day, for example, the nice folks at Profhacker published a post on using Anthologize to build a printable syllabus. When I saw that blog post come through my Twitter stream, my first thought was “Oh boy, here comes another round of bug reports that the team doesn’t have time to address”. Somewhat in jest, I tweeted the following:
I got quite a bit more interest than I expected. In addition to a couple direct inquiries from individuals and organizations, CHNM – where Anthologize was originally prototyped – offered to match, dollar for dollar, any donations to the cause (up to a maximum of $5,000).
So now I’ve got to put my money (or your money!) where my mouth is. I’ve started an Indiegogo campaign where you can pledge any amount to support a round (or more) of development time for Anthologize. Check it out for full details: http://www.indiegogo.com/anthologize. The campaign runs through October 10, and development will start in November.
Please spread the word!
Wood panels, fake bricks, dim lights, frosted glass
Padded horseshoe bar, cushy pleather stools
Cigarette vending machine
Brandy old fashioned sour, rocks glass, maraschino cherry
Pickle garnish, olive garnish, mushroom garnish
Blatz, Schlitz, Old Milwaukee
Order at the bar, shake of the day
Table numbers on table tents
Baskets of sleeves of breadsticks and crackers
Choice of cheese spreads
Hot bacon dressing
Fried fish, fried mushrooms, fried frog legs, fried cheese
Prime rib king cut, prime rib queen cut
At the country crossroads
Getting dressed up means
The Packers shirt without a grease stain
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)?
My last post on using Git with wordpress.org/extend is one of the more popular resources on the web on the subject. But since writing it, I’ve changed my workflow a bit more. So, instead of writing a new guide, I added an addendum to the old one. Enjoy!
I realized today that, as of a few weeks ago, I’ve lived in New York City for ten years.
In 2002, I was a college senior in Mt Vernon, Iowa. I’d received a few different offers for graduate school fellowships. In the end, I ended up choosing CUNY more or less on a lark; NYC seemed like a cool place to live. So, I packed up a truck, and moved to a city two thousand times the size of Mt Vernon, and one hundred times the size of any city where I’d ever lived.
In everyone’s life there’s a handful of breakpoints: moments at which you make a decision that (intentionally or otherwise) forever and irreversibly changes everything. Ten years on, it’s dizzying to imagine the path not taken – the road that didn’t lead to this city, this job, this wife, this child, this me. I’m humbled, and somehow comforted, by the power that chance and caprice wield over the formation of the things that make up a life.
Here’s a picture I took of myself a few weeks after moving to my first place in NY, a shared apartment at 129th St and Lenox Ave:
Plus ça change….
I like to use email-style quotes when I write:
In your email, you said
> Boone, you suck
You were totally wrong about that.
I wanted to be able to do the same thing on my blog (or in my blog comments) and have the quote rendered as an html <blockquote> element. So I wrote a little filter.
Martha Burtis, instructional technologist extraordinnaire at University of Mary Washington, wrote earlier today about some WordPress development workshops she’ll be leading at Universidad del Sagrado Corazón in the upcoming days. She’s responding to my prodding, and in the process, demonstrates with aplomb a few of my central points:
On the overlap between web development and education:
I got into Web design/development years ago because I loved how it allowed me to architect experiences. I got into higher education at the same time because I really do believe that education is one of our society’s highest callings. Blending my passion for education with my passion to craft experiences is basically what drives me [...] I believe strongly that the fundamental nature of the code we work with speaks to the values we’re trying to embrace in the practices that our code enables. I love WordPress because it affords me possibilities. It affords me possibilities because it is open.
On how she plans to frame the technical parts of the workshop:
People are always amazed when they find out I studied English as an undergrad. I never quite understand why. Don’t they know that code is poetry? Seriously, I’m going to talk a bit about the relationship between code and poetry — a relationship that I’ve always found fascinating. I’m also going to talk about code as a tool for building experience. Finally, I’m going to talk about the way our values and politics (small “p”) inhabit the code we work with.
Martha illustrates the value that WPedu can bring to the broader free software project. People working with WordPress inside of the university approach their development (design, etc) with a focus on the user, and the benefits that the open nature of the software bring to the user experience. And people from academic backgrounds are trained to reflect critically on the way that software mediates our relationships with the world and with each other. This is a breath of fresh air in what can sometimes be an overcommercialized and results-focused community. Rock on, Martha!