 Hello, everybody. And welcome to my talk today on the ultimate WordPress development environment. My name, like Tako said, is Matt Jerry, and I hail from sunny South Africa, down in Cape Town. And I've got the best job in the world. I get to wake up every single day, sit in my underpants, and work on WordPress. I am a remote WordPress engineer for a company called XWP, and we mainly do enterprise-level WordPress projects. Since Google knows a lot more about me than I know about myself, you can just Google me. Matt Jerry, the first result is going to be my website, MattJerry.com, where I do weekly WordPress development tutorials and articles, as well as videos that teach you various different things around WordPress developments. So I wanted to start out my presentation today by asking the question, why? Why should you pay attention to my talk today? And why should you care about setting up a development environment that suits your needs? And it's quite simple. There's three reasons. The first reason is to write more code in less time. So if you've got a WordPress development environment that's tailored to your needs, you're going to be able to write more code with less keystrokes. Then the second reason would be to reduce the amounts of bugs in your code. Who here in the audience today has ever pushed a piece of code to production, and it's broken something? I have two, and I've done it multiple different times. So with the right development environment, you can eliminate doing that. And then the third reason is to implement code in standards strictly. If you're working on open source software, or if you're working as a team on a project, you want to implement code in standards so that the code is more maintainable. So what is the ultimate WordPress development environment? When I joined XWP at the end of last year, I went on a quest to figure out what it was, and I narrowed it down to five core key component areas. And that is, you need a local server to serve the WordPress files. You need an IDE and a text editor to actually write code. You need to be able to check your code that it is following standards. Like I said, code and standards are very important. And you need to be able to debug your code. So when you're testing it in your browser and your local environment, you need to be able to debug the code if something's gone wrong and figure out what's going wrong. And then the fifth component is deployment. You need to get that code from your local machine onto your live environment. Now, the tools that I'm going to be talking about today are my personal recommendations. They're not necessarily the tools that you currently use or are going to use, but it's a good starting point for setting up your development environment. Sorry. So starting off with the local server, I've split this into two different groups. There's required items that you definitely need in your environment, and then there's a second set of tools that I just recommend. The first item that you need is obviously a web server. You need to be able to serve WordPress files. You need a database server to host the WordPress database. And it's usually a MySQL database. And you obviously need the WordPress files on that server. My two recommendations that you include as well is version control, so something like SVN and Git, and then a tool called WPCLI, which I'll get to in a moment. So traditionally, there's been multiple different ways to set up a server on your development environment. Some of you may notice what these logos are. It's MAMP and ZAMP. It's a very popular way to host a server on your computer. And some people just go ahead, and they're brave, and they install Apache directly on their machine. What I'm going to recommend today is that you scrap that and you virtualize your environment. So virtualization as a quick explanation and the way that I like to think of it is it's a computer within a computer. So what we're talking about here is having your computer and a server within that environment. So why would you want to virtualize? Well, again, three reasons. There's no manual installation required. You don't have to go onto a server, download software, and install it one by one. You actually write a script and use that script to create the environment over and over again. The second reason is that it's portable. This development environment can be used on a Macintosh. It can be used, I don't know what he's saying. What he said. So it's portable. You can take that environment and you can run it on a Macintosh. You can run it on an Ubuntu server, on an Ubuntu desktop installation. You can run it on Windows. And all your developers can have the same environment. And then you can closely replicate production. So the software that you use it in production to host your web servers, even if you're using a Macintosh on your local host, you can run the same software. So you can test against the same environments. My personal recommendation is VVV. It's a full solution. It's got Nginx on it, MySQL. It's got all the WordPress repositories on it. It does have its issues. You'll hear it when people mention VVV. It's got a bit of a bad reputation about a slow provisioning process. So provision is taking the script, running it, and creating the development environment. The one thing I would say about it on the flip side of that is it's never failed me. It's always worked, and it's got everything that I need. It has also become somewhat of an industry standard. So you'll find a lot of core developers using VVV for their development, and a lot of agency workers using it as well for their WordPress development. The alternatives to VVV, you've got Wacker, which is based on a Docker infrastructure. You've got WP Libbox, Vagrant Press, HDV, and a whole bunch more. So what does VVV look like? Unfortunately, if you're looking for a nice, pretty interface, you're not going to get it with VVV. It is a command line interface. So learning the command line is not difficult. You can probably spend about 30 minutes getting familiar with how to navigate file structures in command line, and that's most of what you need apart from just running some commands. So in my screenshot here, you can see I've got a terminal window open on my Macintosh. I've run a command called vagrant SSH, which has taken me onto the box, which is an Ubuntu server on my local development environment. From the front end, so if I go to VVV.dev in my Chrome browser, you'll see you have a present with a whole bunch of tools. You've got PHP My Admin, you've got Webgrind for profiling, you've got your PHP Info page, and then most importantly, you have your WordPress installations. The two most important ones there is WordPress Stable, which is a stable release of WordPress, and WordPress Trunk, and that's what you would be doing your WordPress development on. Before we finish off on the first component, we are going to talk about command line WordPress. This is one of my favorite tools since I enjoy the command line, and this is WPCLI. It's a super useful piece of software that allows you to manage your WordPress installation directly from the command line, so you don't have to go to 4-wp-admin to create a user, to create a post. You can do it in one single command on the command line. Here's an example. I've run... I've changed... I've gone on to my VVV box, changed directory to WordPress defaults, which is where the WordPress files reside, and I've just typed WP, user, create mat, mat, mat.jerry.com. I've set myself to an author, and it's created that in WordPress, so that user now exists in WordPress. So we onto our second component, which is the IDE or text editor. That is not a Photoshop logo. That is PHPStorm. Now, I was never a big fan of IDEs. I had the same objections to most people, they're slow, they bloated, until I tried out PHPStorm. I highly recommend that you give it a try yourself. It has got everything in one place. It's got version control, it's got database, it's got FTP, SCB, it's got debugging, everything that you need for WordPress and PHP development. So I wanted to walk you through some of the features. It knows WordPress deeply. It's... If you start, for instance, typing out actions, if you add action, it'll autocomplete actions for you. It'll do the same for WordPress functions. You can start typing out a function, it'll tell you what functions you're potentially trying to use, and let you know the arguments that you need to pass into that function. It's really great. And the other additional feature is that you can start... You can shift-click on a WordPress function, and it'll take you to that place in WordPress Core to see how the function is defined. Then it's got a built-in terminal, which is just a standard UNIX terminal. You access it from the bottom bar, and you can have multiple different tabs as well. It's got built-in source control, so it supports SVN and Git. It's got a visual diff, so you can see a nice visual overview of the changes that you've made compared to what's committed to the repository. It's got a blame feature, which they call annotations, so you can see who created a piece of line of code and when they did it. It has got a really good visual merge tool to merge code if there's a conflict, change list, and the killer feature, the number one killer feature of PHP Storm, the version control, source control feature is the GitHub integration. So you can create a pull request directly from the IDE. You don't have to go to github.com, you can just go click a single button and create a pull request. Then it's got MySQL admin, so you no longer need PHP MyAdmin. It's got full database control. You can manipulate the schema, change a table name, a column name. You can just double click any cell to edit the data, so you've got data manipulation. You can export data, do custom queries, and pretty much anything you can do with PHP MyAdmin, you can do directly from your IDE. Again, it's got one of my favorite features is built in testing. So you can run all your unit tests from within the IDE, and when a unit test fails like this one did here, it gives you a clickable link that'll take you directly to that piece of code where the unit test fails and you can fix it directly there. It has also got great code coverage features, so you can run your unit test with code coverage. It'll tell you how much of your code has been covered by unit tests, how much has not, and it'll also highlight the code that hasn't and the code that has been tested. Lastly, it's got built in snippets. So in this example, you can see I typed out pubf to define a method in a class, and it's done all the scaffolding work for me. You can do custom snippets, and it's got emits integration as well, so you can do really good HTML and CSS work using emits. There is so much more, it's got smart refactoring, so if you right-click a file and change it, it'll find all the references of that file and update those references. It's got vagrant support, composer support, syntax linting, and so much more. So we're onto the third component here, which is code checking. We want to be able to make sure that when we commit in code that it follows standards, and it is secure. So there's two tools that I use for this. It's PHP code sniffer, and on top of that is PHP coding standards, which is basically a list of rules for PHP code sniffer. Who here in the audience feels that this code is insecure? So there's a funny story about this piece of code when I was a young developer working on mobile press. I actually committed this exact line of code to the plugin and quickly, quickly learned my lesson from the WordPress community that I'd made a big mistake. So I rolled that back, but the point of the story is that if I was using PHP CS and WordPress coding standards, this insecure code would never have gone to production because it would have warned me about it. So what PHP CS and WP code standards does is it warns you about potential security issues and additionally makes sure that you follow in the WordPress coding standards. So you've got your spaces in the right places, you're using tabs for indentation, et cetera. Here's a quick example with inside PHP storm of a report that I've run on WordPress coding standards. It's telling me about a sanitization issue. It's telling me I'm missing some doc blocks and it's telling me that I've got code style issues. The fourth component that we're gonna talk about is debugging. So they've got an awful logo, but X debug is the de facto standard in debugging PHP code. It is mostly like traditionally being used for stack traces, so when you get an error in your application, you can at least see the path that the application took to find that error, and then profiling as well to tell where's the bottlenecks in your application. But there's a little known feature of X debug which allows you to do breakpoint debugging. So is anybody here using prints R or var dump when you're looking for an error in your application or you wanna profile your application? Nobody? You're all using breakpoint debugging. It is an honest guy. So if you're using prints R or var dump, make sure you switch over to breakpoint debugging. I'm gonna give you an example now of how cool it is. X debug ships with VVV, so you just got a SSH into your VVV installation and type xdebug underscore on, and it will enable Xdebug, and PHP storm has excellent support for Xdebug like I'm going to show you right now. So what I've done is I've got a piece of code here, and I want to, when I run my application, I want it to stop at this line of code 223 and tell me all the details of the application at that point of time. By the way, this doesn't just work with PHP storm. There's an Atom plugin and a Sublime text plugin as well if you want to debug using those text editors. So what I've done is I've set my breakpoints. I've got into a browser. The most important piece on this slide here is the JetBrains plugin that I've got installed. There's a Chrome extension, which lets PHP storm know when there is a breakpoint and it'll switch me over to the IDE. So in the IDE, I've got to the point now where we've reached the line of code, the application's been running, it's not going to continue executing, it's paused at that point of time, and I can start expecting the variables. I can see what's in the get variable, I can see what's globals are set. If I've got any custom variables are set, I can check them as well, and you can run expressions against your code. So I can, at this point, if I've got an array, I can check, I can run accounts on that array and see how many items are in the array using an expression. Then you've got your standard debugging step in, over, out, et cetera. So then, the last component that we're going to talk about is deployment. There's traditionally been three different ways that I've deployed code from my local development environment to a remote environment, and that has been vanilla git, so I would go SSH into my server, clone a repo, and every time I make a change, SSH again in and then pull the changes. Then something I've discovered recently is WP pusher, which I'm going to give you an example of in a moment, and the last way to deploy code is using a full build system, something like Travis CI, where it does a build, runs your test, checks your code, and assuming everything passes, pushes a code into your production environment. So WP pusher. If you haven't done any continuous integration before continuous development, this is a good way to get started. It is an excellent plugin and it makes it a breeze to deploy plugins and themes from your local development environment, from a git repository to your live environment. It supports GitHub, Bitbucket, and GitLab. The guy who created it is in the audience today, so you should hook up with him. His name is Peter, and this is just a quick example. So what I've done here is I've got my theme on my GitHub profile, and I've linked WP pusher to that theme, and I've set an option to say push to deploy, which is every time I'm going to push code to that repository, WP pusher is going to recognize that change and pull it into my WordPress installation. So there's my repo, I've connected it to my GitHub. Now, if I didn't want to do that, if I, for instance, just wanted to push code, and then at a certain point of time when I feel I'm ready for my changes to go into production, you can do just a manual update theme. And the same is true for plugins as well. This works for themes and plugins. So a great way to, a great and simple way to deploy your plugins and themes. So just to recap what we talked about today, we said we need a local server that is virtualized. We need an IDE or a text editor that makes us write less keystrokes for more amounts of code. We want to check our code as we write in it. We are going to debug using breakpoint debugging and deploy using something like WP pusher. That's pretty much all I've got for you today. I hope you enjoyed my talk. I have put a URL on this slide, which is matjary.com forward slash WCEU, which has a list of all the resources that I've talked about today, plus some articles that I've written and videos I've recorded that'll show you how to set up these tools. They're at Contribute today. Tomorrow there is going to be a workshop about setting up VVV and they'll help you do that if you're interested in that as well. Anybody got any questions for me?