My first ever contribution to WordPress was trimming whitespace from keys stored in the WordPress options table.
Basically, I removed a space.
But since then, I’ve contributed quite a few other patches to the project I love. Eleven of them have actually made it in to the core codebase!
At the Portland WordPress User Group meetup a few weeks ago, I gave a 5-minute presentation explaining how everyone could get involved with WordPress; both developers and non-developers. Still, people ask all the time how they can see their changes reflecting in WordPress core.
So here’s an example of how a recent contribution I wrote made its way into the yet-to-be-released WordPress 3.4.
The Idea
I am on just about every social networking site possible. Each site adds its own features, and one I really love on Google+ is the ability to scroll back to the top of the page by clicking an empty spot on their top-level toolbar.
I love this feature so much, I find myself clicking on every top-level toolbar in the vain hope that someone has knocked off Google’s code. Unfortunately, this usually leads to nothing more than a few seconds of confusion before I manually scroll to the top.
With WordPress 3.4, though, I was told that the “admin bar” was being converted to a more generic “toolbar.” It no longer represents just administrative functions, but can be wholly integrated into the theme to present a better customer experience.
This announcement came with a tweet from a friend suggesting we roll our own version of Google’s scroll-to-top feature.
I was hooked.
The Ticket
I spent my lunch break reading through the JavaScript in WordPress that controls the toolbar. Apparently it loads two sets of functions—one that uses jQuery and one that doesn’t.
Build a jQuery scroll-to-top feature was easy. That change amounted to a whopping single line of code:
$('html, body').animate({ scrollTop: 0 }, 'fast');
I generally try to avoid jQuery dependency in my client projects, though, so building out a version that worked in the absence of jQuery was vital. Sure, the jQuery version works fine on the administrative side of WordPress, but for the toolbar to be a front-end tool as well, I needed to port the feature there.
My lunch break work evolved into some after-dinner work as I took a look at some stock “scroll to top” scripts I found on Google and some scrolling features I’d built out for past client projects. Eventually, I had a working script, so I created a new ticket on Trac to host my work:
Google+ introduced a fantastic feature with their toolbar. If you’re scrolled far down a page, clicking any non-link in the toolbar automatically scrolls back to the top of the page.
When viewing a very long WordPress front-end (or a long list of comments/large settings page on the WordPress back-end), this would be a fantastic tool. It’s also better to have a consistent UX control built in to the system rather than the various spin-your-own hacks different developers have built over the years.
I propose we add this “back to top” functionality to the WordPress toolbar. It should necessarily work with or without jQuery (in situations where themes don’t enqueue jQuery on the front-end but still display the toolbar).
It didn’t take long for some others to test my code and verify that it did work as advertised. After a day or so, though, someone pointed out that my cursory Trac search failed to pull up an even older ticket requesting the same feature. So my ticket was closed as a duplicate and I made my way over to the original post.
The Patch Process
After transporting my initial patch to the right Trac ticket, I asked the community for some additional feedback.
The first feedback, ironically, was my own. I tried cleaning up some of the stylistic elements of my code (I’m a stickler for elegant code structures) and hit a snag with some single-line logic statements. I fixed my patch and submitted a new copy.
Then Daryl Koopersmith took a look and cleaned up my code a bit more. His code was definitely cleaner, but didn’t seem to work on some older versions of IE due to an inconsistency with those versions’ implementation of JavaScript.
I took another look (since I debug IE issues daily) and found the particular elements that needed fallbacks for the older browsers. A few quick changes took us to a third version of the patch.
While I was making these changes, though, someone proposed the idea of just loading jQuery on the front end of the site by default. I’m very much opposed to this, and made that clear in the comments, but the discussion continued beyond just the ticket. Most of the WP team is fairly active on Twitter and in IRC as well, so we hash out debates in multiple locations.
The final patch came from Andrew Ozz. It was nearly identical to my last patch, except it removed some redundant logic checks. Sometimes it’s just not necessary to verify that [cci]true === true[/cci].
A New Feature
After this final patch, now that the feature had been properly reviewed by the community and tested independently in multiple browsers, it was committed to Core. Andrew Ozz tagged the commit with “props ericmann” to give me credit, and my name will be forever inscribed in the list of WordPress contributors.
Today, you can click an empty spot on the toolbar of all my sites to scroll to the top of the page (I’m running 3.4-beta everywhere). You can also use this feature on WordPress.com as they run several pre-release features on their network, too.
How You Can Get Involved
So how do you get involved with WordPress core development? It’s an easy, X-step process:
- Decide what you want to change. You might have found a bug in WP, there might be a feature you want added, or you might find an unpatched ticket on Trac that appeals to you. If there isn’t a Trac ticket for the bug/feature already, create one.
- Check out WordPress via Subversion. You’ll need a local copy of the WordPress codebase to make changes. Check out a fresh copy of WordPress trunk so you’re up-to-date with the latest changes.
- Make your changes. Then, using Subversion, export a patch that shows what you’ve changed. Upload this patch file to the Trac ticket you made the changes for.
- Engage the community. Take some time to talk about your change on Twitter, in IRC, on your blog, etc. If the community doesn’t know you’re making changes, the changes will never happen. Be sure to explain why you think the change is important or valuable, and be ready to collaborate with other developers to make it happen.
Disclaimers
Not every patch you submit to Trac will make it in to WordPress core. Some changes affect too narrow an audience to belong in the core codebase. If someone claims “that’s plugin territory” it’s because they think the number of users will benefit is just too small to warrant rolling your change in with the core project.
Don’t take this personally.
You can always write a plugin that extends the same functionality. Use the plugin to prove your code and try to convince the community that your changes belong in core. If you’re persistent, you will be heard. Just don’t overdo it.
Also, keep in mind that the WordPress community operates as a meritocracy – those who have contributed the most are listened to the most. If you’re new to the project, it might take some time for you to earn your place at the table. Keep writing good code and contributing in meaningful ways to the project and your voice will be heard.
