Getting Started With Modern WordPress Development: What You Need

I’m teaching a few workshops this month aimed at those looking to level up their WordPress development chops. It’s got me thinking a lot about what you need to do quality WordPress development.

It’s a very subjective question, what software to use, what principles to value, what resources to learn from… So I wanted to share my thoughts on what is necessary for getting started. The list is less about software, and more about concepts because in the end, it’s about the wizard, not the wand.


You can write code in notepad and FTP it up to a shared host and hope for the best, but to do it right you need some basics tools. Here is my opinionated list. I’ve broken it down into “basics” and “important”. The first category is things you should have right away. The second list is important, but can probably wait.


Code Editor and IDE

A code editor is a specialized text editor designed for writing code. I like Atom as my simple code editor. It’s the application I use when I just need to open up a file, read it and maybe make a few changes.

An Integrated Development Environment (IDE) is more than a code editor. A good IDE provides everything you need to develop in a language. I do most of my work in phpStorm. I use it as a code editor, web server, terminal, sFTP client, Git client, and more. I probably don’t use half of its features.

Git and A Git GUI

Github Social CodingYou must use version control. It’s just not optional if you need to do anything large in terms of development or work with others. It will also be a part of your deployment strategy.

I wrote more about why you should use Git on the CalderaWP blog. WP Pusher, which is an excellent tool for deploying Git repos as plugins and themes, offers a Git course on their site that is worth checking out.

While I use the command line and phpStorm for Git most of the time, I am still a big fan of SourceTree and it’s one of a few reasons I miss using a Mac for my primary development machine.

Local Development Environment

Installing A Site With DesktopServerThe reasons to use a local environment are numerous. The short answer is — it’s faster, more secure, and no one can see your fails.

There are a lot of ways to set up a local environment on your computer.  Here are the ways I recommend, in order of ease of use:

  • DesktopServer – A simple application that gives you an interface for creating local WordPress sites. Start here if you are new to local development. It’s easy and might be all you need.
  • Valet – Made by the Laravel project, but works with WordPress. I use this on my Mac (never figured out how to get it to work in Ubuntu.) Requires Composer, homebrew and a bit of setup.
  • Vagrant – Vagrant creates a virtual machine on your computer that you can use for development. I use the popular VVV project for setting up a WordPress development environment on my main computer.


Dependency Management Tools

Mandelbrot FractalI’m going to go less in depth here, as I’ve covered Composer quite a bit here and on Torque. Seriously use Composer, it makes PHP development better and easier.

Other tools I use for dependency management and task running:

  • Composer
  • NPM
  • Grunt
  • Bower


When doing JavaScript development, you can use the browser’s developer tools to debug your code. You set a break point to stop execution and see what the variables equal at that point.

xDebug gives you that for PHP. It’s an amazing tool that takes the guess work, and the vard_dump()/die(); out of development. xDebug comes pre-installed in VVV and works great with phpStorm.



Photo by: veeterzyIf you’re brand new to development, you need to get PHP and JavaScript fundamentals down first.

I’ve written a ton on PHP over on Torque. I recommend starting with my PHP fundamentals article and then looking at my article on using WP_Query to learn object-oriented PHP.

For JavaScript, I like CodeAcademy’s JavaScript course. The book “JavaScript The Good Parts” is also worth reading. Like most WordPress developers, I started with JavaScript by using jQuery and starting in jQuery being a smart start is the consensus we came to when we discussed this on an episode of The WPCrowd, which I followed up with an article on the same topic on Torque.

The WordPress Way

It’s hard to define the WordPress Way, without jumping into WordPress code, which you totally should do. The best way to learn after all is to read the source.

In addition, you really should read the WordPress handbooks:

If you take one lesson from the handbooks, it should be that there is a standard for documenting code and that you should follow it. Inline documentation makes it easier to work with your code, it makes it easier to read your code and it’s super useful to developers who are not familiar with your code.


I am very much a believer that pragmatic adherence to certain principles will make you a better developer. At a minumum, I think you should familiarize yourself with the single responsibility principle and the do not repeat yourself (DRY) principle.

Class Autoloaders

I’m a huge beliver in using a class autoloader. It’s becoming more common in WordPress, but is still behind. I covered using a PSR-4 autoloader and Composer’s autoloader in an article for Torque.

An autoloader is simple to setup and it forces a logical directory structure and class naming system on to your plugin or theme.

The WordPress REST API

As you probably know, I’m a huge advocate of the WordPress REST API. I think it’s super important for advancing the quality of code and end-user experience we can deliver.

