使用 Radicle 进行 WordPress 开发：部署到 Kinsta

现代 WordPress 开发已经超越了手动配置和不一致的部署工作流程。Radicle 将 Roots 和其他 WordPress 开发工具（如 Bedrock、Sage 和 Acorn）整合到一个单一的入门堆栈中。

这种集成意味着你可以直接在 WordPress 中获得 Laravel 的开发体验。

此外，在 Kinsta 上设置 Radicle 为你提供了一个支持该堆栈技术要求的托管环境。你可以获得 SSH 访问、WP-CLI 集成，以及配置文档根目录的能力。

本指南概述了在 Kinsta 基础设施上运行 Radicle 所需的配置流程和部署步骤。

Radicle 及其组件

Radicle 将三个不同的 Roots 项目整合到一个集成开发环境中：

Bedrock 通过其改进的文件夹结构和基于 Composer 的依赖管理提供基础。
Sage 处理主题开发，集成了 Tailwind CSS 和 Vite 用于资源构建。
Acorn 通过将 Blade 模板、迁移、路由等引入你的 WordPress 项目，架起了 WordPress 和 Laravel 之间的桥梁。

这种类型的开发环境使你能够直接从项目根目录工作，而不是在典型的主题目录中工作。你的模板位于项目根目录的 resources/views/ 中，而配置则通过 bedrock 目录中的环境特定文件进行。

Composer 通过单个 composer.json 文件管理 WordPress 核心、插件和自定义依赖项。该堆栈需要 PHP 8.3 或更高版本，以及特定的扩展。你还需要 Composer 进行依赖管理和 WP-CLI 进行命令行操作。

Radicle 与传统 WordPress

标准 WordPress 安装（即把所有内容放在 wp-content 目录中）可能会使版本控制复杂化，并使在不同环境中维护一致的安装变得困难。

但是，Radicle 重新构建了结构，使你能够对你的应用程序代码进行版本控制，而无需跟踪 WordPress 核心文件或上传的媒体：

WordPress 核心位于 public/wp 目录中，与你的应用程序代码分离。
public/content 目录取代了 wp-content，你的自定义主题代码位于项目根目录中。

Laravel 风格的配置使用 .env 文件，而不是将数据库凭据和安全密钥嵌入配置文件中。你可以通过 bedrock/environments/ 中的单独配置文件为开发、暂存和生产环境定义不同的设置。

你的版本控制策略受益匪浅，因为你只需要跟踪你的应用程序代码和配置。WordPress 核心更新通过 Composer 进行，插件作为依赖项管理，主题更改存储在你的仓库中。

为 Kinsta 配置 Radicle

部署到 Kinsta 时，你需要 SSH 密钥身份验证，这可以通过 MyKinsta 仪表板获取。

在站点的 Info 部分下找到你的 SFTP/SSH 访问详情，如果你还没有添加公钥，请现在添加。

MyKinsta 中的 SSH/SFTP 信息。

Kinsta 的基础架构符合 Radicle 的技术要求。它运行 PHP 8.3，包含用于依赖管理的 Composer，并预装了 WP-CLI，因此您可以直接从命令行管理 WordPress。

与传统的 WordPress 设置不同，Radicle 使用基于发布版的目录结构。每次部署都会创建一个带时间戳的发布文件夹，current 符号链接指向活动版本。您的应用程序的 web 根目录应设置为 public/current/public。

接下来，配置您的环境变量。复制 Radicle 项目根目录中的 .env.example 文件并重命名为 .env。然后，添加您的数据库详情和环境设置：

DB_NAME='your_database_name'
DB_USER='your_database_user'
DB_PASSWORD='your_database_password'
DB_HOST='your_database_host'
WP_ENV='staging'
WP_HOME='https://{kinsta-staging-url}'
WP_SITEURL="${WP_HOME}/wp"

Radicle 会在 /wp 子目录中安装 WordPress 核心。这将核心文件与您的自定义应用程序代码分离，支持更清晰、版本控制友好的结构。

预发布环境配置

您的配置目录位于 Radicle 项目根目录中，与 public 和 resources 文件夹并列。打开 bedrock/environments/staging.php 来定义特定于预发布环境的设置。每当 .env 文件将 WP_ENV 设置为 staging 时，此文件会覆盖 bedrock/application.php 中的值。

