# Bedrock をプロジェクトに導入する

## 1.概要
https://roots.io/bedrock/

図のような構成になり、公式が唱えているメリット＋αは下記です。
- コンテンツのURLに wp- を含めないカスタムディレクトリ
- 環境変数設定ファイルを公開ディレクトリより上の階層で管理できる構成。
- 環境ごとに個別の処理を追加可能(追加を想定して設定ファイルが構成されている)
- Wordpressのコアファイルとテーマなどのコンテンツファイル(wp-content)を分離
- wp-password-bcrypt を通じてより安全なパスワードを提供

├── composer.json
├── config
│   ├── application.php     # Primary wp-config
│   └── environments
│       ├── development.php
│       ├── staging.php
│       └── production.php
├── vendor                  # Composer dependencies
└── web                     # Public document root
    ├── app                 # WordPress content dir
    │   ├── mu-plugins
    │   ├── plugins
    │   ├── themes
    │   └── uploads
    ├── wp-config.php
    ├── index.php
    └── wp                  # WordPress core

## 2.導入
### 2-1.composerで導入
composer を用いて導入します。プロジェクトで導入する際は本番環境とPHPバージョンを合わせる必要があるので、DockerなどでPHP環境を構築し、実行します。

% composer create-project roots/bedrock [インストールするディレクトリまでのパス]

#### PHPバージョンについて

レンタルサーバーでは、ディレクトリごとにPHPバージョンを変える機能をコントロールパネルに持たせているため、グローバルにインストールされている PHPバージョンと ディレクトリに設定されているWEBアクセスのPHPバージョンが違う時があります。

そう言った時にサーバーで composer コマンドを実行するときは composer.jsonに合わせて、composer.pharファイルを設置し、該当する PHPバージョンから直接実行します。

> composer.jsonがあるディレクトリで `composer install` を行うとき

% /usr/local/php/8.0/bin/php composer.phar install

#### Composer の実行バージョンを明示的に指定しておく
composer の実行バージョンを明示的に指定しておくことで依存するパッケージのPHPバージョンを固定することができる。

> composer.json

{
  "config": {
    "platform": {
      "php": "8.1.6"
    }
  }
}

### 2-2.設定ファイル
上記2-1のコマンドを実行すると、1のディレクトリ構成に加えて、

