Like most people, I started learning WordPress development by downloading files from the theme I was using for my site, editing them, and then uploading them back and seeing if what I did worked–on my live server, via FTP. Experience developers will shudder at the thought, while newcomers to the exciting world of WordPress development are probably asking why not.
You may think that the things I’m laying out in this article are optional things, not worth taking the time to learn, but they are worth the investment in your time. I’m not saying that because you will get the time spent learning how to do these things back 100-fold or more as they will make you a more efficient developer. No, the real reason I think you must do these things is that it was only once I started doing these things that I started to get any good at WordPress development.
My system might not be the most efficient, hell I’m not even using Grunt, yet, but once I started developing smartly–ie locally, with version control, and using the debug bar, I was able to concentrate on what I was doing, not how I was doing it. I got more done, solved more problems and was able to actually accomplish something.
So, I want to share the three biggest things I wish someone had told me when I started doing WordPress development, in hopes that others will read this and skip as much of the struggles I went through when I started.
What I Wish I Had Known Then
Develop Locally
Life is too short for regrets, but I regret the amount of time I wasted by developing on a remote site. All of the time I spent uploading a file–from a different program than I was writing the code in since I wasn’t using an IDE–refreshing my browser page, waiting for it to load, I want that back. I wasn’t just wasting time, every time I broke my site, I was showing the error in my site or presenting a broken version of my site to the world.
If you’re still developing on a remote site , stop. Clone your remote site using WordPress Duplicator, and import that into a local site using DesktopServer. Once you start developing locally you will never go back. Being able to click save and immediately see the changes–well after a browser refresh if you’re not live reloading your browser–will improve the quality of your life. Seriously, spend less time breaking your live site, waiting for files to upload and dealing with caches, and more time developing.
By the way DesktopServer is the easiest, but not the best or fastest way to create a local development and testing environment for WordPress. Vagrant is better, but harder to set up. Keep that in mind.
Use The Debug Bar Plugin(s)
The plugin Debug Bar and its many add-ons, especially the Debug Console plugin is another one of those that will allow you to do the same thing that you had been doing more efficiently. The debug bar plugin by itself gives you an easy way to see your PHP debug errors, and get some info about the current query, but the add-on plugins are what makes it really shine.
The debug console lets you execute any PHP code and see what happens. Any errors you create will show in the console, and will not break your site. Debugging is all about testing your assumptions. For example, does a piece of code generate the output you expected? Does an option contain the data you expect it to? The debug console, not your current theme’s header.php is the place to do this detective work.
When developing, it is important to work through problems systematically, making sure that every part of your code does what it’s supposed to do and creating the expected output is important. The quickest way to do this process is drop the code into the debug console, and print_r() or even print_r2() the results. Using the console means there are no page refreshes involved.
Use Version Control
Do you make mistakes? So do I, but it doesn’t bother me since everything I do is under version control. Using version control means that you can revert any change you made to a file, even if you’ve made 100 changes since then, without loosing those other changes. It also means you can start your projects by “forking” other people’s work, and it means you can contribute to other open source projects.
Do you have a subfolder of every project you are working on filled with files with names like “index.php-9:14pm” and “single.php-before-adding-new-sidebar” and such? I used to. Then I started using version control.
Using version control isn’t hard since there are great GUI tools for Git, the best version control system that also happens to be the technology that powers the source code hosting and social code sharing site GitHub. I use SourceTree for handling version control, but others like Tower or the GitHub app.
What Else?
I’m sure there are some advanced developers out there reading this, yelling at their screen about what I didn’t cover. For example, using an IDE. Set me right in the comments.