Commit: The Story of Writing a WordPress Patch

Hanging out in the #WordPress irc channel or on the wp-hackers mailing list, a question that comes up from time to time is “How do I get a bug patched”. I recently had a patch committed, so I thought I would detail the process from start to finish to help others get an idea of the process. I can’t guarantee that others will have the same experience, or that even I will have the same experience next time, but this was how I had my first substantial patch committed to WordPress.

The process for me started by seeing a post by Jane Wells talking about a few UX enhancements she wanted to see handled during the recent patch sprint. One that I noticed hadn’t received any attention was Showing the status of an admin attempts an e-mail change under the new multisite configuration. I took a quick look at the relevent code and figured this was something I could patch.

Lesson 1: Make it easy for coders and non-coders to see the change

After I wrote my first iteration of a patch, I hopped into #wordpress-dev and Andrew Nacin recommended that I add a screenshot to make it easier for Jane to see the change.  I couldn’t agree more that this was a great idea. After all, why should you need to apply my patch & test it, or understand the code behind it just to comment on it.

Lesson 2: Just because you write the patch, doesn’t mean others don’t have good ideas for it

I then waited till I was in #wordpress-dev at the same time as Jane and brought up the ticket. This led to a conversation between Jeremy Clarke, jane and myself about the best way to let users know. During this time I went thought a few other iterations and shared those on the ticket. We didn’t come to a firm conclusion, and the next morning Nacin commented with a suggestion on the ticket.

Lesson 3: Sometimes one small change leads to another

The next day I once again headed to #wordpress-dev where Jane, Nacin, and I took another stab at it and decided that an inline warning box would give the proper notification without being distracting. While writing the final version of the patch I noticed that all warning boxes automatically moved to the top of the screen. Nacin took ownership of fixing this, made a few minor changes to my patch and committed changeset #13446.  Now not only will users be able to see pending admin e-mail changes, but developers can use the existing UI warnings inline.

Overall, the process to fix this UX bug took four people and multiple iterations.  I want to thank all three others for assisting me. While there are times that errors make it into the released version of WordPress, I hope this story gives you the idea of the effort that the core development team takes to make sure only the highest quality code and user experience for users.

Published by

Aaron Jorbin

Polyhistoric man of the web. Currently Technical Architect on the Conde Nast Platform Team and a WordPress Core Committer, he works to improve developer happiness and is dedicated to making the internet usable and enjoyable by everyone. He's probably wearing a bow tie right now.

5 thoughts on “Commit: The Story of Writing a WordPress Patch”

  1. I think the environment has changed in the past two years. When I started, the process was the same, but the details were not known. Just putting a patch on Trac did not mean it would be known and committed. Still, that has not changed, except that there are perhaps a bit more people with independent thought looking at patches now than before.

    I’m quite happy that there is better feedback and greater back and forth. It makes for better patches when there is discussion.

    Well, whereas it took you less than an hour to realize that, it took me several weeks and then the back and forth took several more weeks. It wasn’t the best of experiences to say the least. However, it gives a better perspective when things change for the better.

    1. I think the biggest improvement has come very recently with the expansion of the number of developers with commit access. I hope my experience is one that more people have.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>