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? 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!

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!

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.

Is consensus building on the right solution? Just because discussion is still ongoing about what the right solution might be doesn’t necessarily mean that it is the wrong time to offer up a patch.  Often a patch can be the best way to express the technicalities of your suggestion and to allow people to try your ideas out.  If you can figure a popular direction or consensus that is building it is well worth the time to work on a patch.  The availability of a coded solution can be enough to sway a discussion in a particular direction.

Is the ticket patch less? Check to see if someone has already submitted a patch on the ticket.  If they have and the patch works for your please change the keywords from needs-patch to has-patch and leave a comment about what testing you did.

Was the needs-patch keyword added / re-added after the latest patch was submitted? This generally means that someone has reviewed the patch and it needs some improvements before it is ready to be committed to the core.  Usually they will leave a comment describing the issues with the patch so you should know what needs to be addressed.

Is there feedback on the ticket as to improvements that can be made to the patch or test cases which fail when the patch is applied? If so you could work to merge this feedback and improve the patch.  Just because you are not the original patch author does not mean that you should not get involved.  In fact it is great for many people to be involved in the patch development and testing process as that means it is much more likely that any edge-case bugs will be found.

Does the patch still apply? If there is a patch on the ticket can it still be applied to the latest trunk code and fix the issue(s) described in the ticket.  Over time patches become stale as the code that was patched changes for other reasons.  If the patch no longer applies you could update it so that it does and check that the bug(s) are still fixed.

If you are still not sure after playing out all these questions in your head then the best next step is to ask someone.  In general there is usually a few of the core contributors hanging out in the development IRC channel #wordpress-dev on the FreeNode network.  If you ask them about a ticket or for feedback on a patch they will be able to help you.

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

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.

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.