Using WordPress efficiently with Capistrano

Hi everybody,

In the previous article here How to use WordPress with Git efficiently , I showed you the best practices when you have to deal with Git and WordPress.

It’s good, but what if you have to deal with multiple environments like “local, staging and prod”? What would be the best deployment procedure?

WordPress is a cms managed essentially through the database, partially with files, and plugins don’t have a repository system like Packagist with Composer or NPM, so hard to deal with third parties properly in all environments, you’ll have to put all the plugins in your vcs (Versioning Control System) or install them manually in all your environments.
And, about the database, it is very difficult (impossible) to manage it through a vcs.

If you didn’t managed yet to work with Git and wp-cli in your WordPress project, please refer to my previous article How to use WordPress with Git efficiently.

To deal with deployments best practices under WordPress, we will use the most famous “Capistrano” adapted for WordPress, link here It’s not really good explained, let me save you some time.

Let’s start:

  1. If Ruby, gem, bundler and wp-cli are not installed in your machine, install them
    apt-get install ruby gem
    rvm gemset use global && gem install bundler
    #Now install wp-cli
    curl -O
    chmod +x wp-cli.phar
    sudo mv wp-cli.phar /usr/local/bin/wp
  2. Download the github repository on your machine

    git clone <YOUR_FOLDER_NAME>

  3. Be sure that the owner of the last created folder is not “root”, it will cause you issues with Capistrano and wp-cli. If the folder owner is “root”, change it to any other profile you have.

  4. Install the ruby gems dependencies

    cd YOUR_FOLDER_NAME && bundle install

  5. Write your wordpress repository config (with the right branch, mainly development) inside file

    nano config/

  6. Automatically pull your WordPress repository inside our main repository, it will be pulled inside a wordpress directory

    bash config/

  7. Check that your repository has been pulled inside the “WordPress” directory with the correct branch name

    cd wordpress && ls -al
    git checkout

  8. Perfect ! Now let’s configure general settings

    cd ../config && ls -al
    #You can look at all the files inside. For general settings we will only use the deploy.rb file
    nano deploy.rb
    #wp_user: The username of your WordPress administration user.
    #wp_email: The email address of your administration user.
    #wp_sitename: The site title of your WordPress installation.
    #wp_localurl: The local URL of your site.
    #application: The name of the temporary folder used by Capistrano when deploying the website.
    #repo_url: The SSH URL of the remote repository. Capistrano uses this to clone the repository onto the server.

  9. Now let’s fill in database details for all of our environments

    #First duplicate the database.example.yml file and edit it
    cp database.example.yml database.yml
    nano database.yml

  10. Alright ! Now let’s configure our deployment environments

    cd /deploy && ls -al
    #You must see two files, production.rb and staging.rb, open them and fill in correct informations
    #stage_url: This is the URL of what the website will be under in that environment. This should always have the HTTP protocol (,, etc etc). You'll need to make sure your vhosts on the server are setup for this URL.
    #server: The IP address of the server to connect to via SSH. Each environment can be on a different server, think staging server vs production server, keeping things nice and compartmentalized.
    #user: The SSH server you'll be using to connect.
    #deploy_to: The folder on your server where the site will reside.

You are almost done. You are now on your development branch inside the staging environment, be sure that you have a working production environment.

If you already have a database for your project, install it manually, if not, you can deploy your project locally.

bundle exec cap staging wp:setup:local

#Then check your database

Your purpose now is from staging to push modifications on production and rollback immediately if something is going wrong. Never push directly from local environment to production, and, like it is done for WordPress, you can easily push/pull/backup your database from any environment to any other.

These are the list of all commands available.

deploy                   # Deploy the project to a given environment
deploy:rollback          # Rollback to a previous deployment.
wp:setup:local           # Setup your project locally
wp:setup:remote          # Setup your project on a remote environment
wp:setup:both            # Setup your project locally and on remote environment
wp:set_permissions       # Set 666 permission for `.htaccess` and 777 for `uploads` on remote environment
wp:core:update           # Update WordPress submodule (core) locally.
db:push                  # Override the remote environment's database with your local copy. Will also do a 'search and replace' for the site URLs.
db:pull                  # Override the local database with your remote environment's copy. Will also do a 'search and replace' for the site URLs.
db:backup                # Take an sqldump of the remote environment's database and store it in a folder of your local repository called db_backups (its ignored in Git)
uploads:push             # Override the remote environment's uploads folder with your local copy.
uploads:pull             # Override your local uploads folder with the environment's copy.
cache:repo:purge         # Remove the repo folder on the environment in question.

If you need more informations about capistrano and this tutorial, this is a useful link:

Using WordPress efficiently with Capistrano

Doctrine Annotations 1.2.2 // Bug errorException unlink annotations


If you have updated doctrine dependency today 2014-12-19, and since 2014-12-18, you may have faced this error:

  unlink(/var/www/xxx/app/cache/dev/annotations/54940ee3e1d910.826327572T4l9C): No such file or directory

The problem is caused for a recent update in Doctrine Annotations, in the fileReader that tries to delete a file that has been removed.
I’ve proposed a fix here:

if you want to fix this issue quickly, just open:

nano /var/www/xxxx/vendor/doctrine/annotations/lib/Doctrine/Common/Annotations/FileCacheReader.php

//Then, Comment line 207
Doctrine Annotations 1.2.2 // Bug errorException unlink annotations

Git clone and pull from command line without prompt

If you have ever tried to clone or pull a private git repository from command line, you surely face the prompt for username and password.

This is a quick way to solve this problem:

git clone

This command also work for git pull

git pull

It saved me a lot of time to monitor a git repository from command line, I hope it will help you.

Git clone and pull from command line without prompt