README

这是 Bedrock 的分支，具有默认的 Vagrant 设置。Bedrock 是一个现代 WordPress 堆栈，可以帮助您使用最佳的开发工具和项目结构开始。

快速入门

运行 composer create-project kanedo/bedrock <path>（更多详细信息请参阅 安装/使用）运行 cp .env.example .env 并修改以满足您的需求 运行 vagrant up

功能

• 使用 Composer 进行依赖管理
• 使用 Capistrano 自动部署
• 更好的文件夹结构
• 使用特定于环境的文件轻松配置 WordPress
• 使用 Dotenv 管理环境变量
• 使用 Vagrant 和 Ansible（GitHub 上的 bedrock-ansible）轻松创建服务器环境

Bedrock 是为了作为您分支和修改以适应您需求的基础而设计的。它是可删除键友好的，您可以删除或修改它的任何部分。您还希望使用针对您的网站/公司特定的设置来自定义 Bedrock。

Bedrock 背后的许多理念都受到了 Twelve-Factor App 方法的启发，包括针对 WordPress 的特定版本 WordPress specific version。

注意：虽然这是来自 Roots starter theme 的人的项目，但 Bedrock 与 Roots 无关，并且可以与任何主题一起使用。

要求

• Git
• PHP >= 5.3.2（用于 Composer）
• Ruby >= 1.9（用于 Capistrano）
• Vagrant

如果您不打算使用某个部分，那么也不需要其要求。不使用 Capistrano 进行部署？那么不用担心 Ruby，例如。

安装/使用

有关以下步骤的更多详细信息，请参阅 文档。

使用 create-project

Composer 的 create-project 命令将自动将 Bedrock 项目安装到目录中并运行 composer install。

安装后的脚本将自动将 .env.example 复制到 .env，并提示您生成密钥并将其附加到您的 .env 文件中。

注意：要无提示生成密钥，请以 -n（非交互式）运行 create-project。您还可以在您自己的分支下 composer.json 的 config 中更改 generate-salts 设置。默认值为 true。

要完全跳过脚本，可以以 --no-scripts 运行 create-project 以禁用它。

1. 运行 composer create-project roots/bedrock <path>（path 是要安装的文件夹）
2. 编辑 .env 并更新环境变量

• DB_NAME - 数据库名称
• DB_USER - 数据库用户
• DB_PASSWORD - 数据库密码
• DB_HOST - 数据库主机（默认为 localhost）
• WP_ENV - 设置环境（development、staging、production等）
• WP_HOME - WordPress 主页的完整URL（http://example.com）
• WP_SITEURL - 包括子目录的WordPress的完整URL（http://example.com/wp）

1. 添加主题
2. 在 http://example.com/wp/wp-admin 访问WP Admin
3. 将您的Nginx或Apache vhost设置到 /path/to/site/web/（使用Capistrano时为/path/to/site/current/web/）

手动操作

1. 克隆/Fork仓库
2. 运行 composer install
3. 将 .env.example 复制到 .env 并更新环境变量

• DB_NAME - 数据库名称
• DB_USER - 数据库用户
• DB_PASSWORD - 数据库密码
• DB_HOST - 数据库主机（默认为 localhost）
• WP_ENV - 设置环境（development、staging、production等）
• WP_HOME - WordPress 主页的完整URL（http://example.com）
• WP_SITEURL - 包括子目录的WordPress的完整URL（http://example.com/wp）

1. 添加主题
2. 在 http://example.com/wp/wp-admin 访问WP Admin
3. 将您的Nginx或Apache vhost设置到 /path/to/site/web/（使用Capistrano时为/path/to/site/current/web/）

使用Capistrano进行部署吗？

使用Capistrano进行部署

所需Gems

• capistrano (> 3.1.0)
• capistrano-composer

这些可以通过 gem install <gem name> 手动安装，但强烈建议您使用 Bundler 来管理它们。Bundler基本上是PHP的Composer的Ruby版本。就像Composer管理PHP包/依赖项一样，Bundler管理Ruby gems/依赖项。Bundler自身是一个Gem，可以通过 gem install bundler 安装（可能需要sudo权限）。

此仓库根目录下的 Gemfile 指定了所需的Gems（就像 composer.json）。一旦安装了Bundler，运行 bundle install 以安装 Gemfile 中的Gems。使用Bundler时，您需要在 cap 命令前添加 bundle exec 前缀，如下所示（这确保您没有使用系统Gems，这可能导致冲突）。

有关为服务器设置SSH密钥认证的最佳方式，请参阅https://capistrano.ruby-lang.org.cn/documentation/getting-started/authentication-and-authorisation/（无密码且安全的部署）。

部署步骤