通过在 staging.php 顶部添加以下常量来设置您的预发布站点 URL：

<?php
define('WP_HOME', 'https://staging-url');
define('WP_SITEURL', WP_HOME . '/wp');

预发布 URL 遵循您在网站的 Environments 部分选择预发布环境时显示的模式。

在 MyKinsta 中查找您的预发布环境 URL。

您的部署路径决定了文件在 Kinsta 服务器上的位置。在 MyKinsta 中，注意 Environment details 下的路径。该路径通常显示为 /www/sitename/public，代表您的部署目标。您的部署脚本会将文件同步到这里，为每次部署创建诸如 /www/sitename/public/releases/timestamp 这样的结构，/www/sitename/public/current 符号链接指向活动版本。

建议也在 bedrock/environments/staging.php 中为您的预发布环境启用调试模式。此外，在您的本地 .env 文件中复制并设置预发布环境的数据库凭据（不应将其提交到版本控制）。或者，将这些配置为部署服务器上的环境变量。Kinsta 会为每个环境生成唯一的凭据。

正式环境配置

一旦您从 MyKinsta 仪表板的下拉菜单切换到正式环境，配置过程将与预发布环境相同，但使用正式环境特定的值和更严格的安全设置。

为此，请打开项目根目录 bedrock 目录中的 bedrock/environments/production.php 并修改正式环境 URL：

<?php
define('WP_HOME', 'https://yourdomain.com');
define('WP_SITEURL', WP_HOME . '/wp');

您的正式环境错误处理将与预发布环境不同。主要区别在于关闭调试显示，同时保留错误日志：

define('WP_DEBUG', false);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
define('SCRIPT_DEBUG', false);

此外，从 MyKinsta 的 Database Access 部分复制生产数据库凭证。这些凭证通常与临时环境不同。然而，生产部署路径遵循与临时环境相同的模式，但指向生产环境的目录。MyKinsta Environment details 中的路径可能具有不同的（但相似的）URL。您的部署脚本将以此路径作为生产发布的目标。

修改部署任务

Radicle 的默认部署假设服务器控制，而 Kinsta 不通过托管托管提供此控制。因此，您需要删除任何尝试管理服务器服务的部署任务。

如果您使用的是 Trellis（Radicle 的默认部署工具），请编辑 trellis/roles/deploy/hooks/finalize-after.yml 并完全删除 Reload php-fpm 任务。Kinsta 在检测到文件更改时自动管理 PHP-FPM 重启。

此外，缓存清除通过 Kinsta 的 API 而不是服务器命令进行，因此您需要将任何基于服务器的缓存清除替换为对 Kinsta 缓存清除端点的 HTTP 请求。您可以在设置 API 密钥后将此任务添加到部署最终钩子中：

- name: Clear Kinsta cache
uri:
  url: "{{ site_env.wp_home }}/kinsta-clear-cache-endpoint/"
  method: GET

每个站点都有一个唯一的安全端点，您可以从 Kinsta 支持团队获取该端点。

资产编译在部署之前执行，而不是在服务器上执行。您的本地开发机器或 CI/CD 管道执行 npm run build 将 JavaScript 和 CSS 编译到 public/build 目录中。这些编译后的资产将随您的 PHP 文件一起部署。

Composer 依赖项安装在使用 SSH 执行文件同步后进行：

cd /www/sitename/public/current
composer install --no-dev --optimize-autoloader --no-interaction

--no-dev 标志排除开发依赖项，例如测试框架和调试工具。--optimize-autoloader 标志构建类映射以实现更快的自动加载，减少在请求期间定位类文件的开销。

将 Kinsta MU 插件添加到 Radicle

Kinsta MU 插件通过 MyKinsta 为您的站点启用全页缓存、CDN 集成和缓存管理。由于 Radicle 的非标准目录结构，您需要设置一些特定的配置常量，尽管您可以通过 Composer 将 Kinsta MU 插件添加到 Radicle。安装插件后，您可以将这些常量添加到您的 bedrock/application.php 文件中：

/**
* Kinsta CDN fix for Radicle/Bedrock structure
*/

define('KINSTA_CDN_USERDIRS', 'app');

/**
* Fix Kinsta MU Plugins URL path with Radicle/Bedrock
*/

$mu_plugins_url = Config::get('WP_CONTENT_URL') . '/mu-plugins';

