Usage

wp-deploy: Usage

A guide on how to work with a wp-deploy project

---

This guide is broken down into the following areas:

• WordPress as a submodule
• Updating WordPress & plugins
• Available commands

WordPress as a submodule

Working with git submodules can be a little daunting at first, but once you get the hang of it its pretty simple. The main thing to understand is to never edit the WordPress submodule. Leave the core as core, and then build upon that with your themes and plugins.

wordpress/wp-content vs /content

Speaking of themes, if you can't edit anything in wordpress/wp-content, then how are you supposed to create themes or add plugins?

Take a look at the content/ folder in the root project. Using a line within our wp-config.php in the root of our project (not in the WordPress submodule) we can direct WordPress to use this folder instead of the usual wordpress/wp-content. This means we can keep our submodule nice and up to date with WordPress releases (which we'll get into within the Updating WordPress & plugins section below), whilst keeping our project up to date with new additions.

Updating WordPress & plugins

Updates work a little different for a wp-deploy project.

WordPress Core

To update WordPress core you don't use the admin interface. Instead, with it being a submodule, you can act as though its an ordinary repository and pull down the changes you need, and checkout into a specific version.

Theres a command in wp-deploy to help you with this. Run the following and you'll update your version of WordPress to the latest version:

$ bundle exec cap staging wp:core:update

Again, an environment always has to be set for a capistrano command, even if not used like above. This command only updates the local WordPress submodule (not any remote environment.)

As this is a submodule, you'll need to make your repository aware of the changes and store them, so that you can push this out to your remote environments. Run the following:

$ git add -A
$ git commit -m "Update WordPress to version X.X.X"

If you push this to your remote repository and then push to an environment you'll see it take effect there too.

NOTE: Occasionally you may run into problems with the cached repo folder on your environment conflicts with the changes you're looking to do, as described in this issue. If this happens, try running the cache:repo:purge command to flush your repo folder.

Plugins

Plugins however, are done in the normal way – the admin area. Log into WordPress, update your plugins and then commit your changes to Git.

Available commands

Here's a list of all available commands for wp-deploy. They must all be prefixed by bundle exec cap <environment>.

$ 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.