WordPress Bedrock 入门

以下是 Alessandro Vendruscolo 的客座文章，他兴奋地写信给我，希望撰写一篇关于 WordPress 工具的客座文章，而我对此知之甚少：Bedrock。它不是主题，而是一种在考虑安全性和现代开发实践的情况下安装、配置和管理 WordPress 的方法。

Bedrock 是由 Roots 创建的一个开源项目，您可以将其用作 WordPress 项目的基础。

为什么您应该关心 Bedrock？让我们退一步，思考一下在 WordPress 项目中工作的一种典型方式。

经典 WordPress 工作流程

您可以在本地机器和生产服务器上下载并安装 WordPress。您可以为您的主题创建一个 Git 存储库。部署可以是主题的 FTP 传输或服务器上的 Git 拉取存储库。对于某些项目，您可能还希望将整个站点（甚至 WordPress 文件）也保存在 Git 中。

这存在一些问题

• 从生产环境更新 WordPress/插件可能会破坏您的生产站点
• 您必须手动跟踪 WordPress/插件版本
• 部署可能很麻烦
• 配置 WordPress 很困难，因为 wp-config.php 不能放在版本控制之下

以下是一个示例，说明我的意思。您在本地更新一个插件，因为您需要更新的插件提供的一些新功能。您根据该新功能编写代码。现在是部署的时候了。您

1. 在生产站点上安装或更新插件（确保版本相同！)
2. 编译资源
3. 更新远程服务器上的主题（使用任何部署方法）
4. 如果是一个新插件，请确保它已在生产站点上激活

这是一种相当手动的方法，并且可能容易出错。最重要的是，它会导致停机或致命错误。例如，您更新插件，但它不向后兼容，因此在部署完成之前会抛出错误。或者您先部署，然后站点会抛出错误，直到您更新插件。

进入 Bedrock

如果以上问题听起来像是您过去处理过的事情，那么您会喜欢 Bedrock。它带来了

• 由 Composer 跟踪的显式依赖项
• 使用 phpdotenv 进行轻松配置
• 使用 Capistrano 进行轻松的一键式部署

您最终将获得一个独立的 WordPress 项目，该项目将安装 WordPress 和所需插件的显式版本 (composer install)，这些版本可以轻松配置。所有配置都保存在 .env 文本文件中，并进行部署 (cap production deploy)。

更少的麻烦和更多的自动化！即使是引导新开发人员也更容易。

您还可以免费获得多阶段环境。您可以拥有一个用于本地工作的 development 配置，一个用于测试的 staging 配置，以及一个用于实时站点的 production 配置。您还可以定义自定义配置，例如 backup，您可以在其中在另一台服务器上拥有生产环境的 1:1 副本。

要求

以下是使用 Bedrock 的要求

• 您应该习惯在命令行上工作。
• 您需要服务器的 Shell 访问权限：如果您的站点托管在共享主机上，您可能无法使用¹。
• PHP >= 5.5
• 您需要在服务器上安装 Composer（安装说明）。
• 您需要在您的机器上拥有一个可用的 Ruby 和 gem 环境才能执行部署。
• 如果您计划使用 WP-CLI，则需要在本地和服务器上安装它。这不是必需的，但您稍后会看到它很有用（安装说明）。

这除了所有正常的 WordPress 服务器要求（如 MySQL）之外。

入门

让我们假设一个全新的 WordPress 项目。首先，您需要一个 Bedrock 的副本，您可以从其 存储库 中获取。

我应该克隆还是下载存储库？

Bedrock 的自述文件 告诉您克隆存储库，但在我看来，您最好下载它。如果这是您计划定期更新的内容，请使用克隆方式；如果这是您计划设置并忘记的内容，请使用下载方式。

保持 Bedrock 更新当然是一件好事（改进、安全等），但这可能很棘手。您可能需要手动挑选更改或尝试合并两个上游。由于它是一个起点，因此下载它意味着您可以设置一次并忘记它。

安装

现在您已下载存储库，您可以为项目初始化您自己的存储库。