I’ve written a ton on the REST API to help you get started. But, in my mind, it’s not just about learning the REST API. It’s about learning how to write plugins, themes and site-specific code that can be used with theme templates, shortcodes and the REST API.


Photo by: Paula BorowskaPaula BorowskaOk, that was a little long, but here is my summary:

Use local development (start with Desktop Server) and Git (Github and SourceTree FTW.) Composer and autoloaders are awesome. Read Carl and Tom and document your code.

I’ve linked to a ton of free content, mainly by me, to help you learn. I have two WordPress development courses. One on the WordPress REST API and one on modern WordPress development. You should check those out if you want to learn more and say thanks for all the articles and WordCamp talks that I’ve done to help educate the community.

Deploying WordPress Plugins and Sites Built Using Composer

I’m a big fan of Composer, which I believe will give you super powers. I am happy that it is gaining in popularity in the WordPress world. I often hear from developers who love it, but are not sure what to do about the vendor directory in their plugins or themes or sites.

I spoke about the advantages of challenges of using Composer in a recent episode of The Plugin Architect podcast. I use Composer in most of my plugins. Most of Ingot’s code is in Composer packages, which helps us share code between different versions and add-ons. I also helped refactor the plugins Maps Builder and Maps Builder Pro by WordImpress to make sharing code between the pro and free versions easier.

Often times people are not sure what to commit or gitignore and the best way to deploy their code to keep their package size small. I’d like to answer a few questions to help you make the best of Composer for WordPress development.

Should You Ignore The Vendor Directory In Your Git Repo?

TL;DR yes.

A lot of people are hesitant to gitignore the vendor directory and other dependencies in their GIT repos. Most of the managed hosts encourage you to use GIT to manage your dependencies when using GIT as a deploy tool. This is not good practice for  a few reasons.

First, it is messy and redundant. Why should I use a GIT to manage changes in code that is managed by a different VCS system? It doesn’t make sense. A change to a dependency should require a commit in the configuration file for Composer, Bower, NPM, etc, but not commits of actual code.

Also, keep in mind that by default, Composer checks out all packages as GIT repos. That’s great in development, but not something you want included in your final product. Composer is built with this in mind. But you should not ship your plugins with Composer packages as GIT repos or push GIT repos of dependencies to your site.

Down with redundancy and bloat, folks.


TL;DR –prefer-dist

Let’s talk about two scenarios, site deployment and shipping plugins. The solutions are pretty similar.

Site Deployment

The first situation is where you are deploying a site using GIT and Composer. If your live server has Composer installed — a rarity for some bizarre  reason in the WordPress managed hosting space — then this is easy. Use Composer to manage dependencies and gitignore the vendor directory and when you deploy use the –prefer-dist argument to tell composer to not checkout the whole GIT repo.

Laravel Forge, which is a server provisioning and deployment system of industry, has this line in its default deploy script:

composer install --no-interaction --no-dev --prefer-dist

This tells Composer to install with none of the packages that are required for development only, like your unit test framework, and to get the packaged distribution of the dependency, not the whole GIT repo. I have no idea what --no-interaction does, but let’s assume its good.

You probably want to add –optimize-autoloader to that if you’re not using Laravel, which runs that in one of its post install scripts.


CalderaWP WapuuI make more plugins than I make sites. Most Caldera Forms add-ons use Composer to manage at least two dependencies. I’ve written a Grunt script that helps automate this process. It checks out all of the dependencies using composer update --prefer-dist and then copies everything to a sub directory, which it then zips and deletes.

This means that my plugin repos, have a directory, usually called releases, with a ZIP file I can upload to our site. I used to add an automated SVN deploy when I was working on plugins that need to go to Now I just open that ZIP file and drag it into a new tag inside the SVN repo, opened with phpStorm and commit that.

What Else?

TL;DR Alot
Photo by: Jasper van der MeijThere are a few other challenges when using Composer. But I really do think they are outweighed  by the benefits. Composer is an essential part of the workflow for modern WordPress development.

Nor are these issues unique to Composer. I should probably write a follow up on using Bower Installer to solve a similar problem with Bower and NPM.

Composer is a great tool, and I hope you will try it, and when you do, this will have helped you learn how to make it work properly with GIT.


Composer For WordPress Plugin Development On WPSessions

WPSessions Icon For The TalkToday I did a WPSessions on using Composer in WordPress plugin development. I’m super honored that Brian allowed me to do this, and was really happy to share what I think is a really important tool.

