When I first learned WordPress and only had to manage one project at a time, usually with months or years between builds, I was content to do things in what I would now call the hard way (and others would say the Cowboy way). Since starting work as a full-time consultant, I finally had to refine my workflow in order to increase my productivity, improve project tracking, and maintain backups of my work. Although I know there is a lot of room for me to improve, I’m sure that I’m doing much better than I was when I started out as a WordPress developer. So I thought I’d share a few tips for fellow cowboys out there looking to settle down and set up a stable development homestead.

Going Local

There are a lot of ways to setup a local development environment, some recommend using Varying Vagrant Vagrants, others use MAMP, but I found VVV increadibly difficult to setup, and MAMP requires purchasing a pro license to be a scalable solution. I ended up going with the method detailed here (OSX Yosemite and up). It may look intimidating if you don’t spend that much time in the terminal, but the author did a bang up job of ensuring that all you have to do is copy and paste a bunch of commands. Once this is setup, you’ll be able to create a new .dev domain by simply creating a new folder inside the Sites folder of your home directory.

Finally, I installed phpmyadmin by simply downloading the files and placing them in ~/Sites/phpmyadmin, allowing me to go to phpmyadmin.dev to manage my local databases.

Git Out of FTP

If you’re on a host that doesn’t allow you shell access or the use of GIT when logged into the shell, then this step won’t be feasible for you. If you aren’t afraid of the command line, and are looking for a host that gives you the full access of a VPS without the high cost, I’ve been extremely happy with DigitalOcean.

Once I have my initial install of WordPress up and running with my base theme and essential plugins, but before I do any custom coding, I add my files to a private Git repository on BitBucket. I use the same .gitignore file for most project that excludes the following files & directories (if I anticipate the site will exceed 2GB, the limit for free BitBucket repos, then I’ll add wp-content/uploads/ to this list):

[[code]]czoyMzI6XCJ3cC1jb250ZW50L2FkdmFuY2VkLWNhY2hlLnBocAp3cC1jb250ZW50L2JhY2t1cC1kYi8Kd3AtY29udGVudC9iYWNrdXB7WyYqJl19cy8Kd3AtY29udGVudC9ibG9ncy5kaXIvCndwLWNvbnRlbnQvY2FjaGUvCndwLWNvbnRlbnQvdXBncmFkZS8Kd3Atc25hcHNob3RzL3tbJiomXX0Kd3AtY29udGVudC93cC1jYWNoZS1jb25maWcucGhwCgovbGljZW5zZS50eHQKL3JlYWRtZS5odG1sCi9zaXRlbWFwLnhtbAovc2l0e1smKiZdfWVtYXAueG1sLmd6XCI7e1smKiZdfQ==[[/code]]

Once I have pushed all my files up to the new repository, I log into my host via SSH, go to the website’s directory and clone the repository. Now whenever I reach a development milestone such as coding a new page template, add new core functions, or fix a bug, I use Git to manage my file transfers instead of FTP. If you haven’t worked this way and are used to FTP, the process of adding, committing, pushing and pulling to and from the remote repository may seem overly complicated, but I assure you it’s worth it for the following reasons:

  • You don’t have to remember which files are supposed to be uploaded. You also won’t have to waste time and transfer data uploading your entire theme’s directory every time you are ready to push a change. Git keeps track of what files changed and will only pull down the relevant files with a single command.
  • You can use your commit log as a makeshift time tracker. Then if you ever have a client question how long a task took, you can reference the log and even show them the amount of code that changed if you really wanna get technial.
  • Git will allow you to roll back the file to a previous version if you ever find that some code you uploaded completely breaks something.
  • Git enables conflict-free collaboration, should the day come when you need to bring another developer in to work on a project.

Of course, Git only keeps track of the files, not the database. If you want to be extra cautious when making major changes or updating plugins, it never hurts to keep a dump file of the database somewhere in the project.

WordPress Migrate DB

Before I developed this workflow, I tried some clunky ways to move from local to staging and production environments. At first I would export my DB and do a search and replace for my file paths and domain name. For a while I would use Duplicator to create an installer package and archive and install it on the new server, but both of these methods ran into problems and were extremely time consuming.

Finally I discovered the WordPress Migrate DB plugin and my life was complete. One day I may upgrade to the Pro version that promises to simplify things even more, but for now I couldn’t be happier with the process. It handles all the file path and domain name changes, and even lets you save profiles based on what environmnet you’re exporting to. Once the SQL file has been downloaded, all I have to do is go to phpmyadmin on my remote server, select the appropriate database and import the new database. To keep things simple, I always make sure that I setup the databases with the same names and users on all my environments atorvastatin price.