This is the killer workflow for WordPress, or at least the key element to build one.

  • Part 1: Composer and WordPress
  • Part 2 (in the work): WordPress and Git

1. What is Composer

Composer is a great tool to manage your PHP dependencies. You probably already know about it if you are used to working with PHP.


Composer is to PHP what npm is to javascript or pip is to Python.

If you come from WordPress integration world, then it might be new to you, but if you want to systematise your install and updates process, this is a great improvement from the traditional WordPress way.

shell > composer install
shell > composer update

2. Key Concepts of Composer

(Where we talk about composer file (composer.json) and Packagist)

NB: If you know composer you can basically skip that part

2.1. Composer.json

  • The central file that control all the dependencies.
  • Very similar to package.json in a nodeJS app.
  • Structure
    "require": {
        "vendor/package": "1.3.2",
        "vendor/package2": "1.*",
        "vendor/package3": "^2.0.3"

2.2. Packagist: where the packages lives

  • is probably the greates source of public packages (like in JS)


Packagist hosts roughly over 200K PHP packages

If you need a PHP package - it is likely to be on Packagist

2.3. Install Composer and elementary commands

2.3.1. Installation

Installation is a one liner : curl -sS | php

If you are on Windows and you don’t have curl, you probably will want to install it first. Google is your friend, but because I am nice, here is a link that looks pretty much what you’d need : Install Curl On Windows

2.3.2. Common commands

# How to install a new package and update your composer.json
composer require vendor-name/package-name

# How to install packages and depencies as defined in composer.json
composer install

# How to update packages all at once
composer update

In short

So you should know that:

  • Composer is a tool to manage PHP packages
  • How to install composer and basic commands
  • Packagist is where are most of PHP packages lives

3. Composer and WordPress

Where we introduce WPackagist, and we modify WordPress folder structure for a cleaner app logic.

WordPress and Composer

3.1. WPackagist

Basically Packagist provide packages for WordPress themes and plugins This is where you will source most of the plugin installs


3.2. Typical WordPress Composer Json config file

(TODO: replace this shameless copy paste from WPackagist with a better example)

    "name": "acme/brilliant-wordpress-site",
    "description": "My brilliant WordPress site",
    "require": {
    "autoload": {
        "psr-0": {
            "Acme": "src/"

Composer and WordPress - real world example

In a typical scenario you need:

  • WordPress itself
  • Plugins most of them public but maybe a few premium
  • A Theme

WordPress itself

You get it from John P. Blosh

And yes, call WordPress from composer make wordpress a dependency.

I know it might feel weird at first, but it’s ok, once you make wordPress a simple dependency of of the project and not the core of the app it makes things easier.

Concretly, it means :

  • wp-content is where most of the valuable data live - that’s the core of your app and has a life of his own - independently of the main WordPress dependency - it makes sense therefore to separate wp-content from the rest.

  • wordpress itself can be installed in its own sub-directory



You get it from

  • wpackagist and git repos


  • You get it from a git repo

Git all the things

Where we discuss version control the things