If you missed the live event, you can always purchase the recording from WPSessions.

Below, you can see my slides from the event, which include a lot of helpful links for Composer. You should probably checkout the links in the post for my WordCamp Atlanta talk on Composer, which was a more basic talk, with a broader scope.

Gain WordPress Development Superpowers With Composer

This weekend I am super-honored to be presenting at WordCamp Atlanta 2015 on Composer, the PHP dependency manger. This presentation, “Using Composer To Increase Your WordPress Development Powers,” is adapted from an earlier post on this site of the same title.

If you are new to Composer, I recommend that you read my Torque posts on it. So far I have written an introduction to using Composer with WordPress and a guide to improving WordPress plugin development with Composer. I also recommend reading through Rarst’s Composer for WordPress resources.

The video from the talk is now available from WordPress TV:

My slides for the presentation are below:

Using Composer To Increase Your WordPress Development Powers

In the last few months I’ve been using Composer to improve my development and deployment of WordPress projects. It’s an important tool that is not only easy to use, but also leads to increased code reusability, a reduction in copypasta errors, encourages best practices like using namespacing and autoloaders, and can aid in deployments.

I’ve covered how composer works in my posts for Torque on the subject already. But, in this post I wanted to just briefly go over the various scenarios in which composer is useful and how it can improve your life, and increase your personal powers as a developer and a human being.

If you are new to Composer, I recommend that you read my Torque posts on it. So far I have written an introduction to using Composer with WordPress and a guide to improving WordPress plugin development with Composer.

Improved Site Deployments

One of the trickiest things about moving between a development and production site is dealing with the parts of the project that do not belong in version control. Sometimes you end up with all of your plugins, and WordPress itself in the Git repo you use for the site.

This is, objectively speaking, an absolutely terrible idea. Why should you write every change to WordPress or a plugin to your Git history? That makes no sense. Use version control to track changes to code you are changing and no other code.

For HoloTree, we have a Git repo for building the live and development sites that establishes the structure of the site. It includes wp-config, my VVV config and a few other things, but does not include any plugins, the theme or WordPress itself. All of that gets pulled in by Composer.

Mark at Kinsta helped me set up to automate the process. Since connects to my server via SSH, it is able to run composer update for both the main repo and the plugins that power HoloTree, each of which pull various libraries.

This is all made easy by the fact that every plugin in the plugin and theme repositories are automatically available as a Composer package, thanks to wpackagist.

Update: I created a git repo that has everything set up for new WordPress site development using Vagrant, and my preferred way of using Composer for dependency management.

Sharing Code Between Plugins

As you go through life, you will find yourself developing repetitive patterns you like to use in all of your plugins. That’s great, unless you are cutting and pasting those patterns between projects.

Moving the classes and collections of functions you use for a part of a project into a Composer library is a little bit of extra work. You will see a return on investment for that small amount of work the first time you use the library again. When you fix a bug in the library and are able to easily share the change across all projects using that library… well that’s just awesome.

Using Other People’s Libraries

Packagist, GitHub and the internet at large are full of great libraries that you can pull into your plugin or other project using a dependency manager like Composer or NPM. Using a dependency manger makes doing so both easy to do and easy to keep up to date.

If you ever wanted to use a piece of another PHP framework, say for example Symphony, Composer makes it easy. Also, some talented WordPress developers publish libraries on Packagist. For example, Mark Jaquith, Andrey “Rarst” Savchenko and Eric Mann.

Of course, a package doesn’t have to be on Packagist. If it has a valid composer.json file, you can pull it directly from GitHub.

Composer Libraries Are Git Repos!

Note: I know they could be SVN or whatever repos, but using anything besides Git is, objectively speaking, silly.

Let’s say you have a plugin constructed of several Composer libraries, and one file with the plugin header and a function to include the autoloader. First off, great victory, you win a _doing_it_right() award in my book. You might be worried about having to maintain separate checked out version of the repo to commit changes to.

This is not the case. When Composer pulls in a package, it includes the .git file and sets the remote origin properly. If you have write access to the repo, you can simply CD into the package’s directory and commit and push like any other Git repo.

No New Copypasta!

copypastaDon’t Repeat Yourself (DRY) is one of the most sacred principles of programming for good reason. Cutting and pasting the same code between files is an equal, if not greater violation of this important principle.

Not making your code easily reusable for the benefit of yourself and others makes your life harder. Further, it robs you of the ability to help others while promoting yourself.

So stop.


Featured Image by:  Lance Anderson via Unsplash