1. 编辑您的 config/deploy/ 阶段/环境配置以设置角色/服务器和连接选项。
2. 在第一次部署之前，运行 bundle exec cap <stage> deploy:check 以创建必要的文件夹/符号链接。
3. 将您的 .env 文件添加到远程服务器上的 deploy_to 路径的 shared/ 中，用于您使用的所有阶段（例如：/srv/www/example.com/shared/.env）
4. 运行正常部署命令：bundle exec cap <stage> deploy
5. 享受一键部署！

• 在 config/deploy/ 中编辑阶段/环境配置以设置角色/服务器和连接选项。

文档

文件夹结构

├── Capfile
├── composer.json
├── config
│   ├── application.php
│   ├── deploy
│   │   ├── staging.rb
│   │   └── production.rb
│   ├── deploy.rb
│   ├── environments
│   │   ├── development.php
│   │   ├── staging.php
│   │   └── production.php
│   └── application.php
├── Gemfile
├── vendor
└── web
    ├── app
    │   ├── mu-plugins
    │   ├── plugins
    │   └── themes
    ├── wp-config.php
    ├── index.php
    └── wp

Bedrock的组织结构与将WordPress放入其自己的子目录类似，但有一些改进。

• 为了不在webroot中暴露敏感文件，Bedrock将所需内容移动到 web/ 目录中，包括打包的 wp/ 源和 wp-content 源。
• wp-content（或可能是仅为 content）已重命名为 app，以更好地反映其内容。它包含应用程序代码，而不仅仅是“静态内容”。它还与Symphony和Rails等其他框架相匹配。
• wp-config.php 仍然位于 web/ 中，因为它由WP需要，但它只起加载程序的作用。实际的配置文件已移动到 config/ 以实现更好的分离。
• Capistrano配置也位于 config/ 中，以保持一致性。
• vendor/ 是Composer管理的依赖项安装的地方。
• wp/ 是WordPress核心所在的地方。它也由Composer管理，但由于WP的限制，不能放在 vendor 之下。

配置文件

根 web/wp-config.php 由WordPress需要，只用于加载其他主要配置。不应向其中添加其他内容。

config/application.php 是主要的配置文件，其中包含通常在 wp-config.php 中包含的内容。基础选项应该在那里设置。

对于特定环境的配置，请使用 config/environments 目录下的文件。默认情况下有 development、staging 和 production，但这些可以是您需要的任何内容。

环境配置必须在主 application 配置之前进行，因此环境配置中的任何内容都将优先于 application。

注意：您不能在 PHP 中重新定义常量。因此，如果您在 application.php 中有一个基础设置，并希望在例如 production.php 中覆盖它，您有几个选择

• 删除基础选项，并确保在每个需要的环境中定义它
• 只有当它尚未定义时，才在 application.php 中定义常量。

不想这么做吗？

您将失去定义特定于环境的设置的能力。

• 将所有配置移动到 wp-config.php
• 手动处理特定于环境的选项
• 删除 config 目录

环境变量

Bedrock 尽可能地将配置与代码分离，并使用环境变量来实现这一点。好处是有一个单独的位置（.env）来保存数据库或其他第三方凭证等设置，这些设置不会提交到您的存储库中。

PHP dotenv 用于加载 .env 文件。然后，所有变量都可以通过 getenv、$_SERVER 或 $_ENV 在您的应用程序中使用。

数据库

  # Database Configuration
  DB_NAME=database_name
  DB_USER=database_user
  DB_PASSWORD=database_password
  DB_HOST=localhost

WordPress 环境

  ########################
  # WP Env configuration #
  ########################
  WP_ENV=development
  WP_HOST=example.dev
  WP_HOME=http://example.dev
  WP_SITEURL=http://example.dev/wp
  WP_SITE_TITLE="Test Site"
  WP_SITE_ADMIN_NAME=admin
  WP_SITE_ADMIN_PW=vagrant
  WP_SITE_ADMIN_EMAIL=admin@example.com

主题单元测试

要从 wptest.io 安装单元测试数据，请设置

  WP_TEST=true

插件脚手架

如果您开发插件并想使用 wp-cli 的脚手架，请将 WP_DEV_PLUGIN 设置为 true，并使用 WP_DEV_PLUGIN_NAME 配置您的插件别名。默认情况下，wp-cli 安装单元测试。要防止这种情况，请将 WP_DEV_PLUGIN_TEST 设置为 true。

  # WP_DEV_PLUGIN=true
  # WP_DEV_PLUGIN_NAME=plugin-name
  # WP_DEV_PLUGIN_TEST=true

不想这么做吗？

您将失去配置和代码之间的分离，并可能将安全凭证置于风险之中。