- phpcs.xml ([PHP_CodeSniffer/コーディング標準設計ファイル](https://github.com/squizlabs/PHP_CodeSniffer/wiki/Annotated-Ruleset))
=> Roots(開発元)のPHPコーディング基準の設定ファイルです。

- wp-cli.xml (WP CLI 定義ファイル)
- .env (環境変数定義ファイル)

が追加されます。

Wordpress の リクエスト処理における wp-config.php 内では
composerのvendor(読み込んだライブラリ) => config/application.php の順に読み込みを行うので、config/application.php が wp-config.php と同じ役割をします。

### 2-3.環境ごとの設定
config/application.php では .env の読み込みと、config/environments/[WP_ENV].php の読み込みを行うので、APIキーやメール送信先など、環境変数は .envで設定、環境ごとの構成は config/environments/[WP_ENV].php で設定します。

デフォルトでは、
- DB
- WP_DEBUG
- NONCE SALT
- DISABLE_WP_CRON
- WP_POST_REVISION

など Wordpress標準のwp-config.php で行う設定が環境変数を通じて設定可能になっています。

#### AUTOMATIC_UPDATER_DISABLED
デフォルトではプラグイン・テーマ・WPコアを composer 管理することを前提に作られているため、更新に関する表示が管理画面上で表示されないようになっています。

#### HTTP_X_FORWARDED_PROTO
サーバーの HTTP_X_FORWARDED_PROTO 変数を確認してアクセスをhttpsに強制する仕組みが準備されているのですが、 croudfront などリバースプロキシを使用する構成では設定によって httpアクセスだと認識される時があります。AWSを使用する案件でこちらに遭遇したときはこれを強制的に https にしてしまう様に変更して対応しました。

> config/application.php

- //if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
- //}

#### DISALLOW_INDEXING
bedrock が mu-plugin(一番先に実行されるプラグインディレクトリ) に追加するプラグインを有効化します。robots.txt を変更し、デフォルトではプロダクション環境以外ではサイトをインデックスさせないようにしています。

## 3.環境構築
https://roots.io/bedrock/docs/server-configuration/

公開ディレクトリがプロジェクトディレクトリの ./web になるので、上記URLの通り設定が必要です。
- Docker などで環境構築する際やAWSなどサーバー構築する際は vhosts.conf や httpd.conf で公開ディレクトリを設定する。
- さくらサーバーなどでドメインの公開ディレクトリ設定をコントロールパネルで設定できる時は、[コンテンツ配置ディレクトリ]/web ディレクトリに設定すればOK。
- Xserverなど、公開ディレクトリを変更できない場合は、.htaccess を web/ ディレクトリに設置し、リライトする。

#### 環境変数の注意点
公式ドキュメントに記載されている 公開ディレクトリ(ドキュメントルート)を変更するhtaccessは下記の通り。これを /www/ に配置するだけで /www/ に https://example.com がホスティングされていた場合、 https://example.com へアクセスした時、 /www/web/ を参照する様にリライトされます。

RewriteEngine on

RewriteCond %{REQUEST_URI} !web/
RewriteRule ^(.*)$ /web/$1 [L]

このドキュメントを見ずに、Wordpressのリライトルールをコピーし、下記の様な形で設定し、.envファイルを流出させる事故を起こしてしまったことがありました。不正アクセスを行う人たちはまず ドメイン/.env は確認しに行くので、APIキーなどが含まれる場合、大事故になります。

環境変数を使用する場合、 envファイルのWEBアクセスの禁止はとても重要なセキュリティ項目になります。Bedrockの場合、WEBアクセスが行われる領域(web/)より上位のディレクトリにenvファイルがあることによってWEBアクセスができないように構成されているので、適切に設定する必要があります。

# 完全に良くない例
RewriteEngine on
RewriteBase /
RewriteRule ^$ web/ [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.+)$ web/$1 [L]

※ Wordpressのデフォルトのリダイレクト設定で自動で挿入される `RewriteCond %{REQUEST_FILENAME} !-f` 等はファイルへのアクセスはリダイレクトしない、というルールです。

## 4.プラグイン
プラグインはデフォルトで composer.json が wpackagist を参照する様に設定されているので、[wpackagist](https://wpackagist.org/) からプラグインを参照し、プラグインの任意のバージョンをクリックすればパッケージの場所が表示されます。

そちらをコピーして

% composer require wpackagist-plugin/mw-wp-form

と追加するコマンド実行を行うか、

> composer.json

{
    ...
    "require": {
        ... # パッケージを追加
        "wpackagist-plugin/mw-wp-form":"4.4.4",
        ...
    },
    ...
}

とそのまま貼り付けて追加してから `composer install` を行います。

### Advanced Custom Field Pro

ACF Pro はインストールに認証が必要になるため、wpackagist にはありません。
そのため、下記の様な方法で追加できます。

[公式ドキュメント](https://www.advancedcustomfields.com/resources/installing-acf-pro-with-composer/)

> auth.json

{
  "http-basic": {
    "connect.advancedcustomfields.com": {
      "username": [認証キー],
      "password": "https://localhost"
    }
  }
}

> composer.json

{
  ...
  "repositories": [
    ... # リポジトリを追加
    {
        "type": "composer",
        "url": "https://connect.advancedcustomfields.com"
    }
  ],
  "require": {
    ... # パッケージを追加
    "wpengine/advanced-custom-fields-pro": "^6.0"
  }
}

## 5.マルチサイトでの利用
Bedrock + Multisite だとWordpressアクティベート時に HOME に /wp がついてしまうので、手動で消す必要がある。

サブディレクトリ型では処理の検討は必要ないが、サブドメイン型の場合 /wp をつけるための処理を 追加する必要がある。

# composer require roots/multisite-url-fixer

## 6.Git

上記までを踏まえて、最低限下記の様なファイル群をGit管理する形になるかと思います。

> Bedrock ファイル

├── .env.example
├── phpcs.xml
├── wp-cli.yml
├── auth.json # ACF Pro を導入する場合
├── composer.json
├── composer.lock # インストールするファイルを強制する
├── config
│   ├── application.php
│   └── environments
│       ├── development.php
│       ├── staging.php
│       └── production.php # デフォルトでは追加されません。必要があれば。
└── web
    ├── app
    │   ├── mu-plugins # プロジェクトで独自の mu-pluginを使用しない場合は不要
                        * bedrock-disallow-indexing は　install時追加される
    │   └── themes
    ├── wp-config.php
    └── index.php

> Docker設定ファイル

├── docker-compose.yml
└── docker
    ├── apache2
    │   ├── Dockerfile
    │   ├── httpd-ssl.conf
    │   ├── httpd.conf
    │   ├── vhost.conf
    │── composer
    │   ├── Dockerfile
    └── php-fpm
        └── Dockerfile