Contributing to WordPress Core for Absolute Beginners

Comments and Submissions to WordPress issue ticket 27888 (https://core.trac.wordpress.org/ticket/27888)
Standard

At my company Make Do we only develop websites and applications with WordPress. However I have never made a submission to WordPress Core, that is, until today. This blog post details my first experience of contributing to WordPress Core, and hopefully it will provide a little help for any other budding contributors.

Don’t get me wrong, at Make Do we give back to the WordPress community in many ways already. We do this in the following ways:

…and now through WordPress core contributions!

Where to Start

The WordPress.org website has a fantastic section for contributors, the section I was looking for in particular was the Make WordPress Core area of the website. It was here that I found the Core Contributors Handbook, which gives a great guide on how to get started.

WordPress Development Environment

One of the first things that you need to do is configure a local WordPress environment. I referred directly to the handbook for advice on how to do this, and in particular, the section on installing VVV (Varying Vagrant Variants). The VVV GitHub repository also has a great guide to help you get started.

At Make Do we already use VVV for most of our projects. I actually wrote a handy blog post about getting started with Vagrant, some time ago, but I recomend you ignore that and stick to VVV.

You can choose whichever local development method you like, however VVV handily already pulls down the “WordPress Trunk” SVN (Subversion) repository for you, which is what you need to start contributing, so the rest of this guide will assume you are using Vagrant and VVV.

Finding a WordPress Issue

The WordPress Core team are great for newbies (n00bs) like me. On the Make WordPress Core site they handily link to a section of Trac (their issue management system) with tickets marked as Good First Bugs. As this was my first time contributing, what better place to start?

Make WordPress Core - Good First Bugs Page

The Make WordPress Core – Good First Bugs Page, with the bug that I was about to work on selected.

Choosing an Issue

So lets have a look what tickets were on the ‘Good First Bugs’ list today:

Preparing to Code

I needed the latest version of WordPress trunk from SVN in order to develop my patch. To make sure I got this, I simply ran the following commands in the terminal.

I was prompted for my password, but this is essentially it! Lets step through those commands:

  1. Change directory (cd) to the path of my wordpress-trunk installation (this comes with VVV)
  2. Start Vagrant and provision it. This will automatically pull down the latest version of WordPress trunk from SVN

Simple right? All we need to do now is open up the wordpress-trunk directory in our favourite editor (I’m using Atom these days).

Writing the Code

First up I wanted to address the requested get_current_admin_url() function. The ticket had some suggested code, however I thought the proposed solution was a bit long winded as the same result could be achieved in less code by simply querying the query string using PHPs built in ‘$_SERVER[‘QUERY_STRING’]’ variable. Here is the code I wrote:

Where to put the Code?

Handily, Pascal Birchler (a WordPress Core contributor) had already commented on the ticket with the suggestion that it should be placed inside wp-admin/includes/misc.php. So I added my code to the bottom of that file.

Making the Patch

Making a patch is simple if you have been using VVV, although you do need to SSH into your VVV environment to do it. Doing that is as simple as writing the following code into your terminal:

Once you have done that you should see something a little like the following image:

Entering the vagrant environment using SSH

Entering the vagrant environment using SSH

Now that you are inside your Vagrant environment you need to navigate to the wordpress-trunk directory, and then create your patch. As the ticket number for this patch is 27888, the name of the patch should reflect this. To create the patch you need to enter the following commands into your terminal:

The first line just changes the directory to wordpress-trunk in your Vagrant instance.

The second line is a command to make an SVN diff file. This will create the file 27888.diff in the root of your wordpress-trunk directory. This file contains all the differences between the latest version of wordpress-trunk in the SVN repository, and the changes you have made. This is our patch.

The beauty of VVV is that you now also have this file on your host machine in the same directory, so you can exit Vagrant now by entering the following command into your terminal:

Submitting the Patch

To submit the patch go back to the ticket page (in this case ticket #27888), and if you haven’t already, login.

At the top of the page, under the initial ticket information, you will find a button called “Attach file”. Click this, upload the diff (the patch) and enter a comment. You will end up creating a comment that looks something like this:

Updating the Patch

You may have spotted that this patch only contains one of the two requested functions on this ticket, so I jumped back into the wp-admin/includes/misc.php file, and added in the code to make the get_current_admin_hook() function.

I then repeated patch creation and submit process. As I was updating the same patch, I simply appended a number to the end of the diff file to indicate that it had been updated, creating the file 27888.2.diff.

Updating the Ticket

I now needed to update the ticket to show that a patch had been applied. At the bottom of the screen there is a comment section, along with some options to modify the ticket. It looks a little something like this:

Adding a comment and modifying a ticket

Adding a comment and modifying a ticket

After filling this form in, the following comment was left on the ticket:

What Next?

For now, we wait. The patches need testing, and in my experience its a good idea to let somebody else test your work (also writing WordPress Unit tests will be the subject of a future blog post). Finally the patch will need approving and possibly submitting into WordPress core by one of those lovely core contributors that have the power to do so.

“But it might not get in. I don’t think I could take the pressure!”  — I hear you cry.

For the most part, I don’t care if it gets into core or not, or even if my work gets rejected. Why? Because I did this to learn, and any feedback gained, negative or positive, will aid that learning.

I promise to keep you updated with what happens to my contribution, either as part of this post, or it might even be worthy of a story of its own!

In the meantime I plan to write more patches. These may get accepted (or not), and if I come across any really really good ones, I’ll let you know.

Matt Watson

Technical Lead at Make Do
Matt Watson is the co-founder and technical lead of WordPress agency Make Do. Matt loves writing and learning about code, and considers himself lucky to be doing what he loves for a living. Find out more about Matt, or get in touch to hire Matt for your project.

Leave a Reply