define('KINSTAMU_CUSTOM_MUPLUGIN_URL', "{$mu_plugins_url}/kinsta-mu-plugins");

第一个常量在 Bedrock 的 app 结构中指定您的上传目录。第二个常量更正插件的资产 URL 路径，以便正确加载 JavaScript 和 CSS 文件。

验证插件安装后，您可以通过 MyKinsta 仪表板测试缓存清除，以确认该插件与 Kinsta 的基础设施正常通信。

如何设置自动化部署

GitHub Actions 是将 Radicle 部署到 Kinsta 的简单方法。例如，您可以在存储库中创建工作流文件 .github/workflows/deploy.yml。此工作流在推送到特定分支时触发，这些分支将构建资产并将代码部署到相应的环境。

存储在 GitHub 仓库中的 SSH 密钥将允许安全连接到 Kinsta 的服务器。为此，您需要在 GitHub 中添加 SSH 私钥、Kinsta 主机、SSH 端口和用户名的密钥。

部署脚本负责协调文件同步过程。该脚本通常使用 rsync 高效传输文件，仅发送更改过的文件，并保持正确的权限。但是，您应该从部署中排除开发文件，例如 node_modules、.git 和 .env，以保持生产环境干净。

一旦文件同步成功，就可以运行缓存清除和清理任务。该过程涉及部署脚本向 Kinsta 的缓存清除端点发出请求，等待确认，然后运行任何必要的清理命令。

GitHub Actions 配置

您可以通过在仓库根目录创建 .github/workflows/deploy.yml 文件来定义部署自动化。这将处理资源编译、依赖安装以及文件同步到 Kinsta。

在这里，从特定分支的触发器开始，将 staging 分支部署到您的预发布环境，将 main 分支部署到生产环境：

name: Deploy to Kinsta
on:
push:
branches:
  - staging
  - main
jobs:
deploy:
runs-on: ubuntu-latest
steps:
  - name: Checkout code
    uses: actions/checkout@v3
  - name: Setup Node.js
    uses: actions/setup-node@v3
    with:
      node-version: '22'
  - name: Install dependencies and build assets
    run: |
      npm ci
      npm run build

矩阵策略可以在不重复工作流代码的情况下处理多个环境。您添加的特定环境变量可以根据触发工作流的分支进行更改：

strategy:
  matrix:
    include:
      - branch: staging
        ssh_host: ${{ secrets.KINSTA_STAGING_HOST }}
        ssh_port: ${{ secrets.KINSTA_STAGING_PORT }}
        ssh_user: ${{ secrets.KINSTA_STAGING_USER }}
        deploy_path: /www/sitename_1/public
      - branch: main
        ssh_host: ${{ secrets.KINSTA_PRODUCTION_HOST }}
        ssh_port: ${{ secrets.KINSTA_PRODUCTION_PORT }}
        ssh_user: ${{ secrets.KINSTA_PRODUCTION_USER }}
        deploy_path: /www/sitename_2/public

资源编译步骤在部署前创建优化的 JavaScript 和 CSS 文件。工作流使用 npm ci 而不是 npm install，以根据您的 package-lock.json 文件进行可重现的构建。npm run build 命令执行您在 package.json 中定义的生产构建脚本，通常运行 Vite 或其他打包器来编译和压缩资源。

此时，您可以在 Node.js 步骤之后添加 Composer 安装：

- name: Setup PHP
  uses: server/setup-php@v2
  with:
    php-version: '8.3'

  - name: Install Composer dependencies
    run: composer install --no-dev --optimize-autoloader --no-interaction

工作流现在已准备好编译资源和已安装的依赖，可以部署到 Kinsta。

部署脚本详情

通过 rsync 进行文件同步仅传输更改过的文件，从而最大程度减少部署时间。为此，请在构建资源后将此步骤添加到您的 GitHub Actions 工作流中：

- name: Deploy to Kinsta via rsync
  env:
    SSH_PRIVATE_KEY: ${{ secrets.SSH_PRIVATE_KEY }}
  run: |
    mkdir -p ~/.ssh
    echo "$SSH_PRIVATE_KEY" > ~/.ssh/deploy_key
    chmod 600 ~/.ssh/deploy_key
    rsync -avz --delete \
      --exclude='.git' \
      --exclude='node_modules' \
      --exclude='.env' \
      --exclude='trellis' \
      -e "ssh -i ~/.ssh/deploy_key -p ${{ matrix.ssh_port }} -o StrictHostKeyChecking=no" \
      ./ ${{ matrix.ssh_user }}@${{ matrix.ssh_host }}:${{ matrix.deploy_path }}/releases/$(date +%Y%m%d%H%M%S)/

