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

How to use WordPress with Git efficiently

I use to work with frameworks like Symfony, Angular, Laravel and more.

When it comes to VCS (Version Control System), we need to remind some facts.

1. Keep track of changes by owners, time…
2. Easily roll back changes when necessary
3. Easier to collaborate with other developers

1. Replacement for scheduled backups, VCS !== BACKUP !!!
2. Debugging. Since every little change is tracked, it’s not its purpose.
3. Committing untested or broken code to the repository… Just a matter of sense !
4. Committing generated content (from user or otherwise)
5. Uploads & thumbnails => heavy repo with absolutely no benefit, use a cdn for media content !

WHAT IS THE GOAL OF VCS WITH WORDPRESS (Like another framework or cms)
1. Keep sensitive information out of the repository
2. Avoid wordpress core and upload files

Ok. You will surely tell me that this way, it will be a pain to retrieve the full project for a new developer, because there will be no wordpress core files, nor wp-config.php file.

Sure you’re right. But remember, VCS !== BACKUP, keep third parties you are not allowed to touch apart of your repository.
ANND, I will show an easier way to bypass this simple issue.

  • It is not a good way to modify wordpress core (what about future updates)? Don’t keep core files inside your repository.
  • Config file is personal to each user, never shared it on vcs, keep database datas secret.


Let’s start with the .gitignore file content

# Ignore everything in the root except the "wp-content" directory.

# Ignore everything in the "wp-content" directory, except the based themes and the "tmp" directory.

#Do this essentially if you store your media content inside a cdn

# Hidden files

Now, let’s grab the wordpress core and config files. For that we will need “wp-cli” extension, you can download it here:

Once, you have “wp-cli” enabled in your cli environment, we can start the fun:

  1. Install WordPress core files with a specific version
    wp core download --version=x.x.x --allow-root
  2. Install config file with database datas

    wp core config --dbname=mysite --dbuser=root --dbpass=password --dbhost=

And here we go, quite simple, enjoy 🙂

How to use WordPress with Git efficiently

Git issue with WordPress some folders are ignored

Hi everyone,

It’s been a while I didn’t wrote here and I’m glad to see that I make more and more visits, thank you.
It feels good to be back and share with you my issues.

So today I faced a strange problem with WordPress.

Our wordpress project uses Retouch theme with Unyson plugins.

After some updates on the project, I created a git repository and put my changes in, inside a branch.
Everything was ok, expected that if you pull the git repository, even if you re-upload the database, it seems that instead of displaying the normal content from the database, it was a hash that was shown, something like “{length: xxx, hash: xxx}”.

After many hours, I noticed that the problem was a plugin issue with Unyson Builder extension that was missing in my repository.

I can’t actually figure why, but in BitBucket when I access this directory “wp-content/plugins/unyson/framework/extensions/shortcodes/”, the next folder seems to be two folders attached like this “extensions/page-builder”.

So git was ignoring this folder no matter what I could do.

To solve this kind of problem, you always have to check that git doesn’t ignore accidentally some folders. After your “git add” and before any “git commit”, use this command:

git status --ignored

Thank you for reading me.

Git issue with WordPress some folders are ignored