• 从 composer.json 的依赖项中删除 dotenv
• 从根目录删除 .env.example 文件
• 从 wp-config.php 中删除 require_once('vendor/autoload.php');
• 将所有 getenv 调用替换为您想设置这些值的任何方法

Composer

Composer 用于管理依赖项。Bedrock 将任何第三方库视为依赖项，包括 WordPress 本身以及任何插件。

请参阅这两篇博客以获取更详细的文档

• 使用 Composer 与 WordPress
• 使用 Composer 的 WordPress 插件

屏幕录像 ($): 使用 Composer 与 WordPress

插件

WordPress Packagist 已在 composer.json 文件中注册，因此可以从 WordPress 插件目录 轻松地添加任何插件。

要添加插件，请将其添加到 require 指令下或从命令行使用 composer require <namespace>/<packagename>。如果是来自 WordPress Packagist，则命名空间始终为 wpackagist-plugin。

示例："wpackagist-plugin/akismet": "dev-trunk"

每次添加新插件或更新 WP 版本时，请运行 composer update 以安装新包。

plugins 和 mu-plugins 默认情况下被 Git 忽略，因为 Composer 管理它们。如果您想向这些文件夹添加由 不是 Composer 管理的内容，您需要更新 .gitignore 以将其列入白名单。

!web/app/plugins/plugin-name

注意：一些插件可能会在其指定的作用域之外创建文件或文件夹，或者甚至修改 wp-config.php 以及 app 目录中的其他文件。这些文件应添加到您的 .gitignore 文件中，因为它们由插件本身管理，这些插件是通过 Composer 管理的。需要修改 wp-config.php 的任何更改应移动到 config/application.php。

更新 WP 和插件版本

更新您的 WordPress 版本（或任何插件）只需更改 composer.json 文件中的版本号。

然后运行 composer update 将拉取新版本。

主题

主题也可以由 Composer 管理，但只有在以下两种条件下才应该这样做

1. 您使用的是不会进行任何修改的父主题
2. 您希望将主要主题分离出来并作为独立包使用

在大多数情况下，我们不推荐进行 #2，而是将您的主题作为应用程序仓库的一部分保留。

就像插件一样，WPackagist 维护了 WP 主题目录的 Composer 镜像。要要求一个主题，只需使用 wpackagist-theme 命名空间。

不想这么做吗？

Composer 集成是 Bedrock 的最大部分，因此如果您打算移除它，使用 Bedrock 就没有太大的意义。

Capistrano

Capistrano 是一款远程服务器自动化和部署工具。它将允许您通过一条命令部署或回滚您的应用程序。

• 部署: cap production deploy
• 回滚: cap production deploy:rollback

Composer 支持是内置的，因此当您运行部署时，将自动运行 composer install。Capistrano 有一个很棒的 部署流程，您可以挂钩并扩展它。

它是用 Ruby 编写的，因此如果您想使用它，需要在 本地 上安装它。Capistrano 最近被重写为完全与语言无关，因此如果您之前因为它过于侧重于 Rails 而将其排除在外，那么请再次看看它。

屏幕录像 ($): 使用 Capistrano 部署 WordPress

不想这么做吗？

您将失去一条命令部署以及与 Composer 的内置集成。您还需要另一种部署方法。

• 移除 Capfile、Gemfile 和 Gemfile.lock
• 移除 config/deploy.rb
• 移除 config/deploy/ 目录

wp-cron

Bedrock 通过 define('DISABLE_WP_CRON', true); 禁用了内部 WP Cron。如果您保留此设置，您需要手动在 crontab 文件中设置一个像以下这样的 cron 作业

*/5 * * * * curl http://example.com/wp/wp-cron.php

WP-CLI

Bedrock 与 WP-CLI 一样，就像其他任何 WordPress 项目一样。之前我们将在 composer.json 文件中将 WP-CLI 作为依赖项要求。这已被删除，因为 WP-CLI 现在推荐使用 phar 文件全局安装它。这也导致了冲突，如果您尝试使用全局安装。

wp 命令将自动识别 Bedrock 的子目录安装，只要您从项目目录（或更深层次）中运行命令。Bedrock 包含一个 wp-cli.yml 文件，将 path 选项设置为 web/wp。使用此配置文件进行任何进一步 配置。

待办事项

• 基本数据库同步/复制解决方案

贡献

欢迎每个人为改进此项目做出贡献。请点击这里了解如何贡献。您可以通过以下几种方式做出贡献：

• 报告问题（请阅读问题指南）
• 建议新功能
• 编写或重构代码
• 修复问题
• 在论坛上回答问题

支持

使用Roots Discourse论坛提问并获得支持。