 As Brad said, I'm the front-end architect at RP3A Agency in Bethesda, Maryland, that is a truth. And I'm Tope Kat, T-A-U-P-E-C-A-T all over the interwebs and on Twitter as well. So you can follow me there after this. I love to chat online. Now as the front-end architect, not everything that I do is WordPress. I like to do WordPress as much as possible. And when I do, I use tools like Vagrant and Composer, Underscores and SAS and Gulp, and a few other things that we're going to be talking about today. So the first tool that we use is revision control, namely we use Git. At this point I'd like to see a show of hands. Who here uses revision control in their projects? Now I should see every single hand go up. This shouldn't even be a question. Why? Because it's 2015. And I've worked as recently as three and a half years ago for organizations that were not using revision control, and really for a successful team, or even as a freelancer, you need revision control to kind of go back in time. If something happens in your code, you want to be able to go back in time to when things actually worked, and so revision control can help you with that. Also if you're working on a small team, whether there are three people in your office or 15 people spread out all over the world, you need to have a tool like revision control that will help keep all of your developers on the same page. Now there are alternatives to Git, and admittedly Git can be kind of obtuse and hard to break into, and there actually will be a talk in one of the lightning talks later today about getting started with Git. So I would go check that out if you're interested in Git. WordPress itself has had a long history using subversion to manage its core and plug-ins, but even WordPress and some of its associated side projects like Jetpack and underscores and dash icons are also moving to Git. So really the industry standard is Git, and you should probably work on that if you're new to revision control. Now Git is a distributed system, so if you're working by yourself in a place with no Wi-Fi like say your daughter's dance practice and there's no Wi-Fi in the studio, that's happened to me lots of times, then you can work on Git completely independently not have to talk to a server. But eventually if you're working on a team you're going to need a way to share your code amongst the members of your team. So to do that you need a repository service, and kind of the fact of standard these days of course is GitHub, which builds itself as kind of a social network for coders. So that's great for open source projects because it's really easy. You can have as many public repositories as you want to share amongst your friends and the greater world. You can contribute to other projects by submitting pull requests. But if you want to move for client work, private work, while GitHub does have private repositories, I also want to consider there's some other alternatives. Beanstalk is one of those options that we use at RP3. There's also Bitbucket by Atlassian. And if you are an Amazon Web Services shop just this year, they launched their own code commit, which is a Git repository service. So as I said, Git is kind of not something that you learn in a day. It's something you learn over the course of your career. You will learn a few commands really well, really quickly. But then some of the finer points, rebasing things like that, they come over time and I'm still learning them and I've been using this tool for four years now. So I'm going to take a little pause here and give you a security tip. Now, why am I talking about security and why am I talking about it in context of Git? Well, by default WordPress lets administrators edit the PHP files for your themes and for your plugins directly through the WordPress admin. If you're using Git to manage your deployments and your versions for releases, then that opens up administrators who might be your clients to go in and edit code outside the revision control system. You can probably surmise that this is probably not a good thing. And we've actually had clients do this to our code and then email us complaining later that when we pushed out a new revision, their changes went away. Well, don't do that. So we implemented this policy and we do this for all of our sites now. The other reason that this is a security tip is if your clients don't know what they're doing, they can do really bad things to their site. They can open up security holes. If they even miss putting a semicolon in the wrong place, they will get a white screen of death and they will blame you for it. So please put this in your WP config file that functions like PHP file or somewhere in your project, put this line to keep your clients safe from themselves. So moving on, I'm going to talk now about Vagrant, which is a virtualized development environment. What does that mean exactly? Think of it as a computer inside your computer. So if you're doing your development on Mac, you would have a separate computer running in software that would be serving the purposes of your development environment. Why would you want to do this? Well, first of all, you can configure it with code. And anything that you can configure with code, you can store in your revision control system and share amongst your team. So you know that everybody on your team is going to be working with the same development environment that you are. Likewise, you can also have a closer match with your development environment and your production environment. This will help avoid the problems that might arise if you are running a different version of PHP, for example, on your development environment than the production would. Say you're using your Mac and you have Apache, but your production environment uses NGINX, there are configuration differences. So the closer that you get in having your production environment in your development environment, the more you can resonate those potential problems early on in the development process. And also, you can create and destroy your environments at will. So you can spin up a project, work on it for a number of days, weeks, or months, however long the project lasts. And when you're done, you can destroy your development environment, archive the code that you used to create it, and then pull it again later for when you're doing that mythical phase two of the project. However, though, you can vagrant destroy, but you can never vagrant forget. If you're brand new to vagrants, you might want to check out Varying Vagrant Vagrants. This was originally a 10-up project. It's available on GitHub, and it's optimized for doing WordPress development as a vagrant system. The plus side is it has everything you will ever need to develop WordPress in a vagrant that you can get cloned and spin up. The downside is it has everything you would ever need and more. So we don't personally use this for our development projects. It is easy enough to kind of create your own virtual environment and put in what you need. But if you're brand new to vagrant, it does give a good provision file to let you know some of the things that you may not have thought of, like PHP debugging tools or some other things that we're actually going to talk about in a minute. It also has a lot of support in the community, so there's lots of places to go for help. Moving on, we're going to talk about package managers, and I apologize for the small type on this tweet, but basically, Bower, Install, NPM, Install, Brew, Install, Yum, wait, forget which order they go in. There are a lot of different package managers out there, and they all do something slightly different. But really, what are package managers to begin with? They are tools that will let you automate the process of installing, updating, and removing software. So basically, you're taking code from a central repository and applying it to your project. If we build greater websites, it's because we're standing on the shoulders of giants who came before us. We're using things like JQuery and Backbone and SAS and all these other tools, but we have to get them from someplace. Otherwise, it becomes unmanageable. The first package manager that is applicable in the WordPress world is Composer. Composer is the package manager for PHP projects. WordPress is a PHP project, so they fit nicely together. So you can manage your core install, you can also manage your plugins and themes as well, using Composer to update them automatically. NPM is another package manager, and it's Node package manager is what it stands for. And I know all the big news from last week, right, is that WordPress is moving to Node? Well, no, it's not. Calypso is something completely different, and NPM has nothing to do with that itself. Node package manager in this context is more of a means to an end. We're going to use it for our purposes to install more package managers. For example, Bower. Bower is a package manager for front-end libraries. So if you are a big SaaS person, as I am, you might want to use things like Breakpoint or Suzy. Again, libraries that people have worked on and maintained and have wide community support, so you don't have to reinvent a good Breakpoint management system every time you start a project. Font Awesome is another popular library that gets used a lot in WordPress projects. You don't want to have to keep maintaining the latest version of Font Awesome. You can use Bower to keep that updated on your system and your project as you go along. One warning, though. WordPress comes with a lot of great front-end libraries installed. I mentioned jQuery before. It's a great project because jQuery comes with WordPress. Same with Backbone, same with underscore, the JavaScript project I'm referring to there. So there's a lot of great libraries that come with WordPress that you kind of don't need Bower for. So you just have to learn kind of which way you're going there. Now there's some controversy as Bower on its way out as it's still being supported. There is some overlap that you can install using NPM versus Bower. Sometimes it comes down to what works best for your own workflow. We use NPM to install kind of the tools and we use Bower to install the front-end libraries. One of the other things that we use NPM to install are JavaScript task runners. These are programs that kind of sit in the background. They actually are running Node themselves as they sit on your table and they do things like watch your files and wait for you to save a change to a file. Then it will do something like convert your SAS to CSS. It can also check your JavaScript code for errors using a tool like JSHint. You can concatenate all of your scripts together and minify them to make them nice and small and reduce your HTTP requests that will improve your web performance overall and much, much more. You also have AWS. There are a lot of different AWS plugins that will let you deploy automatically using a Gulp command or a Grunt command. Gulp and Grunt are probably the two most popular JavaScript task runners out there. Personally, we prefer Gulp because we find it's a little bit faster. It's a little bit more based on codes and piping. Grunt is much more configuration based on file to kind of build its configuration. But some projects in the WordPress community use Grunt, others use Gulp, so it's good to become familiar with both of them and then pick the one that works best for you. Brunch and Broccoli are also two ones that are out there, but they kind of have distant third and fourth status to them and they have much less support. So moving on, extending WPCLI later at WorkCamp US. What it is, though, is a man-line alternative for working in the WordPress admin. So instead of having to go to, whoa, let there be light. So instead of having to actually, I'm sorry, but it's kind of washing out the slide, so I'll keep going. So instead of having to go into WP- admin to do all of your administration tasks, you can do them on the command line, which makes it faster. Anytime you don't have to deal with going through a browser, going through a UI, then you're going to have a significant savings in speed. Also, anything you can do on the command line, you can script. So one of our uses for WPCLI in the past is every time we ran a deployment, we would log that into our site using a WordPress custom post type. We would use WPCLI to generate that post and stick it in the database. Automatically, we didn't have to do anything other than run the deployment command. So now that we have our development environment set up and our tools into place, we need a baseline to actually start building our project. And most of our work is doing custom-themed development for clients. And we use underscores to kickstart that. Underscores is a starter theme for WordPress. And if you're not familiar with the concept of a starter theme, parent-child theming means that you take a parent theme, you create a child theme that refers to that parent theme, and you make all your changes to the child theme so that as you are updating the parent theme, your changes aren't wiped away when the updates are made. Starter themes work a little bit to change the name to whatever is appropriate for your project and edit that code directly and then you never update the starter theme again. So if there's a new version of underscores that comes out once you start your project, you don't want to download that, you don't want to get involved with that because you're already working off of your own thing. You've forked it, essentially, for your own purposes. They build themselves as the thousand-hour headstart, and I think that's being a little bit conservative actually, and it gives you all the templates and style sheets, including SAS versions of the style sheets to really get started on your project. So there's a lot that goes into theming that you just don't have to worry about. It's taken off the table because underscores has thought of it. Similarly, there's a project called the WordPress Plugin Boiler Plane, and as you might surmise, it's kind of the underscores for plugins. It's a standard-organized object-oriented foundation for building high-quality WordPress plugins, and again, it's putting into place a blank scaffold of all the best practices that you need to get started in building a plugin. Whenever you're working on a WordPress project for a client and you're doing custom theme work, you are often going to need to figure out what belongs in my theme and what belongs in a custom plugin. Themes should be limited to things that are directly associated with appearance. Plugins should handle all of the data work, so your custom post-type should end up being in a plugin, not in your theme. So that when you change your theme again later, you can keep all of your data separate and you're not having to reinvent all of your custom post-type information the next time you go and work on that project. So we kind of talked about that. Now that we've got our starter theme going and our starter plugin going, there are a couple of plugins that I definitely use and recommend for every project that kind of help guide your way as you're doing some development. The first one is a really tiny, really trivial plugin that helps me immensely, and if you go to their page, let's see how well the Wi-Fi is working, maybe not so well, it will give you that this plugin hasn't been updated in two years' warning. Well, it doesn't matter because all this plugin does is insert a little comment in the HTML towards the bottom of your page that tells you what template is being served when you hit that page. There is nothing, well, there are few things in life that are more frustrating to think why are my changes to archive.php not working, only to realize many hours later that WordPress was actually serving off the index.php or some other .php template, so Show Template would really help in those situations. Debug Bar puts, ah, there we go, the Show Template. Debug Bar puts this little debug option, it's hard to see right here, but it puts this little debug option in there, and when you click on it you can get some information about your query and your cache, and if there are problems in your code, JavaScript is returning something that's not so friendly or you're getting a PHP notice or something along those lines, this button will actually turn very nasty shades of orange and then red to let you know that something is going on, you might want to check that out before you go to deploy this. Theme Check, if you're interested in developing themes to add to the WordPress.org, Theme Repository for example, you need to become familiar with Theme Check. This is the plugin that the Theme Review team uses to make sure that you're following the guidelines that are set in place for the repository. So it does this a sanity check, you have the alignment classes set, you have a sticky class set, do you have any hard coded URLs or other kind of code in your theme. If it fails any one of these tests you're not going to get into the repository. Even if you're working on custom themes for clients and you have no intention of submitting this to the repository it's still probably a good idea to run your theme through Theme Check just to kind of give it like a second set of eyes say did I miss anything. Regenerate thumbnails, if you know me at all then you know I'm a big evangelist for responsive web design that have been for a number of years. Fortunately WordPress has a lot of great tools and mechanisms and more are coming out in the 4.4 release to work with responsive images including add image size. However if you are adding new sizes of images into your WordPress project any media that's already sitting in your media library does not get that new information so it will not rescale. So a plugin like regenerate thumbnails will go through your entire media library or just the one or two images that you need to be rescaled and go through and add the new image sizes to it. This is actually a test that could also be done on the WordPress command line but sometimes it's nice to just kind of hit the button and go. And the last plugin that I cannot live without is WP MigrateDB which basically when you're going from a development environment to a staging environment to a production environment lets you dump your database including renaming the URLs and renaming the directory paths so that it automatically will apply to the next environment. If you get the pro version then it will go one step further and your different environments will actually talk to each other and make the transfer automatically so you don't even have to deal with database dump files and re-importing it it just handles it all together. So in conclusion, in 2015 when you're starting a WordPress project then you need to install package managers, install your revision control, install your starter themes, install your plugin boilerplate and then maybe at some point down the road you can actually get started with code. It might seem like a lot of steps but if you invest the time in the beginning of a project to put some good tools into place then you're going to find collaboration with your team or even just your own personal workflow as an independent developer will go a lot more smoothly as you go along. So as I said, I'm big into responsive web design. I did actually finish a book this year. There is a code. I'm going to be tweeting this out later if you're interested in learning a little bit more about how to build responsive WordPress themes and thank you very much. So the microphone that's in the center hallway is available if anybody has any questions. Do we have any? Okay, great. Come on up. Can you hear me? I'm just wondering what you think about the Advanced Custom Fields plugin. Do you have any thoughts? I love the Advanced Custom Fields plugin. My personal strategy for creating custom post types that is is to do the post type definition in code although Brad is going to give me a long look because he's got a plugin that does that through the UI. But then I will take Advanced Custom Fields and do that for all my custom fields and we're actually, we've purchased the pro version of that as well to give us the extra features like repeating fields and field groups and at some point I'm probably going to do a talk about some of the nifty tricks that you can do but I love that plugin and that's also an essential plugin for me. I think I hear criticisms about it and I'm just wondering if any of that's valid or, well, obviously it's valid. I've heard murmurings and criticism although I don't know what the specific problems are. I did write a blog post on Treehouse a long time ago and I still get comments saying that, oh, this is just a shill for ACF? Well no, this comes from the heart. I really do love it and I would recommend it. Hi Tracy, thank you for the presentation. There's a lot of us, WordPress developers, we work solo so I would like to know your input and why we should still use version control if we work by ourselves. There's a lot of good reasons and I touched on a couple of them which is basically if you end up with problems in your code then you can go backwards in time and find them. The other good thing is if you push your code in Git or something like that to a central repository like GitHub for your code. So if your backups haven't kicked in on your production site or you're working on something on a non-backed up environment this provides an automatic backup and we've actually had that problem happen to us where we were self hosting our Git repositories and our server crashed but I had all the GitHub repositories on my local machine and I was able to kind of restore everything so that's another good reason for a solo developer to be using version control. You're welcome. Thanks for your talk. One of the problems that I frequently have working with clients is when a site is up it's launch, it's been going for a while and it's time to do some work on it. So the client is working on the live site as they often should and they're working on content they're creating new posts and create new content but we're changing configuration and code on the staging site. Merging them together can often be quite challenging because a lot of stuff is stored in the database so the configuration stuff that we're doing some of it is stored in the database the stuff the client is doing on the live site is also stored in the database. Merging those things together are huge pain. Is there some secret trick that I don't know about? Secret trick might be a little strong. There is no one best answer for that. There is a WordPress constant in PHP called save queries which will actually save out your queries as you're doing them so things like we talked about advanced custom fields that's all in the database so if you're adding new fields to a project that's already live you don't want to push your entire database and overwrite their content changes so you can put in policies to say okay from this point in time to that point in time no changes are to be made but that's not usually realistic when you're working with clients save queries will let you save the queries that you're making as you go along and sometimes maybe it just comes down to keeping track of the changes that you're making on your development environment and recreating them in a later environment ACF for example does have a way of exporting its individual custom field groups so that you can re-import them into another environment without having to do a wholesale database change so that's helpful in that regard but there's no one perfect solution other than good project management skills to kind of solve that so I had a question about debug bar which you mentioned that I love there's probably a couple of dozens extensions and add-ons and stuff like that to debug bar like the kint debugger and console and stuff like that and I was just wondering if you could speak to maybe some of the things that you found particularly good in terms of making debug bar more useful the short answer is no, not really I've used some of those plugins before they each have their own purpose and so you kind of tailor to what is the problem I need to kind of keep track on when I'm doing development but I don't have like a list of go-to add-ons to debug bar honestly, since I'm a front-end person specifically although I do do a lot of theme work and PHP work on the themes but most of my focus is on front-end I do a lot of time in the web inspector and Firebug and use those tools as I go along Thanks Hi I've had some struggles setting up the workflow that you've discussed are there any resources in particular that you recommend a video tutorial that would go through everything or which part of it in particular has been vexing you or is it just kind of like well I wanted to start working in SAS and my first project I was using Gulp I got it working at work and then I couldn't get it working on my home computer and I even had a friend try to help me and I really struggled with it a lot and I ended up now on my projects I use a plugin that just does my preprocessing for me so I'm using SAS but I'm not using the workflow that I should be and I do struggle with it and I just wonder if there's any resources you recommend I would have to kind of research that and get back to you so if you want to ping me on Twitter I will do that one thing I will say though is I really don't recommend having a plugin do the CSS preprocessing for you because that's adding more overhead to what WordPress is doing and shouldn't really be its job so you're on the right track to be using a JavaScript task runner I also don't know what development environment you use if you're a Mac person or a PC person but there are also GUI tools like well Koala is one Scout is one but there's a big one whose name is CodeKit yes thank you because I did use CodeKit a long time ago on a big redesign project before we moved to JavaScript task runners so you might find a GUI environment easier to kind of get started with great thank you very much sure good morning great presentation thank you thank you can you have you got any experience using Docker with WordPress I knew I was going to get a Docker question and there's a gentleman in a green follow smiling right now so no I don't have direct experience with Docker it's actually something I was supposed to work on over Thanksgiving but I did not get to it it is definitely something I'm going to be involved in we're an all AWS shop at RP3 and Docker and AWS have some very close integrations but I just haven't quite gotten there yet thank you hi there hi there so I was wondering about tracking compiled CSS and JavaScript files and minification kind of like what you do to work from non-minified files on different environments okay in a word don't I don't commit compiled CSS and I don't commit compiled minified JavaScript for variety reasons first of all that's not where you're doing your development you want to be putting into revision control the stuff that human hands are going to be working on in theory if you're using those tools human hands are not going to be working on the finished CSS and they're certainly not going to be working on a minified JavaScript file the other reason that you don't want to do this is minified files usually are one or two lines with no line breaks every single time a change is made it's going to change the same line and if you have two developers who are working on different files if you're committing the minified code you're going to have a conflict every time that you're going to have to resolve and it's almost impossible to resolve a conflict in a minified file so my recommendation is do not commit your minified and compile code so just to follow up do you compile them on the server we compile it in our development environments using the JavaScript Task Runner so you can do that inside the vagrant virtual machine or you can actually do that on what's known as the bare metal so outside the virtual machine if you have your JavaScript Task Runner like Gulp install globally and you can run NPM on a Mac to install these at the operating system level and run them from there thank you all alright I'm afraid this is going to be the last question Brad's the bad guy on this sorry good morning I was curious if you had thoughts on one the potentially some day upcoming version press and the version control they're trying to do with WordPress and two about development environments and builds using root's tools bedrock, sage, trellis and if you had any experiences with those I will just say I'm sorry I'm not familiar with either of those things that you've mentioned so I really have no answer for that sorry so thank you very much everybody and enjoy the rest of WorkCamp US