README

该仓库是一个参考实现和起点，用于利用 Composer、持续集成（CI）、自动化测试和 Pantheon 的现代 WordPress 工作流程。虽然这是一个好的起点，但您仍需要根据您的项目自定义和维护 CI/测试设置。

此仓库应一次性通过 Terminus Build Tools 插件 进行复制，但也可以用作模板。它不应直接克隆或分叉。

Terminus Build Tools 插件将为新项目搭建框架，包括

• Git 仓库
• 免费的 Pantheon 沙盒站点
• 持续集成配置/凭证设置

有关创建新项目的更多详细信息和说明，请参阅 Terminus Build Tools 插件。

重要文件和目录

/web

由于 pantheon.yml 中的配置，Pantheon 将从 /web 子目录提供服务。这对于基于 Composer 的工作流程是必要的。将您的网站放在此子目录中还可以让您在您的仓库中存储与您的项目相关的测试、脚本和其他文件，而不会污染您的 Web 文档根目录或从 Pantheon 上可访问。如果您的版本控制项目是公开的，它们仍然可以从您的版本控制项目中访问。有关详细信息，请参阅 pantheon.yml 文档。

/web/wp

即使在 /web 目录中，您也可能发现其他目录和文件与默认 WordPress 安装的位置不同。WordPress 允许将 WordPress 核心安装在它自己的目录中，这在使用 Composer 安装 WordPress 时是必要的。

有关关键设置，例如 WP_SITEURL 的详细信息，请参阅 /web/wp-config.php，这些设置必须更新，以便 WordPress 核心在重新定位的 /web/wp 目录中正常工作。仓库中目录的整体布局受到了 Bedrock 的启发，但并不完全相同。

composer.json

此项目使用 Composer 管理第三方 PHP 依赖项。

应使用 composer.json 的 require 部分来指定您的 Web 项目需要的任何依赖项，即使是那些可能仅在非生产环境中使用的依赖项。所有 require 依赖项都将推送到 Pantheon。

应使用 require-dev 部分来指定不是 Web 应用程序的一部分但构建或测试项目所必需的依赖项。一些例子包括 php_codesniffer 和 phpunit。Dev 依赖项不会部署到 Pantheon。

如果您只是浏览此 GitHub 仓库，您可能看不到上述某些目录，例如 web/wp。这是因为 WordPress 核心和其插件是通过 Composer 安装的，并在 .gitignore 文件中被忽略。

使用自定义的、适用于 Pantheon 的 WordPress Composer 版本 作为 WordPress 核心的源。

第三方WordPress依赖项，如插件和主题，通过composer.json添加到项目中。composer.lock文件记录了依赖的确切版本。Composer installer-paths用于确保WordPress依赖项被下载到适当的目录。

非WordPress依赖项下载到/vendor目录。

.ci

此.ci目录是存储所有在持续集成上运行的脚本的目录。特定提供者的配置文件，如.circle/config.yml和.gitlab-ci.yml，都使用这些脚本。

根据其功能，脚本组织在.ci的子目录中：build、deploy或test。

构建脚本.ci/build

构建适合部署的工件的操作步骤。根据需要，您可以在此处添加其他构建脚本，例如安装Node依赖项。

• .ci/build/php使用Composer安装PHP依赖项

构建脚本.ci/deploy

协助代码部署到Pantheon的脚本。

• .ci/deploy/pantheon/create-multidev为除了默认Git分支之外的分支创建一个新的Pantheon multidev环境
  • 请注意，并非所有用户都有multidev访问权限。有关详细信息，请参阅multidev常见问题解答文档。
• .ci/deploy/pantheon/dev-multidev根据Git分支将构建的工件部署到Pantheon的dev或multidev环境

自动化测试脚本.ci/tests

运行自动化测试的脚本。根据您的测试需求，您可以在此处添加或删除脚本。

静态测试 .ci/test/static和tests/unit 静态测试在不执行代码的情况下分析代码。它在检测语法错误方面很好，但不擅长检测功能。

• .ci/test/static/run 运行PHP CodeSniffer和WordPress编码标准、PHP单元测试和PHP语法检查。
• tests/unit/bootstrap.php 引导Composer自动加载器
• tests/unit/TestAssert.php 一个单元测试示例。需要在tests/unit中创建项目特定的测试文件。

视觉回归测试 .ci/test/visual-regression 视觉回归测试使用无头浏览器对网页进行截图，并比较它们的视觉差异。

• .ci/test/visual-regression/run 运行BackstopJS视觉回归测试。
• .ci/test/visual-regression/backstopConfig.js BackstopJS配置文件。在此处设置的设置需要根据您的项目进行更新。例如，pathsToTest变量确定要测试的URL。

Behat测试 .ci/test/behat和tests/behat Behat是一个用PHP编写的接受/端到端测试框架。它方便在Pantheon基础设施上测试完全构建的WordPress站点。WordHat用于帮助整合Behat和WordPress。

• .ci/test/behat/initialize 从Behat测试中删除任何现有的WordPress用户并备份要测试的环境
• .ci/test/behat/run 使用Terminus设置BEHAT_PARAMS环境变量，配置它通过wp-cli运行，创建必要的WordPress用户，启动无头Chrome，并运行Behat
• .ci/test/behat/cleanup 恢复之前制作的数据库备份，删除用于Behat测试的WordPress用户，并保存Behat拍摄的屏幕截图
• tests/behat/behat-pantheon.yml 与Pantheon站点进行测试的Behat配置文件
• tests/behat/tests/behat/features Behat测试文件（扩展名为.feature）应存储的位置。提供的示例测试需要替换为特定项目的测试。
  • tests/behat/tests/behat/features/visit-homepage.feature 一个Behat测试文件，它访问主页并验证200响应
  • tests/behat/tests/behat/features/admin-login.feature 一个Behat测试文件，它以管理员的身份登录WordPress仪表板，并验证对新建用户访问权限
  • tests/behat/tests/behat/features/admin-login.feature 一个Behat测试文件，它以管理员的身份登录WordPress仪表板，更新blogname和blogdescription设置，清除Pantheon缓存，访问主页，并验证更新的博客名称和描述是否出现。

使用Lando本地工作

要开始使用Lando进行本地开发，请完成以下一次性步骤。请注意，Lando是一个独立产品，并由Pantheon支持。如需进一步帮助，请参阅Lando文档。

• 安装Lando（如果尚未安装）。
• 从GitHub（或GitLab或BitBucket）本地克隆您的项目仓库。
• 根据WordPress配方手动创建一个.lando.yml文件，并使用您首选的配置。
• 运行lando start来启动Lando。
  • 保存本地网站URL。它应类似于https://<PROJECT_NAME>.lndo.site。
• 运行lando composer install --no-ansi --no-interaction --optimize-autoloader --no-progress来下载依赖项。
• 运行lando pull --code=none来下载从Pantheon的媒体文件和数据库。
• 访问上述保存的本地网站URL。

您现在应该能够在本地编辑您的网站。上述步骤不需要在后续启动时完成。您可以使用lando stop停止Lando，然后使用lando start再次启动它。

警告：不要在Lando和Pantheon之间直接推送/拉取代码。所有代码都应该推送到GitHub，并通过持续集成服务（如CircleCI）部署到Pantheon。

Composer、Terminus和wp-cli命令应在Lando中运行，而不是在宿主机器上运行。这是通过在所需命令前加前缀lando来完成的。例如，在更改了composer.json后，运行lando composer update而不是composer update。