wget https://github.com/roots/bedrock/archive/master.zip
unzip master.zip
rm master.zip
mv bedrock-master ~/Sites/example.dev
cd !$
git init

我将所有 Web 项目保存在主目录 (我在 OS X 上开发) 中的 Sites 文件夹中，并按名称对其进行索引。我使用 `.dev` 顶级域名，以便可以使用虚拟主机配置 nginx。这样，即使在本地工作时，我的配置也与实时网站几乎相同。（与使用 localhost 相比，额外的好处是：您可以获得一个新的环境来工作：cookie、本地存储、缓存的 URL 等与您之前使用过的任何其他站点不共享。）

在我的机器上，我使用此最小配置来指示 nginx 如何托管网站。请注意，根文件夹与项目不同。Bedrock 将所有公共文件放在 web 文件夹中。

server {
  listen 80;
  server_name example.dev;

  root /Users/MJ/Sites/example.dev/web;

  location / {
    try_files $uri $uri/ /index.php;
  }

  location ~ .php$ {
    try_files $uri =404;
    fastcgi_split_path_info ^(.+\.php)(/.+)$;
    include fastcgi.conf;
    fastcgi_intercept_errors on;
    fastcgi_pass unix:/tmp/php5-fpm.sock;
  }
}

现在我们需要运行一个命令来让魔法发生

composer install

如输出所示，Composer 将安装 composer.lock 文件中列出的依赖项，包括 WordPress 本身²。

那么，发生了什么？

如果您不熟悉 Composer，我将快速解释它是什么以及它是如何工作的。

Composer 是一个用 PHP 编写的工具，它允许您管理 PHP 依赖项（就像 Ruby gem、npm 模块、CocoaPods 等）。如今，所有语言都具有依赖项管理器。

您在 composer.json 文件中声明您需要的包，然后使用 约束 声明它们。拥有约束可以让您定义在运行 composer update 时 Composer 将如何更新它们。

例如，Bedrock 需要 WordPress 的显式版本（在撰写本文时为 4.5）和任何版本
大于 2 但小于 3 的 phpdotenv。

每次执行 composer update 时，Composer 都会尝试将您的包更新到允许的最新版本，并将该版本号写入 composer.lock 文件。

现在，当您运行 composer install（就像您之前所做的那样）时，它将无论如何都会安装该特定版本，从 composer.lock 文件中读取（这是使用 Composer 非常安全的原因，就像 gem 和 CocoaPods 一样，与 npm 不同，除非您使用 shrink-wrap 功能）。

如果您现在列出 web 和 web/wp 目录的内容，您将看到一些熟悉的内容：Composer 已将 wp-config.php 文件移动到 web，所有 WordPress 文件都在 web/wp 文件夹中。如果您检查该文件，您可以理解它为什么在那里。

我们已经准备就绪，现在是时候配置 WordPress 了。

将 `.env.example` 复制到 `.env` 并对其进行编辑

cp .env.example .env
vim .env

它会询问您

