[Update 2012-07-28: It’s been almost 3/4 a year since I wrote this and time hasn’t been on my side for getting involved in WordPress core/trac. Hopefully soon…]
History with WordPress
My first foray with WordPress came about 7 years ago, before I really knew much about the platform. I wanted to write a blog, which no one ended up reading (hopefully people read this, but that’s another can of worms). Then I started Loot Ninja, a video game reviews and editorial website, and we chose WordPress as our platform. It was pretty sparse at first, just grabbing some off the shelf themes and plugins. As time went on, I wrote a couple custom themes, functions and plugins to suit the site’s needs. Fast forward to today, where client projects for Kernel Creative Media are bending and shaping WordPress in ways I never would have imagined in those early days. I’ve used more content management systems than I’d care to count and I always come back to WordPress as my go-to favorite.
Deciding to contribute wasn’t just an “oh, I’ll do that” decision. It requires time and dedication to make the platform and code better. The first thing I did was read up on the ways to contribute to WordPress. I already participate in the IRC chat (I’m “mattbanks” on Freenode), and post occasionally in the Support Forums, but I wanted to do even more, so I decided I would take a look at WordPress Core and see if I could work and test any patches. There are some caveats if you’re in a similar situation, which are all fine by me. You have to be familiar and comfortable working from the command line. You have to be able to articulate and document bugs and patches. You have to be patient enough to know that anything broken can be fixed. I feel it’s time for me to help.
As you’re reading this, keep in mind that I’m a beginner at contributing to WordPress. If you’re a seasoned vet, you’ll know this already, but I wanted to document my experiences so others might join in and contribute as well.
Subversion on Mac – It’s Just That Easy
If you’re running Windows, I’m sorry. I’m a big Mac fan and use them both at work at home. Things are just easier and the tools you need are readily at your disposal. And with a Mac, checking out the source code with Subversion is a snap. One of the WordPress lead developers, Mark Jaquith, has a lovely tutorial for getting setup quickly on his blog. The gist of is that you want to create a folder to house the WordPress files (I made one on Dropbox so I can use multiple machines easily), and then run the following command from Terminal:
svn co http://svn.automattic.com/wordpress/trunk/ .
Note the space and period at the end there. When I first ran the command without them, a sub-folder called “trunk” was created to separate the trunk branch from any other branches I might check out. Since I’ll only be working from trunk, having it an extra folder level deep isn’t necessary, so I started over. Once I had the files downloaded, it’s just a matter of updating my local files before I start any work. A simple command from Terminal takes care of that:
So why use Terminal for all of this instead of an app like Versions or Cornerstone? Being a comfortable git fan who uses Tower, Github’s Mac App as well as the git command line, my first instinct was to grab a copy of either Versions of Cornerstone and go to work, but Andrew Nacin, another core developer for WordPress, let me know about issues with patching and creating diff files with the Mac software.
— Andrew Nacin (@nacin) December 10, 2011
Patching, Diffs, and the World of Contribution
So what are these diff files? When you change something to create a patch, you want to create a diff file to send the differences to the WordPress Trac for testing. This patch allows other developers to test what you’ve just written to make sure it’s secure, has good performance, and actually fixes what you say it does. Creating diff files is easy with Subversion in Terminal. You can either make a patch for a particular filename:
svn diff filename.php > filename.diff
Or you can make a big patch for all the files you’ve changed:
svn diff > big_patch.diff
Once you’re ready, post an issue over at the WordPress Trac with your diff file to queue it up for testing. You’ll get responses form other developers, possibly some debate on whether the change is necessary, and it’ll either get approved or not.
Many times, though, you’ll be testing other people’s patches. Reading through the issue list is a great way to find out what needs fixing. If something needs a patch, hop in and code it if it you can, or test a patch that someone else submitted. Again, it’s a simple process at the command line. Download the file, place it in the WordPress directory you cloned earlier, and drop this bad boy into Terminal (obviously, with all of these examples, you need to replace paths and filenames to suit your environment):
patch -p0 < patch.diff
If you find problems applying the patch or bugs afterwards, posting back in Trac lets everyone know. It’s a fairly simple process if you’re comfortable with all of the tools.
What’s in it for Me?
So why did I decide this was for me? Like I said earlier, I wanted to give back and help make the system I use on a daily basis better for myself and all of its users. I had a patch ready to go for a bug I’ve been noticing (rel=”category tag” causing HTML5 validation errors), but someone beat me to it and patched it in already. I tested the patch and am moving on to some other issues that I’d like to assist with. Overall, it just makes me feel good.
If you know how to write code and love WordPress like I do, why don’t you jump on it and help in the development process? You just might end up getting your name in the Credits page on everyone’s dashboard!