WordPressのデプロイをwp-deployで設定する

vpsを借りてwordpressを設置するのは簡単だが、ただ設置するだけだとデザイン調整を本番ままで調整したりいじってもバックアップ取らないといけなかったりとかが面倒になる。面倒なところは早めに潰しておきたいのでwordpressのデプロイを[wp-deploy](https://github.com/Mixd/wp-deploy)で設定する。

wp-deployの機能として簡単に説明すると

- capistranoを使用
  - wordpressのコア部分はgithubにある[WordPress](https://github.com/WordPress/WordPress)リポジトリからソースを持ってきて設置する
    - 日本語対応させるためにこの設定は無くすけど
  - WordPressのインストール階層の変更を使っている
    - `http://example.com/wordpress/`に本体が入ります。
- databaseの設定がyml管理
  - ローカル、ステージング、本番共に
- dbのバックアップがコマンドで実行できる
- 画像、dbの内容をローカルに持ってきたり本番に持って行ったりできる
- ローカルでwordpressの表示確認ができる

って感じかな。
主にデプロイ環境を整えるので、テーマのインストールやプラグイン、テーマの変更とかwordpressのバージョンアップはローカルで実行してからコミット。デプロイを行って本番に反映するって流れになる。

# 設定方法

`bundler`、`wp-cli`、`git --version 1.7以上(?)`が必要。gitのバージョンは`git checkout -B`が使えるバージョンまで上げる。2.3系まであげればとりあえずいいんじゃないかな。(要確認)
これらはローカル、リモート環境両方に入れる。

`wp-cli`はmacの場合はbrewで入れられる

    brew install wp-cli

curlで実行ファイルダウンロードもできる

    curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
    php wp-cli.phar --info
    chmod +x wp-cli.phar
    sudo mv wp-cli.phar /usr/local/bin/wp

gitのバージョン上げる(centosの場合)

    sudo yum remove git
    sudo yum install curl-devel expat-devel gettext-devel openssl-devel zlib-devel perl-ExtUtils-MakeMaker
    wget https://www.kernel.org/pub/software/scm/git/git-2.3.1.tar.gz
    tar -zxf git-2.3.1.tar.gz
    cd git-2.3.1
    make prefix=/usr/local all
    sudo make prefix=/usr/local install
    git --version

# wp-deployの初期設定

    cd my/desired/directory
    git clone --recursive https://github.com/Mixd/wp-deploy.git new-project
    cd new-project
    bash config/prepare.sh
    git remote add origin <repo_url>

`repo_url`はgithubとかbitbucketとかご自由に

wordpressの管理画面から日本語に更新するとgitのサブモジュールとして入れたwordpressディレクトリ配下のファイルが更新されてしまう。サブモジュールままだとその変更が反映されないのが嫌だったのでサブモジュールを無くして、gitリポジトリに全部含めるようにする。

    git submodule deinit wordpress
    git rm wordpress
    git clone -b 4.0-branch https://github.com/WordPress/WordPress.git wordpress
    rm -rf wordpress/.git

xmlrpcで更新する場合の`xmlrpc.php`がgitignore設定されてるので除外しないように

    vi .gitignore

```php:
-xmlrpc.php
+#xmlrpc.php
```

    git add -A
    git commit -m 'wordpressをリポジトリに含める'

deploy時の設定を書き換える

    vi config/deploy.rb

```ruby:config/deploy.rb
set :wp_user, "yourname" # The admin username
set :wp_email, "yourname@example.com" # The admin email address
set :wp_sitename, "WP Deploy" # The site title
set :wp_localurl, "http://wpdeploy" # Your local environment URL

set :application, "wp-deploy"
set :repo_url, "git@github.com:Mixd/wp-deploy.git"
```

staging、productionの設定

    vi config/deploy/production.rb
    vi config/deploy/staging.rb

```ruby:config/deploy/production.rb
set :stage_url, "http://www.example.com"
server "XXX.XXX.XX.XXX", user: "SSHUSER", roles: %w{web app db}
set :deploy_to, "/deploy/to/path"
set :branch, "master"
```

`database.yml`を環境によって書き換える

    cp config/database.example.yml config/database.yml
    vi config/database.yml

```yml:config/database.yml
staging:
  host: localhost
  database: db_name
  username: db_user
  password: 'db_pass'
production:
  host: localhost
  database: db_name
  username: db_user
  password: 'db_pass'
local:
  host: localhost
  database: db_name
  username: root
  password: 'root'
```

一通りの準備はここまで。

# ローカル環境での表示確認

最初に書くと

    bundle exec cap production wp:setup:local # productionと指定してるけどローカル環境のみに設定されます(!?)

の実行はタイミング間違えると地雷っぽいので最初にやらないように。作成してくれて便利っぽいんだけど、表示してくれるadminパスワードでログインできない(?)のでコマンド実行で作成される`wp-config.php`をブラウザ経由で作成するようにします。(ちゃんとしたやり方があるのだろうか)(バグっぽいので今後改修されるかもだけど)

ローカルで設定してしまえば、あとはdbの内容を本番に持って行ったりをして共有できるので、一度設定しちゃえば楽なんだけど。

ローカルで確認するために`/etc/hosts`を編集しローカルを見るドメインの設定、apache等で今まで作業していたリポジトリを見るように設定しておきます、あとwordpressが実行できるようにとか(要検索(書くの疲れた))

で、ここでは<http://wpdeploy>を設定したら今まで作業していたリポジトリを見にいくように設定したとします。現状のままアクセスすると真っ白な画面しか表示されないと思います。これはテーマが全くインストールされてない、読み込めてない状況なのでテーマ移動してやります。

    bundle install
    mv wordpress/wp-content/themes/twentyfourteen/ content/themes/

<http://wpdeploy/wordpress/wp-login.php>にアクセス。

聞かれるがままに答えます。言語指定、wordpressのサイト名、ユーザーの設定、dbの指定等々(設定ファイルに書いた内容のまま)をします。管理画面が表示されればオッケー。
このままだとテーマの読み込みが`wordpress/wp-content`配下のを読むので、一旦削除してから`wp-config.php`の作成

    rm wordpress/wp-config.php
    bundle exec cap production wp:setup:local # productionと指定してるけどローカル環境のみに設定されます(!?)

とりあえずこれで<http://wpdeploy>にアクセスしてテーマが適応されたサイトが表示される。

    git add -A
    git commit -m 'テーマの設定'

# 日本語化、バージョンアップ

もう一度<http://wpdeploy/wordpress/wp-login.php>にアクセス。ログアウトされてるのでブラウザ経由で設定したユーザー名、パスワードでログイン。

Dashboard -> Updates

で`Update Now`、`Update Translations`、Select Allをチェックしてから`Update Themes`をクリックで新しいものを入れる。
これで一通りが最新&日本語化が完了する。

    git add -A
    git commit -m 'wordpressの更新、日本語化'

ローカルはこんなもんです。一旦お疲れ様でした。


# リモート環境へデプロイ
上記で説明していた`bundler`、`wp-cli`、`git --version 1.7以上(?)`を入れておいて

    git push # remoteリポジトリの最新を持ってくるのでpushしておく
    bundle exec cap production wp:setup:remote
    bundle exec cap production deploy
    bundle exec cap production wp:set_permissions
    bundle exec cap production db:push # ローカルの設定が反映、url等の置き換えは自動でしてくれるので便利

でオッケー。パスワードはローカルで設定したものでログインできる。capistranoの方言や(`/path/to/deploy/current`にapache等のroot pathの変更等)、わかっていれば問題ないかな。`config/database.yml`を適切に設定できていれば設定してくれる。php-fpmとか使ってるのならreloadの設定を追加したりする。

あとは便利そうなコマンド一覧。

    bundle exec cap production db:push
    bundle exec cap production db:pull
    bundle exec cap production db:backup
    bundle exec cap production uploads:pull
    bundle exec cap production uploads:push

`uploads:pull`とかの画像系をローカルに持ってきたり、持って行ったりのタスクはsshポートが22にしか対応していないので、タスクの変更が必要になる。ポート変わってるだけでタスクの中身変えるの嫌だったのでプルリク送ったけど勘違いっぽいコメントつけられてプルリク閉じられたので悲しみ。
https://github.com/Mixd/wp-deploy/pull/59

継続して使う分には問題なく、最初だけ設定が複雑だけど後のコストはあんまりかからなそうなのでまぁこれでいいかなって感じです。

# wp-cli
この設定してる時に初めてwp-cliを知って、設定してみたんだけどwp-deployの時はちょっと設定必要みたい。環境によるみたいだけど。

このissueにあるように、`wp-config.php`の`WP_CONTENT_DIR`の設定値を確認するのをお勧めします。
https://github.com/Mixd/wp-deploy/issues/3

自分は以下のように書き換えが必要でした

```php:wp-config.php
  define('WP_CONTENT_DIR', realpath(dirname(__FILE__) . '/content'));
  // define('WP_CONTENT_DIR', realpath($_SERVER['DOCUMENT_ROOT'] . '/content'));
```

使ってみてだけど、日本語化ファイルの最新がちゃんと入らない(?)みたいで結局ブラウザからインストールしたりとかしてたので、あんまり使わないかなぁとは思う。`cap`の内部で使ってはいるけど、それ以上はあんまり使い道は見つけられなかった。


# 総括
一回やれば便利っぽいけどとても面倒くさかったです。(私は使いますが)