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.