My First Patch: Scott Reilly – coffee2code

Here is the next in the series of posts about your first patch and the experience of getting involved. I now hand you over to Scott “coffee2code” Reilly to talk about his first patch:

WordPress was already a quite capable blogging platform when I first got involved with it over six years ago. However, it wasn’t without significant issues. But unlike during my years using Movable Type, I was compelled to pitch in and help fix those issues. Maybe it was the active and friendly community. Maybe it was the palpable potential. Whatever the reason, from day one I’ve always felt the responsibility to contribute to and improve the project.

What specifically sparked my involvement with WordPress development were a number of formatting bugs. Turns out I wasn’t the only one experiencing these issues. After closer inspection and testing, I identified and provided examples of six bugs related to tag balancing:

• User text gets irretrievably deleted
• Insertion of non-sensical </> “tag”
• Tags not getting balanced in certain situations (particularly when following an HTML comment)
• Improper balancing of unclosed tags
• Insertion of a close tag for <input />, which is a single-entity tag
• Unclosed single-entity tags do not get closed

The most egregious being of course the possibility for WordPress to lose user content. The other issues resulted in broken tag semantics and validation, as well as often causing browser rendering issues for pages.

The culprit for all the issues listed above was balanceTags() (now called force_balance_tags()). Since that bit of code can seem a bit hairy at first glance and requires some close analysis to understand what it’s doing and how it’s doing it, I decided to make a blog post to explain the changes I made.

The patch was officially applied by Matt to trunk about five months later, on January 6, 2005, in time for WordPress 1.5.

Oddly enough, I just recently found myself again contributing a patch that involved modification of force_balance_tags().

I’m pleased to have been a part of WordPress for so long and to have contributed directly to core or indirectly via plugins. Most of all I’m pleased to have seen WordPress grow and help so many people in so many ways.

Note: My first patch applied to core was actually for #113, applied in [1519] by Ryan on August 8, 2004.

Editors Note: Please let me know if you would like to share your experiences writing your first patch for the core of WordPress.

How do I report documentation bugs for WordPress?

Lee asks:

How do I report documentation bugs for WordPress? Just through trac?

The answer to this depends on what documentation you have found a bug in.

If the error is in the codex documentation anyone with a WordPress.org login can edit the codex and correct the error themselves.

If the error is in the inline documentation in the source code then the best place to report this is a new ticket in trac setting the component to “Inline Docs”.

Finally, if the error is in the documentation in the rest of the WordPress.org website then again the best place to report the issue is in trac this time setting the component to “WordPress.org”.

Do you have a question about contributing to WordPress if so please ask!

What version of WordPress do you use to create a patch file?

Jonny asks:

I am really eager to start contributing to the core, but have only submitted one ticket so far (for which a patch was kindly created for me!).

I know it sounds silly, but I do have one question – what version of WordPress do you create a patch/diff file using? I am connected to the WordPress SVN repository at core.svn.wordpress.org – is it the version in ‘trunk’? Just want to make sure I get it right to save anyone having to do this for me again, thanks!

In most cases the version of WordPress you want to create a patch against would be the version in trunk. The only reason for not using trunk is if the issue is severe enough that it needs to be fixed in a point release.

At any time there are usually two active development streams within the WordPress subversion repository.  The first of these is the development for the next major release which will occur in the trunk version.  The second of these is the development of the next minor or point release which will occur in the relevant branch.  For example at the moment we have branches/3.0/ which is where development for the next 3.0.x release occurs.

Do you have a question about contributing to WordPress if so please ask!

When does a ticket really need a patch?

Welcome to the first question and answer post on “Patches Welcome”.  If you have a question about contributing to WordPress please ask!

Tim asks:

I’m wondering how best to tell when a Trac ticket really needs a patch. Sometimes it seems like a ticket has the “needs-patch” tag, but is still being discussed. How can a newcomer best tell when to jump in and produce code?

I agree that for a newcomer it can be difficult to decide if a ticket really still needs a patch.  Here is the list of questions I would go through in my head when looking at a ticket to decide if it is ready for or still needs a patch, some are obvious some not so obvious.

My First Patch: Peter Westwood – westi

Welcome to the first in a series of posts reflecting on the experiences around the first patch that a contributor wrote or had committed to the WordPress core. I thought I would start the ball rolling with myself and I hope to draw some other people in for future posts in this series.

I can just about remember what drove me to get involved and write one of my first patches for the core of WordPress just over 5 years ago.  I had run WordPress for about a year and a half and started to get a little obsessed with the number of database queries that were required to produce the front page of the site as they were slowing it down. It seemed to me that there were an a lot more queries that should be needed to output a list of 5 posts and the meta data associated with them.

It turned out, when I dug into what the queries were for, that most of them were related to the different options that were added by all the plugins I had loaded my site up with.  I found that there was a subtle performance issue in the way most plugins used add_option() and update_option().  Basically every time a plugin called add_option() WordPress would check to see if the option already existed and only add if it didn’t.  This seemed sensible except that for every option that was marked for “auto loading”. For these WordPress already knew they existed as it caches all the “auto load” options with a single query early on.

As can be seen from the ticket it took a little while before Ryan had time to review and commit the patch – It also turns out fellow lead developer Mark also had a hand in updating the patch when it went stale.

It really great to look back and reflect on “my first patch”. I had a great experience at the time. It was really nice to have a friendly community which nurtured me as I developed in my knowledge of WordPress and contributing to an open-source project.

Please let me know if you would like to share your experiences writing your first patch for the core of WordPress.

Introduction

Welcome to “Patches Welcome”, I hope to make this site a friendly centralised place to curate and link content on how to contribute to the WordPress family of open source projects and also make it easy for new contributors to connect with mentors and find tutorials.

Over time I hope to interview as many as possible of the current and future contributors and collect stories about what experiences they have had while contributing to WordPress as well as to get people to reminisce about their first patch.

I also intend to answer as many questions about how to contribute as possible and have set-up and open contact form to allow people to ask their questions and I aim to post at least one new question and answer pair per week.