Fixing Bugs

A great way to contribute to the development of WordPress is to help patch bugs. Having a good working knowledge of PHP, JavaScript, or CSS is recommended.

First, if you have found a bug in WordPress, please make sure you report it. Please search Trac first to see if the bug has already been reported before creating a new ticket.

Once you’ve either found an existing Trac ticket or created a new ticket for the bug, you can get to work.

If you want to help, but don’t know which bugs to fix, review the Finding Bugs to Fix section below.

Overview #Overview

WordPress uses Subversion for source control. You will want to check out a working copy of WordPress using a Subversion client (such as Tortoise SVN on Windows, using the command line on Mac and Linux). For more, read the Subversion article.

One of the many benefits to using a version control system is that you can create a simple text file, called a patch, that shows exactly what you’ve changed – the lines of code you added, modified, and removed. A patch is also called a diff, for differences.

If you are not familiar with how WordPress is written and organized, read the article on the WordPress Codebase.

Once you’ve figured out how to fix the bug by modifying WordPress core files, you should create a patch. Review the Creating a Patch documentation.

Once you’ve created a patch, upload it to the Trac ticket using the Attach file button, and add has-patch to the workflow keywords. Please don’t overwrite any existing, previous patches.

Top ↑

Finding Bugs to Fix #Finding Bugs to Fix

If you want to fix bugs in the core parts of WordPress, but don’t know what to fix, here are some suggestions on finding one:

• Try starting with tickets that have been tagged with the ‘good-first-bug’ keyword. They’re great for getting familiar with the process before attempting to solve more complicated problems.
• Look through the ticket report for the latest release, in particular the Needs Patch group.
• Look through the ticket report for “early” tickets. These tickets have been marked by contributing developers as needing attention early in the WordPress release cycle. Generally, this means a trusted core contributor has shown interest in it, “blessing” the ticket to a certain extent.
• Look through the Awaiting Review report. These tickets have not yet been slated for the next release of WordPress, but if a developer takes an interest in it, that can change.
• There are individual reports of tickets for a number of specialized areas: you may be interested in writing unit tests (see Automated Testing), working on or providing feedback for user interfaces and user experiences, tickets of interest to the mobile development team, and tickets requiring more documentation in the Codex.
• If you are interested in tickets from a particular component, you can use the Query feature of Trac. For example, all open XML-RPC tickets, all open Multisite tickets grouped by milestones, and all open Accessibility tickets.
• The WordPress development team has daily discussions on bug triage, and weekly project meetings. For dates and times, see the sidebar on Make WordPress Core.
• Consider joining the wp-trac mailing list to follow the discussions in every Trac ticket. Also follow along on Make WordPress Core, and potentially other Make WordPress blogs.