 Good to go. Before I start proper, I'd like everyone to put their hands together and just give a round of applause to all the organisers and all the volunteers at WordCamp Central. The Industrial Age is defined around the explosion of manufacturing and construction technology in the first half of the 19th century. There were great improvements in construction, in mass transportation, both of people and of goods, and the construction of bridges and tunnels, all of which led to huge time savings and much of which is in use today. And while the Luddites famously protested elements of the Industrial Age, it did contribute substantially to a great improvement in the standard of living. And it's contributing to improving the standard of living that I want to talk to you about today. But I want to do it in the context of our own lifetimes, the Information Age. It's the improved distribution of information through the internet that has led to the most recent improvements in the standard of living. Over the course of this WordCamp, literally thousands of people will download and install WordPress for the very first time, all across the world. Who knows where it's going to lead them? I'm sure it led some of you to unexpected places. It certainly changed my life, and that's why I like contributing code back, and I do this by contributing to WordPress call. And it's important to emphasise the word call in the title of my talk. I'm not talking about contributing to WordPress because there are so many ways of doing this that I couldn't hope to cover all of them at all today. So contributing to call is only a small fraction of the way that you can contribute back. Which begs the question, what do I mean when I say WordPress call? When I talk about call, I'm specifically talking about the code base that powers WordPress. The code that powers the dashboard allows you to select the theme and plug-ins and to write content that will appear in your theme. Since the end of 2014, I've been a regular contributor to WordPress call, although my first contribution was this in 2011. 47 characters. And this is the same contribution as I uploaded it. But I'm really getting way ahead of myself here. I'm getting ahead of myself because when contributing to call, you need to consider that the code will run on one in four websites. And as such, any code that's contributed needs to be considered carefully before being committed. No one really knows for sure how that code will be run. My day job is as a WordPress engineer at Human Made, we build high-end sites using WordPress and we use WordPress in a very specific way. A way suitable for building large sites that will scale for big businesses. I was lucky enough to be invited to be a guest committed for WordPress 4.6 and 4.7. And that's an idea that I like to keep in mind before committing code. I use WordPress in one way. But there are hobbyists, bloggers, small businesses and so many others around the world using WordPress in a different way. And this is why it can sometimes take a little while for a patch to get into a WordPress call. It's a desire to keep those one in four websites running. It's these one in four websites that have led to the WordPress philosophies. The best known aspect of which is to maintain backward compatibility. Let's move towards writing some code. Development of WordPress takes place on the WordPress core track. The track home page looks like this. It's pretty plain. It can be thought of as a code browser with an issue tracker attached. It helps to go exploring to see what's around. So the first stop will be a code browser. The code browser is essentially find at the track. So you've got your modified date, the age of files, all that sort of information that you'd expect from a regular file system. However, as it's hooked up to a version control system, it also includes a summary of the most recent change. The next screen I'll take a look at is the ticket screen. It leads to the various ways of navigating tickets. And there's a lot of ways that tickets can be navigated. But that's because there's a lot of tickets. Over 37,000 tickets have been opened on the WordPress core track since WordPress began. Around 10% of these remain open at the moment. Once you start participating in track, a really handy report is this one. It lists all the open tickets that you've shown an interest in. And once you've been contributing for a little while, it can end up being quite a long report. But that's okay. At any one time, there's quite a lot going on in WordPress core. Another helpful report is to see what will be included in the next major release of WordPress. Early on in the release cycle, it's full of tickets. But as the release approaches, it becomes smaller and smaller. I took this screenshot here. The weekend after WordPress 4.6 released candidate one was released. Which is handy because it means that all the tickets can fit on one screen. Right now at the start of WordPress 4.7's release cycle, we would not be so lucky. Now I understand that the administration of WordPress track is not the most glamorous part of contributing to WordPress core. It's necessary, though, for the reason that I showed you earlier, the high number of sites that are using WordPress. Enough about WordPress core track for the time being. Let's move towards writing some code. Development of WordPress takes place using SVN. So to check it out, you run the same SVN checkout command you would for any other repository. The WordPress SVN repo is at the address on screen. And it's recommended you check it out into a directory called WordPress developer. Enough about WordPress core track for the time being. Let's move towards writing some code. Development of WordPress takes place using Git. So to clone it, you run the same Git clone command you would for any other repository. The WordPress Git repo is at the address on screen. And it's recommended that you clone it into a directory called WordPress developer. That's right. You can contribute to WordPress core using either SVN or Git. For many of us, me included, SVN can feel a little bit like this, while Git is considered the more modern approach. As I can't hope to cover both today, I'm going to focus on Git. Once you've cloned the repository, as we did earlier, you need to set up a web server running on your local machine to run your local copy. And while it's possible to use to run your local web server as a virtual machine, I want to focus on the lowest barrier to entry today. And for me, that means running a basic web server on your computer. There's a lot of options around, but I first started contributing to WordPress core using the free version of Man. To my way of thinking, it's much easier to set up Man, select the preferences, and set the document route to the source directory inside the WordPress developed directory. Having set the source directory, I think set Man to use the default web port for setting up a web server. After that, you can click start and the server is running. I am prepared to accept that running Man, or another web server GUI, is not going to get you an award for the most advanced development environment of the year. However, it will get you to contributing to WordPress core in between 5 and 10 minutes, so I'll take that over any nerd cred that happens to be going around. The final step is to get WordPress running on your local machine. Before setting up WordPress, you need to create a database for your install. Man includes PHP MyAdmin for this purpose, so you create the database in your web browser at the address on screen. Some of you may have used PHP MyAdmin on a hosting provider's service, but for the uninitiated, it's a case of clicking new in the menu on the left and creating a new database and naming it on the right of the screen. You can then install WordPress on your local computer, as you would on a normal website. The install follows the standard practice for installing WordPress. You visit the address of the site, local host, and follow the installation. When it comes time to entering your database details, the database name is the same one you entered earlier, and the databases username and password are both through. On the final screen, you can set up the site details with anything you would like. I usually name it WordPressDevelop and use some ludicrously insecure login details, but it's only running locally, so it doesn't really matter. Now, I happen to think that developing anything without test data is about as useful as a car with flat tyres. So I tend to download the test data from WPtest.io for use on my development install. It's a really nice set of test data, particularly useful when it comes time to testing for edge cases. Once downloaded, the data can be imported using the WordPress importer. So finally, with WordPress installed, a really nice set of test data, we're ready to write some code at last for WordPress. There are two approaches you may want to take for this. You may have a particular enhancement in mind, or you may want to pick up something else that someone else has reported as a bug. It's really up to you. If you're looking for a good first bug, a good spot to start is the aptly titled good first bug report on track. For the demo today, I'm going to create a simple ticket to create an Easter egg on the body class for any posts that are titled WordPress Singapore. And this is the ticket as it would appear in track. So let's get started and work on making a patch. Creating a patch is done on the copy of WordPress that we downloaded and filled with test data a little bit earlier. It's always wise to make sure that WordPress is up to date with the main repo when you start writing a patch. This is done by running get cool in the command line, and once it's finished running, we can ensure that we had WordPress core up to date for writing our patches. My not entirely guilty secret is that I prefer a GUI for some activities in GIG. Again, it's not something that will win you any nerd credibility, but it's a good, but it's good development tools that can help you write the best code possible. So finally, we start writing some code. And it's relatively simple enough. We get the title. If the title happens to be WordCamp Singapore, then we add an Easter egg to the list of classes. But there are some problems with this quote. The first problem becomes obvious when we look at the HTML. The code is an adding one class. It's adding two. And they include characters that are going to make using these classes very difficult. So we can fix that with the built-in WordPress class sanitization function. We've solved the obvious problem, but we still haven't solved the biggest problem. The biggest problem with the code actually relates back to railway in the industrial age. It's a massive problem with implications to this very day. During the industrial age, different engineers designed railways. So let's start by building a railway. First, we'll lay one track. Now, we'll lay another track. Although I'm worried that these tracks are a little close together, maybe I should move the second one out a bit. The trains will be bigger, but they'll be able to carry more goods so we can build less of them. Building a railway without any standards is really hard. So many of you will have guessed what happened. Everyone built railways without considering what happened at the border. For many years, there were border crossings that required passengers to change trains. Fortunately, such foolishness is behind us and we now have standards. These standards are very low, which brings me to the WordPress coding standards. This is what the code that I wrote in the last few years earlier looks like in my text editor. It's really trying to tell me something. You see, I have my text editor linked up to the WordPress coding standards. The WordPress coding standards are designed so that it looks like WordPress call is written by one person. It does this by enforcing the same set of practices they follow. My editor looks like this because there are a few problems with my code. The WordPress call coding standards call for spaces inside brackets inside function calls. So I can remove the errors from the first line by just adding spaces inside all those brackets. But that's had no effects on the warnings for the other lines. That's because there are other problems with those lines against the WordPress coding standards that need fixing. The inline control structure needs to be converted to include braces. WordPress doesn't allow the inline control structures because braces make it harder to introduce a bug down the track. If a second line is added, then the developer down the track, the future developer, can just add their own line of code. However, other problems remain. The WordPress call coding standards prefer single quotes over double quotes. Among other things, double quotes are unnecessary without variables being evaluated. But it also just keeps the code base looking like it was written by one person. Finally, WordPress uses yoda conditions for the if statements. Again, yoda conditions are to help prevent errors. If you miss an equal sign with a yoda condition, your code will throw an error. Without them, you'll happily set the title of every single post to word camp Singapore. You've introduced a bug. As you can see, we've cleared out all the warnings, but there is one slight change that I would make. I'd altered the double equals to be a triple equals. In this instance, we can avoid type chuckling, so it's best to do so. Again, this is all to make the code run consistently and look like it was written by one person. The next step is to upload our change on track. In context, our change looks like this. It sits within the get body class function inside the post template file. When patching call, we can't just upload the file that we want to change. We need to upload the diff, which is just the changes to the file. In the WordPress develop directory, we run the command get diff. It's messy, but it gives us a screen that looks like this. There are a few separate parts to the screen that it's worth looking at. First of all, we can see the file that is being modified. We can see the function that we're making the changes to and the lines of code either side of the changes that we are making. And finally, we can see the code changes that we want to introduce to WordPress call. Looking at the entire diff, I can see that it looks good and is ready for uploading to track for consideration in WordPress call. The next step is to generate the patch file for the purpose. And the command is very similar. Get diff, output to a file, and I put it into a file in my downloads directory. And I follow a common naming convention on track, which is to name the file for the ticket number in question. If there is a clash with an existing file, track will detect it and just add a version number to the file as you upload it. On our ticket, we can upload our file by clicking the attach file button, which you'll see at the bottom of the screenshot there, and then we choose our file and upload it. And by uploading it, we agree to license our code to WordPress foundation for use under the GPL. However, and this is really, really important, one of the most important things about WordPress. You retain the copyright on any code that you write. You are licensing your code to WordPress and to the wider community for use. Uploading a file, unfortunately, though, won't notify anyone. You need to, at a comment, letting people know what you've done. I just tend to summarize the changes that I've made. You also need to add the keyword has patch. Submitting your comment will notify anyone following the ticket of these changes. At this point, your code will be reviewed by a volunteer with a view as to whether or not it should be committed into WordPress code. And if all goes to plan, it will be. When I say it all out, it seems like quite a process, step by step, but it's really quick once you get some practice. And to help you through the process is why the community runs events like contributor days, word camps, like you're here today, and so on. I'll be around for the rest of the day, so if you want to help hand getting started contributing to WordPress call, feel free to tap me on the shoulder. Contributing code allows you to follow one of the fundamental rules of open source. Hack call and contribute the hacks back. You can follow along in the WordPress Slack or the WordPress Slack for the process. But if you don't want to hack call, you can write documentation, either for users or for developers. You can translate WordPress into another language. You can contribute in so many ways. In fact, you're contributing to the community by being here at the word camp today. And for that, I thank you. Thank you very much. And if you have any questions, follow up in my request you raise. Do I ask him? Sorry, how do I start? How did I start? I started doing it on my weekends, which is when I first got involved. I just started doing it as a hobby to just fill in time. I was working in a job that wasn't using WordPress much at the time, and I wanted to keep my hand up with WordPress. So that's when I got involved quite heavily. And that was, as I said, sort of at the end of 2014. And now that I do use WordPress every day at work, I've just sort of kept it up and continued doing so. Anyone else? Anyone else that's too shy to ask a question in a big crowded room but actually does have a question about contributing to WordPress call? As I said, feel free to come and tap me on the shoulder. I'll be sort of hanging around in the hallways and in the building for the rest of the day. And I'd be absolutely delighted to show you and help you get started. And if you want to ping me on Twitter and say, make me near the coffee machine, that's also fine. So you should feel free to do so. Thank you.