1. 你使用的数据库名称（我将使用 `example_development`）
2. 用于连接数据库的用户名（在我的机器上，只有一个 `root` 用户）
3. 该用户的密码
4. 数据库主机（`127.0.0.1` 或 `localhost` 均可）
5. 此安装的环境（`development` 即可，您可以设置任何您想要的：通常情况下，您有 `development`、`staging` 和 `production`）
6. WordPress 将用于构建 URL（以及其他用途）的主页 URL（我设置了 `http://example.dev`）
7. 管理员页面的 URL。保持原样，您将可以通过 `http://example.dev/wp` 访问 WordPress 管理页面。如果您更改此设置，则还需要相应地移动 `wp` 文件夹的内容
8. 您可以 [在线生成](https://roots.io/salts.html) 的授权密钥和盐值

保存文件后，您可以继续安装 WordPress（它需要在数据库中创建所有表！）。您可以通过访问 `http://example.dev/` 上的网站或使用 [WP-CLI](http://wp-cli.org) 来完成此操作

wp core install --url='http://example.dev' --title='Example' --admin_user='admin' --admin_password='enter' --admin_email='<admin_email>'

WordPress 已成功安装！

我们可以提交我们所做的更改（`git add . && git commit -m 'First commit'`）。

让我们回顾一下这个过程

1. 下载 Bedrock；
2. 运行 `composer install`；
3. 编辑 `.env` 文件；
4. 安装 WordPress（使用 `wp core install …` 命令自动完成）。

如果以后有其他开发人员加入团队，他们将克隆项目的仓库并从步骤 2 开始。

在项目中工作

至此，我们拥有了一个默认的 WordPress 安装，并且可以开始对其进行自定义！

如果我们检查文件夹结构，您可以看到 Bedrock 如何组织文件

.
├── config
│   ├── application.php
│   └── environments
│       ├── development.php
│       ├── production.php
│       └── staging.php
├── vendor
├── web
│   ├── app
│   │   ├── mu-plugins
│   │   ├── plugins
│   │   ├── themes
│   │   └── uploads
│   ├── wp
│   └── wp-config.php

• config：这是您配置 WordPress 的地方。这些文件无法从互联网访问，因为我们设置 nginx 从 `web` 文件夹提供文件。
  • config/application.php：此文件包含通常的 WordPress 配置，并旨在包含所有环境共有的基本设置。
  • config/environments/*：这些包含特定于环境的设置。例如，在生产环境中，它会禁用错误输出。
• vendor：由 Composer 管理的依赖项将安装在此处，除了 WordPress 插件和主题；如果您检查 `composer.json` 文件，您会看到这些类型的包将被移动到 `web/app/{mu-plugins,plugins,themes}/` 中。
• web：此目录中包含的文件是公开可用的
  — 只有必需的文件位于 `web` 文件夹中（请参见上面的 `config`）。
  • web/app：这是旧的 `wp-content` 文件夹。它已被重命名以更好地反映其内容（这也与其他框架约定相匹配，例如 Rails 和 Symfony）。这是您的插件和主题将最终存放的地方。
  • web/wp：整个 WordPress 包。这应该放在 `vendor` 中，但由于 WordPress 的限制而无法做到。
  • web/wp-config.php：此文件众所周知，但在 Bedrock 中它充当加载程序（它从 `config` 目录加载设置）。它需要保留在这里，因为 WordPress 核心对路径进行了硬编码。

配置和环境变量

如我们前面所见，我们在 `config` 目录下有多个配置文件，我们还有 `.env` 文件，我们在其中放置数据库的用户名/密码。

关键点在于：如果某些内容是敏感的（密码或外部服务访问密钥），则应将其放入 `.env` 文件中，并使用 `env('<name>')` 函数读取。敏感信息永远不会存储在您的 Git 仓库中（`.env` 文件被 Git 忽略），这是一个巨大的优势。它还允许您为每台机器定义不同的密码/密钥。想象一下，如果每个开发人员都必须生成他们的 Twitter 消费者密钥，或者必须为测试目的生成一个新的密钥：如果密钥存储在一个由 Git 跟踪的文件中，您必须记住不要将该文件添加到暂存区。

解决方案是将其添加到 `.env` 文件中

[…]
DB_PASSWORD=<password>
[…]

并在配置文件中读取该值

define('DB_PASSWORD', env('DB_PASSWORD'));

请记住，特定于环境的文件（`config/environment/`.php`）在主文件（`config/application.php`）之前加载。**这意味着您无法覆盖设置**。假设您对开发和暂存环境有相同的配置，但对生产环境有不同的配置。您可以

• 在每个环境文件中定义它（`development.php`、`staging.php`、`production.php` 等）。
• 将其放入 `.env` 文件中并在主应用程序（`application.php`）文件中定义它。

插件

如果您的插件在官方插件注册表中可用，您可以使用 Composer 和 [WordPress Packagist](https://wpackagist.org) 进行安装，后者是一个 Composer 仓库，它镜像了 WordPress 的官方插件和主题注册表。

Bedrock 已经添加了 wpackagist 的仓库，因此安装插件只需运行以下命令即可安装最新版本

composer require wpackagist-plugin/<name>
git add composer.json composer.lock
git commit -m 'Install <name> plugin'

插件名前缀为 `wpackagist-plugin/`，因此插件 [Memberful WP](https://wordpress.org/plugins/memberful-wp/) 变为 `wpackagist-plugin/memberful-wp`。

您可以为版本提供约束（前面的命令将使用 [^ 约束](https://getcomposer.org.cn/doc/articles/versions.md#caret)）。

composer require wpackagist-plugin/memberful-wp ~1.0
git add composer.json composer.lock
git commit -m 'Install Memberful plugin'

如果您手动编辑 `composer.json` 文件并运行 `composer install`，则可以实现相同的效果。

如果您的插件在官方注册表中不可用（如自定义插件或付费插件），您需要将其放入 `web/app/plugins` 并将其从忽略列表中删除

mv ~/Downloads/my-plugin web/app/plugins/
echo '!/web/app/plugins/my-plugin' >> .gitignore
git add .gitignore web/app/plugins/my-plugin
git commit -m 'Add my AWESOME plugin'

更好的是，如果您有插件的 Git 仓库，您可以直接使用 Composer。将以下内容添加到 `composer.json` 文件的 `repositories` 数组中

{
  "type": "git",
  "url": "<repository url>"
}

该仓库需要在其根目录中包含一个 `composer.json` 清单文件，例如

{
  "name": "macstories/wp-push-plugin",
  "description": "MacStories' implementation of Safari Push Notifications",
  "type": "wordpress-plugin",
  "license": "proprietary",
  "require": {
  "php": ">=5.5",
  "composer/installers": "~1.0.12"
  }
}

设置好以上所有内容后，您可以运行 `composer require macstories/wp-push-plugin` 来安装它。Composer 期望该仓库至少有一个 Git 标签。

现在我们已经安装了插件，我们可以启用它。转到 WordPress 管理页面或再次使用 [WP-CLI](http://wp-cli.org)

wp plugin activate memberful-wp

这次我们不需要 `wpackagist-plugin` 前缀，因为 WordPress 不了解 Composer。

如果插件需要创建文件或文件夹，则应将其添加到 `.gitignore` 文件中，将其忽略。一个例子是 WP Super Cache：它创建了两个包含设置的 PHP 文件。

如果插件要求您修改 `wp-config.php` 文件，请将这些新设置移动到 `application.php`（或特定于环境的文件）中，如前所述。

主题

主题的工作方式与插件相同，但有两个区别

1. 它们的目录是 `web/app/themes`；
2. Composer 的供应商名称是 `wpackagist-theme`。

如果您使用的是官方 WordPress 注册表中可用的主题，则可以使用 Composer 安装它

composer require wpackagist-theme/activello

如果您要开发自己的主题，请在 `web/app/themes` 下创建其文件夹，然后您就可以开始了。无需将其从 `.gitignore` 文件中排除。

在您的主题中，您可以查询当前环境并利用它。例如，在 [MacStories](https://www.macstories.net/)（我使用 Bedrock 开发的一个网站）上，我不在 `development` 中包含最小化的资源

$main = '';
if (WP_ENV === 'development') {
  $main = macstories_asset_url( '/dist/main.css' );
} else {
  $main = macstories_asset_url( '/dist/main.min.css' );
}
// use the $main variable

另一个区别是分析。我仅在生产环境中包含 Mint Analytics，使用类似于上述的方法。Google Analytics 即使在开发或暂存环境中也可用，但这两个环境使用不同的网站 ID，因此更容易执行测试。

升级 WordPress

在撰写本文时，WordPress 版本为 4.5.2。假设发布了 4.5.3 版本。我们需要更改所需的版本。您可以编辑 `composer.json` 文件并运行 `composer install`，或者您可以只发出以下命令

composer require johnpbloch/wordpress 4.5.1

它将更新 `composer.json` 文件（以及锁定文件，因为我们升级了一个依赖项）并安装依赖项。

通常，在每次 WordPress 更新后，都需要执行数据库模式升级，您可以通过访问 WordPress 管理页面来执行此操作。但这很繁琐，因此 WP-CLI 有一个执行此操作的命令

wp core update-db

在升级数据库模式时，还需要注意另一件事：如果您使用 Web UI 执行此操作，并且操作花费的时间过长，则可能会遇到 HTTP 超时。WP-CLI 跳过 HTTP 层并通过从命令行运行 PHP 执行操作，这样就不会有任何超时问题。

插件升级

升级插件类似于升级 WordPress：如果您使用 Composer 安装了它们，则使用 Composer 升级它们。

您可以运行 `composer require wpackagist-plugin/<name> <version>` 将给定插件升级到特定版本，或者，更好的是，使用 `composer update` 将每个包更新到满足 `composer.json` 文件中设置的约束的最新版本。

当您 `composer require <package>` 某些内容（未指定版本）时，Composer 默认情况下会使用 `^` 约束：运行 `composer update` 将把包更新到最新的非大版本更新。非常简单。

项目部署

此时，您应该在您的机器上拥有一个可运行的 WordPress 网站。但这几乎毫无用处，除非您的机器连接到互联网。

Capistrano 是用于部署的事实上的工具，您可以使用它来部署 WordPress 网站。

什么是 Capistrano？

Capistrano 是一个用 Ruby 编写的强大工具，主要³ 用于执行部署。最初它是为了部署 Ruby on Rails Web 应用程序而诞生的，但后来它发展到可以部署任何类型的 Web 应用程序，并带有插件来运行自定义任务或连接到外部服务。

互联网上有大量的指南和许多会议演讲，但概括地说：Capistrano 将使用 SSH 连接到您的服务器，然后按照 此流程 更新服务器上的存储库并运行任务。您在每个任务上添加钩子来执行您需要的操作。

它旨在与 SSH 密钥配合使用（因此您不必使用密码），并且应该以非特权用户的身份连接到服务器。它可以发出 `sudo` 命令，但是如果您需要这样做，那么您的设置可能存在问题。您可以在 身份验证和授权 文档页面上了解更多相关信息。我使用 SSH 代理转发，以便 Capistrano 能够使用我的本地 SSH 密钥从 Git 服务器拉取代码。

在服务器上，Capistrano 通过在您设置为部署目标的目录中保留多个目录来工作

.
├── current -> releases/20160420173015
├── releases
│   ├── 20160420173015
│   ├── 20160412113015
├── repo
└── revisions.log
├── shared

• current：这是指向当前部署版本的符号链接（最新版本或如果回滚则为先前版本）。
• releases：每次您部署时，Capistrano 都会创建一个带有时间戳的新文件夹。您可以配置要保留的版本数量，Capistrano 将清理旧版本（默认为保留 5 个版本）。
• repo：Capistrano 在服务器上保留存储库并在服务器上检出正确的版本——没有任何内容从您的机器传输到远程服务器。
• revisions.log 在每次部署或回滚后，此日志将被更新。
• shared：包含必须在版本之间共享的文件和文件夹，例如用户上传的文件。

每个部署都在隔离环境中运行，并在 `releases` 文件夹中拥有自己的文件夹。如果出现错误，则当前版本不会发生任何变化。完成后，Capistrano 将更新指向刚刚部署版本的符号链接。

在您的项目中，您将有一个 `Capfile` 用于需要运行的任务（请参阅流程中的示例）和一个包含设置的 `deploy.rb` 文件。

如果不想使用 Capistrano

Bedrock 支持 Capistrano，但这不是必需的。如果 Capistrano 对您没有吸引力，或者您更喜欢使用其他工具，或者更喜欢根本不使用任何工具，您可以这样做。

唯一的要求是在服务器上运行 `composer install`，以便 Composer 可以下载 WordPress、插件和您的网站所需的任何其他依赖项。否则，您将拥有一个类似僵尸的网站，只有应用程序代码，但没有应用程序本身。

使用 Capistrano 部署

好的，我让你尝试使用 Capistrano，让我们继续吧！

Roots 团队（Bedrock 背后的团队）创建了一个 单独的存储库 来托管 Bedrock 的 Capistrano 集成。这是因为 Capistrano 不是 Bedrock 的必需组件，但可以随时添加。

在项目根目录中创建或编辑 `Gemfile` 文件，并粘贴以下内容

source 'https://rubygems.org.cn'

group :deployment do
  gem 'capistrano', '~> 3.4'
  gem 'capistrano-composer'
  gem 'capistrano-wpcli'
end

现在运行 `bundle` 以安装 gem。这与 Roots 的设置略有不同，因为我们将这些 gem 分组到 `deployment` 组中，并安装了 `WP-CLI` 扩展。

Capistrano 将由 Bundler 安装，并像我们之前对 WordPress 和 Composer 所做的那样，将其视为依赖项。这很有用，因为每个项目都可以使用不同版本的 Capistrano，并且不会依赖于全局安装的版本。此外，如果团队中有多个开发人员，则本地安装（并同步）的 Capistrano 版本可确保一切尽可能顺利⁴。

提交 `Gemfile` 和 `Gemfile.lock`——就像 Composer 一样。

git add 'Gemfile*' && git commit -m 'Install Capistrano'

现在我们需要设置 Capistrano。Capistrano 的配置将保存在 Git 存储库中。您必须从 存储库 中复制 `Capfile` 文件和 `config` 目录的内容。这相当于运行 `bundle exec cap install` 并编辑 Capistrano 的配置文件。

由于我们还安装了 WP-CLI 插件，因此我们必须在 `Capfile` 中引用它。在引用 Composer 插件之后添加以下行

require 'capistrano/wpcli'

编辑 `config/deploy.rb` 并设置 `:application` 和 `:repo_url` 变量，并删除 `:deploy_to` 行。如果需要，您也可以在此处更改其他设置。有很多代码注释，并且 文档 非常棒。

:linked_files 和 `:linked_dirs` 变量非常重要。如果您还记得之前的内容，Capistrano 将在服务器上创建一个 `shared` 文件夹（在部署之间共享）。默认情况下，我们将共享 `.env` 文件和 `web/app/uploads` 文件夹。

`.env` 文件包含应用程序设置，需要共享才能使站点正常工作，还需要共享，因为此文件不在版本控制之下。`web/app/uploads` 文件夹是旧的 `wp-content/uploads` 文件夹，需要共享，否则上传的文件将仅存在于某个版本中。

您可能可以忽略 `config/deploy.rb` 文件的其余部分。第 22 行之后定义了两个自定义任务。第一个是空的，默认情况下处于禁用状态。例如，它可以用于重新启动 Web 服务器。如果您在部署后需要重新启动某些内容，请更新任务并启用它。
第二个任务由 Roots 团队添加，默认情况下处于禁用状态。它用于更新 WordPress 的 `stylesheet_root` 和 `template_root` 选项。我从未有过更改它们的理由。

编辑 `config/deploy/<stage>.rb` 文件以设置每个阶段的设置。

您必须更新 `server` 设置，因为生产环境可能位于与暂存环境不同的服务器上。

我们将 `:deploy_to` 路径设置移到此处，因为您的暂存路径可能与生产路径不同。您还可以覆盖在主 `deploy.rb` 文件中设置的设置。这些文件的原理与 Bedrock 环境文件相同。

现在我们配置了 Capistrano，并且应该可以正常工作了。Capistrano 带有一个检查任务，它会检查一切是否正常。

运行以下命令执行检查

bundle exec cap staging deploy:check

Capistrano 将

1. 以您定义的用户身份登录服务器（确保 SSH 连接正常）
2. 列出存储库远程文件（以便您知道 Capistrano 能够连接并对 Git 服务器进行身份验证）
3. 创建目录结构
4. 创建链接文件夹
5. 检查链接文件

以下是一个可能出现的 Capistrano 错误示例

ERROR 链接文件 /path/to/:deploy_to/shared/.env 在 <host> 上不存在

创建该文件（您可以使用 `scp .env <user>@<host>:<value of :deploy_to>/shared/.env` 将您的开发 `.env` 文件上传到服务器。此时，我们关注的是拥有该文件，而不是拥有正确的文件）完成后，再次检查一切是否正常。万岁！它可以工作了！

推送您的更改（否则 Capistrano 将克隆一个空或旧的存储库），并运行以下命令执行实际部署

bundle exec cap <stage> deploy

这是您每次想要部署网站时都需要记住并运行的命令。

配置远程 WordPress

您需要更新远程服务器上的 `.env` 文件，以设置正确的数据库信息，最重要的是 WP_ENV 和 WP_HOME 设置。

如果您部署到生产环境，则必须为 WP_ENV=production（我不知道您的 WP_HOME 值）。

您的 Web 服务器需要从 current 文件夹提供内容，因此，如果您在本地为 nginx 设置了以下内容

root /Users/MJ/Sites/example.dev/web;

在服务器上，您需要按以下方式更新它

root <value of :deploy_to>/current/web;

在远程服务器上安装 WordPress 只需执行与在本地计算机上执行的操作相同的操作即可。您可以使用 Web UI 或使用 WP-CLI，甚至可以在 Capistrano 内部使用。

当您部署新版本并在该版本中安装新插件时，可以使用以下命令启用插件

bundle exec cap <stage> wpcli:run['plugin activate <name>']

执行数据库迁移

bundle exec cap <stage> wpcli:run['core update-db']'

钩子

您可以为 Capistrano 定义自定义任务以运行，但在执行此操作之前，请搜索现有的解决方案。Capistrano 带有许多官方插件，例如 Bundler、npm 和许多其他 社区驱动的插件。

例如，假设您有一个编译 Sass 资产的构建脚本。由于我们之前讨论过的优点，您应该在 Gemfile 中使用以下命令引入 Sass：

gem 'sass', '~> 3.4'

现在，我们在部署时需要做两件事

1. 确保安装了 sass gem
2. 运行我们自己的构建脚本

Capistrano-bundler

第一步很容易实现：我们将通过将此行添加到 :deployment 组中来引入 capistrano-bundler gem

gem 'capistrano-bundler', '~> 1.1.2'

之后，您运行 bundle 来安装 gem，并编辑 Capfile 以引入它

require 'capistrano/bundler'

完成。每次我们部署时，Capistrano 都会在 deploy:updated 任务之后在服务器上运行 bundle install。

如果需要，可以在 `deploy.rb` 文件中设置 :bundle_without 变量

set :bundle_without, %w{deployment development test}.join(' ')

这样做将排除这些组的 gem 不被安装。Bundler 将安装更少的 gem（我们不需要！），并且我们的部署将更快。

运行自定义脚本

我不知道您的构建脚本是如何构建的。我喜欢 make，但您可以使用任何您想要的：shell 脚本、npm 脚本、Grunt/Gulp 任务等。无论如何，我们都必须运行它们，否则我们的站点将没有资产。

我们可以轻松地创建一个自定义任务。在 lib/capistrano/tasks 中创建您的 .cap（例如 make.cap）文件，以便自动加载它（否则您需要从 Capfile 中显式引入），内容如下

namespace :make do
  desc "Runs make all"
  task :all do
  on roles :all do
    within release_path do
    execute :make
    end
  end
  end

  before 'deploy:updated', 'make:all'
end

Capistrano 将在 deploy:updated 任务之前运行我们的任务。由于我们使用了 within release_path do … 部分，因此此命令将在 Capistrano 正在部署的正确的 release/ 目录中执行。

查看 Capistrano 的文档 以了解更多信息。热提示：请确保在任何参数之前使用冒号（这与 shell 转义有关）。

添加新阶段

Bedrock 带有三个默认环境

1. 开发（仅限 Bedrock）
2. 登台（Bedrock 和 Capistrano）
3. 生产（Bedrock 和 Capistrano）

如果需要，您可以添加一个新的阶段。一个例子可能是 100% 等于 production 的 backup 环境。数据库可以定期同步，或者您可以设置 MySQL 复制功能。如果发生故障，您可以更新您的 DNS 以指向不同的主机，并且没有人会注意到任何事情。

添加新阶段

1. 为 Bedrock 创建一个新环境：`config/environment/backup.php`（您可以复制现有环境并更新所需内容）
2. 创建 Capistrano 阶段配置：`config/deploy/backup.rb`（同样使用现有配置作为基础）
3. 设置服务器（Web 服务器、数据库等）
4. 部署项目（bundle exec cap backup deploy:check 和 bundle exec cap backup deploy）
5. 确保 `.env` 文件包含 WP_ENV=production

将现有项目迁移到 Bedrock

在本教程中，我们创建了一个新项目，但 Bedrock 可用于现有项目。

如果您有一个现有的 WordPress 网站并希望将其转换为 Bedrock，您可以将其视为一个新项目

1. 安装 Bedrock
2. 配置 WordPress
3. 恢复您的主题
4. 使用 Composer 安装插件

如果您没有修改 WordPress 核心文件，则已完成。如果您修改了 WordPress 核心文件，则需要将您的自定义 WordPress 版本保存在版本控制下（您将失去易于 Composer 驱动的 WordPress 更新，但仍然拥有所有其他功能）。

注意事项和技巧

一些技巧

1. 请记住，如果[某事物]创建了[其他事物]，则不应管理它。例如，这包括：插件创建的文件、包管理器安装的文件、用户上传的文件等——不要将它们添加到 git 中。如果您忽略了它们，它们很有可能应该出现在 Capistrano 的 linked_files 设置中。
2. 不要将敏感信息存储在 git 中。
3. 不要忘记在部署之前 git push：我多次部署了相同的版本，然后才意识到我忘记了推送（在服务器上，Capistrano 一遍又一遍地拉取相同的版本）。
4. 尽可能使用 WP-CLI：它更快，可以由 Capistrano 执行。示例包括
   • wp plugin activate <name>
   • bundle exec cap <stage> wpcli:run['plugin activate <name>']
   • wp core update-db
   • bundle exec cap <stage> wpcli:run['core update-db']
5. 您可以将 Capistrano 分支（config/deploy.rb）设置为 set :branch, ENV['BRANCH'] || :master：这样做可以让您轻松地通过执行 BRANCH=my-feature bundle exec cap <stage> deploy 来部署分支（请记住推送，请参阅技巧 #3）；如果您没有提供 BRANCH= 环境变量，Capistrano 将回退到部署 master。
6. 使用 Slackistrano，您可以在每次成功部署后发布到 Slack 频道。

总结

希望您能遵循并喜欢本教程。我鼓励您在本地计算机上创建一个新站点，以便有一些内容可以进行实验。

概括地说，以下是 Bedrock 带来的优势

• 自包含的存储库
• 轻松部署
• 轻松的多阶段支持
• 环境之间的一致性更高
• 配置文件与其他所有内容的分离

恭喜您完成本教程。如果教程很长且很难，我表示歉意。它绝对不适合初学者！希望在学习过程中，您学习了一些新的工具，并提高了对所有不同活动部件的理解。

在我看来，以这种方式工作的好处是值得的。现在去创造一些美好的东西吧！

---

[^1]：这并不是因为您无法 ssh @（某些主机允许这样做），而是因为您无法安装某些必需的软件——如果您使用的是在服务器上运行以构建资产的脚本，那么您可能没问题。

[^2]：不幸的是，目前还没有通过 Composer 分发的 WordPress 正式版本。Bedrock 使用 此分支，每 15 分钟同步一次。

[^3]：事实上，您可以使用 Capistrano 部署任何您想要的东西：您不限于 Web 应用程序，如果对您有意义，您可以将 iOS 应用程序部署到远程服务器。

[^4]：稍后您将看到以 bundle exec 为前缀的 cap 命令：这样做可以确保使用本地 gem 而不是全局安装的 gem（可能不存在）。您应该对 Sass 或任何其他 gem 执行相同的操作。