README

该仓库是一个现代WordPress工作流程的参考实现和起始状态，利用Composer、持续集成（CI）、自动化测试和Pantheon。

该仓库旨在通过Terminus Build Tools Plugin一次性复制，但也可用作模板。

Terminus Build Tools插件将构建一个新项目，包括

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

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

重要文件和目录

/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。开发依赖项不会部署到Pantheon。

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

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

通过composer.json将第三方WordPress依赖项（如插件和主题）添加到项目中。composer.lock文件跟踪依赖的确切版本。使用Composer installer-paths确保将WordPress依赖项下载到正确的目录。

我们不允许从公共wpackagist仓库安装插件。所有插件都必须通过我们的nolte-wpackagist安装。这确保了只有经过批准的插件被使用。

非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 使用WordPress编码标准和PHP Unit运行PHP CodeSniffer以及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。

使用Lando在本地工作

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

• 如果尚未安装，请安装Lando。
• 创建一个用于本地托管项目的文件夹。
• 从您的项目文件夹运行lando init并按照提示操作，选择Pantheon配方，然后输入有效的机器令牌并选择由[Terminus构建工具插件]创建的Pantheon站点。[https://github.com/pantheon-systems/terminus-build-tools-plugin]
• 运行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之间推送/拉取代码。所有代码都应该推送到Bitbucket，然后通过其持续集成服务Pipelines部署到Pantheon。

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

使用Cypress进行本地测试

Cypress是一个基于JavaScript的端到端测试框架。它建立在Mocha和Chai之上，这些框架在浏览器上运行，并支持Chai的BDD和TDD断言风格。Cypress的文档可以在这里找到，API文档可以在这里找到。这些包括最佳实践、命令、断言和事件的指南。

您可以在Cypress的Github上找到许多测试示例，包括带有存根、表单和网络请求的测试示例在这里。

编写测试

可以将新测试添加到tests/cypress/integration/。可以在tests/cypress/fixtures/中添加固定数据文件。支持文件tests/cypress/support/index.js在每次spec文件运行之前运行，是存储可重用行为（例如导航到主页）的地方。

要创建一个新的spec文件，使用语法test-name_test.spec.js。使用Mocha函数describe()将每个文件中的测试分组。使用it()来标识单个测试。避免像单元测试时那样为每个断言编写一个it()函数。集成测试可以包含多个断言，并且以这种方式运行效率更高。

要引用组件，而不是依赖于类名或其他脆弱的选择器，检查它是否已经分配了自定义数据属性，或者使用以下模式分配一个：data-{type-of-component}="{component-slug}"

示例：data-molecule="cards/media"

对于创建组件短名，使用文件夹路径。在这个例子中，组件php文件位于molecules/cards/media.php

请注意，为了测试不同屏幕尺寸，Cypress为常用设备提供了视口预设。

运行测试

要无头运行测试，运行命令composer functional-test。要在浏览器中运行测试并查看逐步快照，运行composer functional-test-open。要同时运行Cypress和PHPunit测试，运行composer test。

每个spec文件最新运行的mp4存储在tests/cypress/videos中。