rsync 标志控制传输行为：

-a 启用归档模式，保留权限和时间戳。
-v 提供详细输出用于调试。
-z 在传输过程中压缩数据。

--delete 标志会删除服务器上仓库中不再存在的文件，从而保持部署的整洁。

排除模式可防止传输不必要的文件。此外，Git 元数据、开发依赖项、环境文件和部署工具都不会进入生产服务器。发布目录结构为每次部署创建带时间戳的目录，以便通过更改符号链接实现快速回滚。

符号链接管理将您的持久数据连接到每个新版本。同步文件后，您可以 SSH 连接到服务器并创建符号链接：

- name: Create symlinks and update current
  run: |
    ssh -i ~/.ssh/deploy_key -p ${{ matrix.ssh_port }} -o StrictHostKeyChecking=no \
      ${{ matrix.ssh_user }}@${{ matrix.ssh_host }} << 'EOF'
    cd ${{ matrix.deploy_path }}
    # Link shared .env file
    ln -nfs ${{ matrix.deploy_path }}/shared/.env \
      ${{ matrix.deploy_path }}/releases/$(ls -t releases | head -1)/.env
    # Link uploads directory
    ln -nfs ${{ matrix.deploy_path }}/shared/public/content/uploads \
      ${{ matrix.deploy_path }}/releases/$(ls -t releases | head -1)/public/content/uploads
    # Update current symlink atomically
    ln -nfs ${{ matrix.deploy_path }}/releases/$(ls -t releases | head -1) \
      ${{ matrix.deploy_path }}/current
    EOF

.env 文件包含跨部署持久化的环境特定配置。存储在发布目录外的上传文件可防止删除旧版本时丢失媒体文件。原子符号链接更新（ln -nfs）确保零停机，因为请求永远不会访问到部署到一半的版本。

清理会在成功部署后删除旧版本，只保留最近的五个版本：

- name: Clean up old releases
  run: |
    ssh -i ~/.ssh/deploy_key -p ${{ matrix.ssh_port }} -o StrictHostKeyChecking=no \
      ${{ matrix.ssh_user }}@${{ matrix.ssh_host }} << 'EOF'
    cd ${{ matrix.deploy_path }}/releases
    ls -t | tail -n +6 | xargs rm -rf
    EOF

这种清理策略在磁盘空间利用和回滚能力之间取得了平衡。五个版本提供了多个回滚点，同时防止了无限存储增长。

总结

Radicle 通过将 Bedrock 的改进结构、Sage 的现代主题工作流和 Acorn 的 Laravel 功能整合到一个技术栈中，改变了 WordPress 开发方式。

部署到 Kinsta 需要超出标准 WordPress 托管的配置，但在安全性、可维护性和开发体验方面带来的好处证明了设置工作的价值。

当您准备好自信地部署现代 WordPress 应用程序时，探索 Kinsta 的托管 WordPress 托管服务，体验支持您所需自定义开发工作流的主机基础设施。

原文链接：https://kinsta.com/blog/wordpress-development-radicle/

小狸科技

使用 Radicle 进行 WordPress 开发：部署到 Kinsta

Radicle 及其组件

Radicle 与传统 WordPress

为 Kinsta 配置 Radicle

预发布环境配置

正式环境配置

修改部署任务

将 Kinsta MU 插件添加到 Radicle

如何设置自动化部署

GitHub Actions 配置

部署脚本详情

总结

留下评论取消回复

Radicle 及其组件

Radicle 与传统 WordPress

为 Kinsta 配置 Radicle

预发布环境配置

正式环境配置

修改部署任务

将 Kinsta MU 插件添加到 Radicle

如何设置自动化部署

GitHub Actions 配置

部署脚本详情

总结

相关文章

WordPress 中的 Blade 模板：使用 Kinsta 上的 Radicle 进行现代模板开发

使用 HTTP API 构建可靠的远程请求

WPBeginner 聚焦 20：WordPress 存储清理、更智能的预览和自动化更新

留下评论取消回复